From owner-mobile-ip@sunroof.eng.sun.com Sun Jul 1 03:11:52 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA00985 for ; Sun, 1 Jul 2001 03:11:51 -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 AAA02926; Sun, 1 Jul 2001 00:09:20 -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 AAA16211; Sun, 1 Jul 2001 00:09:13 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f6178LdP021475 for ; Sun, 1 Jul 2001 00:08:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f6178KG6021474 for mobile-ip-dist; Sun, 1 Jul 2001 00:08: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.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f6178HdP021467 for ; Sun, 1 Jul 2001 00:08:17 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA23426 for ; Sun, 1 Jul 2001 00:08:27 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA08831 for ; Sun, 1 Jul 2001 00:08: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 AAA18240 for ; Sun, 1 Jul 2001 00:08:26 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6178PU06135 for ; Sun, 1 Jul 2001 00:08:25 -0700 X-mProtect: Sun, 1 Jul 2001 00:08:25 -0700 Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdiYaD3u; Sun, 01 Jul 2001 00:08:24 PDT Message-ID: <3B3ECC67.82A9E6D0@iprg.nokia.com> Date: Sun, 01 Jul 2001 00:08: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: Mobile IP Working Group Subject: [mobile-ip] Generlized Keys draft and AAA Registration Keys draft 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, There are two other newly revised drafts available: http://people.nokia.net/charliep/txt/mobilekey/mip-key.txt http://people.nokia.net/charliep/txt/genkey/genkey.txt Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Sun Jul 1 03:50:34 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA03577 for ; Sun, 1 Jul 2001 03:50:33 -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 BAA09735; Sun, 1 Jul 2001 01: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 AAA16059; Sun, 1 Jul 2001 00:07:29 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f61769dP021443 for ; Sun, 1 Jul 2001 00:06:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f6176952021442 for mobile-ip-dist; Sun, 1 Jul 2001 00:06: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.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f61765dP021435 for ; Sun, 1 Jul 2001 00:06:05 -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 AAA02622 for ; Sun, 1 Jul 2001 00:06:15 -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 BAA09463 for ; Sun, 1 Jul 2001 01:06: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 AAA18183 for ; Sun, 1 Jul 2001 00:06:14 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6176Am04890 for ; Sun, 1 Jul 2001 00:06:10 -0700 X-mProtect: Sun, 1 Jul 2001 00:06:10 -0700 Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdYco5pw; Sun, 01 Jul 2001 00:06:08 PDT Message-ID: <3B3ECBE0.85767958@iprg.nokia.com> Date: Sun, 01 Jul 2001 00:06:08 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Mobile IP Working Group Subject: [mobile-ip] draft-ietf-mobileip-ipv6-14.txt 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, I believe that most of the current issues with Mobile IPv6 are resolved at least to the point of some local equilibrium -- except, of course, that we still do not know how to evaluate security design decisions. Thus, I have supplied a newly revised text to be distributed. It is also available at the following URL: http://people.nokia.net/charliep/txt/mobilev6/mobilev6.txt The new text is improved (thanks to Ken and T.J. and Mattias) from the drafty version publicized a couple of weeks ago. No major comments about the reduced reliance on AH were received, and so I thought that the newly specified structure for the Binding Update option was acceptable. If not, I'll happily make whatever changes are required, including going back to a design which relies on AH. There is one unsatisfied citation -- namely, the citation for the as yet unidentifiable key distribution draft. The Mobile IPv6 draft is completely neutral on this subject; there is only the (currently false) assumption that some key distribution draft does exist. Other changes include the new Mobile Prefix Advertisement message for distributing prefix information to roaming mobile nodes whenever necessary, and a scheduling algorithm for that. Please consult the "Changes" section of the appendix for a more complete list. Comments are welcome as always; please send editorial comments to me directly, and design questions, improvements, and observations to the list. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Sun Jul 1 07:52:01 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA09816 for ; Sun, 1 Jul 2001 07:52: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 EAA19344; Sun, 1 Jul 2001 04:52:34 -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 EAA25883; Sun, 1 Jul 2001 04:52:25 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f61Bp2dP021787 for ; Sun, 1 Jul 2001 04:51:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f61Bp18T021786 for mobile-ip-dist; Sun, 1 Jul 2001 04:51: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.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f61BowdP021779 for ; Sun, 1 Jul 2001 04:50:58 -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 EAA02426 for ; Sun, 1 Jul 2001 04:51:08 -0700 (PDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id FAA26773 for ; Sun, 1 Jul 2001 05:51:06 -0600 (MDT) Received: (qmail 21108 invoked by uid 500); 1 Jul 2001 11:39:34 -0000 Date: Sun, 1 Jul 2001 04:39:33 -0700 From: Pat Calhoun To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Generlized Keys draft and AAA Registration Keys draft Message-ID: <20010701043931.O5195@charizard.diameter.org> References: <3B3ECC67.82A9E6D0@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: <3B3ECC67.82A9E6D0@iprg.nokia.com>; from charliep@iprg.nokia.com on Sun, Jul 01, 2001 at 12:08:23AM -0700 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 much!!!! I owe you at beer in London for turning this around so quickly. See ya soon, PatC On Sun, Jul 01, 2001 at 12:08:23AM -0700, Charles E. Perkins wrote: > Hello folks, > > There are two other newly revised drafts available: > http://people.nokia.net/charliep/txt/mobilekey/mip-key.txt > http://people.nokia.net/charliep/txt/genkey/genkey.txt > > Regards, > Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 2 10:36:54 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA27245 for ; Mon, 2 Jul 2001 10:36:52 -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 HAA25564; Mon, 2 Jul 2001 07:37: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 HAA17774; Mon, 2 Jul 2001 07:37:09 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f62Ea5dP023436 for ; Mon, 2 Jul 2001 07:36:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f62Ea5OW023435 for mobile-ip-dist; Mon, 2 Jul 2001 07:36: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f62Ea2dP023428 for ; Mon, 2 Jul 2001 07:36:02 -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 HAA14981 for ; Mon, 2 Jul 2001 07:36:08 -0700 (PDT) Received: from netmail2.alcatel.com (netmail2.alcatel.com [128.251.168.51]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA04842 for ; Mon, 2 Jul 2001 08:37:08 -0600 (MDT) Received: from auds952.usa.alcatel.com (auds952.usa.alcatel.com [143.209.238.7]) by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id JAA06046 for ; Mon, 2 Jul 2001 09:36:07 -0500 (CDT) Received: from usa.alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f62Ea6F21646 for ; Mon, 2 Jul 2001 09:36:06 -0500 (CDT) Message-ID: <3B4086D4.57676AE3@usa.alcatel.com> Date: Mon, 02 Jul 2001 09:36:05 -0500 From: Sridhar Gurivireddy Organization: Alcatel USA X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] A question on draft-ietf-mobileip-hmipv6-03.txt 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 Routing header is used only when route optimization is done Sridhar Karann Chew wrote: > Hi, > > I have a question on the HMIPv6 draft. Please help. > > In Section 8 "Comparison Btwn HMIPv6 Modes of Operation" > Paragraph #2 mentions that for the extended mode, MAP will _decapsulate_ > the packets and the _encapsulate_ them again to the MN. > > Why decap and encap? For MIPv6, isn't Routing Header is used instead? > > Regards, > Karann > > On Mon, 30 Apr 2001 Internet-Drafts@ietf.org wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > This draft is a work item of the IP Routing for Wireless/Mobile Hosts Working Group of the IETF. > > > > Title : Hierarchical MIPv6 mobility management > > Author(s) : H. Soliman, C. Castelluccia, K. Malki, L. Bellier > > Filename : draft-ietf-mobileip-hmipv6-03.txt > > Pages : 27 > > Date : 27-Apr-01 > > > > This draft introduces some extensions for MIPv6 and neighbour > > discovery to allow for the introduction of a hierarchical MIPv6 > > mobility management model. The proposed hierarchical mobility > > management for MIPv6 will reduce the amount of signalling to CNs and > > the HA and may also improve the performance of MIPv6 in terms of > > handoff speed. Moreover, HMIPv6 is well-suited to implement access > > control and handoffs between different access technologies. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-mobileip-hmipv6-03.txt > > > > 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-hmipv6-03.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-hmipv6-03.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. > > -- Sridhar Guriviredddy, Alcatel- Network Strategic Group, Richardson, TX-75080 Ph: 972.996.2048 From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 2 10:56:50 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10916 for ; Mon, 2 Jul 2001 10:56: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 IAA13751; Mon, 2 Jul 2001 08:57: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 HAA19817; Mon, 2 Jul 2001 07:57:12 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f62EuFdP023553 for ; Mon, 2 Jul 2001 07:56:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f62EuFrW023552 for mobile-ip-dist; Mon, 2 Jul 2001 07: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f62EuBdP023545 for ; Mon, 2 Jul 2001 07:56: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 HAA17575 for ; Mon, 2 Jul 2001 07:56:18 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA13148 for ; Mon, 2 Jul 2001 08:56:16 -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 KAA09767; Mon, 2 Jul 2001 10:55:33 -0400 (EDT) Message-Id: <200107021455.KAA09767@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-kempf-beth-ipv6-00.txt Date: Mon, 02 Jul 2001 10:55:32 -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. Title : Bidirectional Edge Tunnel Handover for IPv6 Author(s) : J. Kempf et al. Filename : draft-kempf-beth-ipv6-00.txt Pages : Date : 29-Jun-01 This document discusses an extension to the Fast Mobile IPv6 handover protocol described in draft-ietf-mobileip-fastmipv6-01.txt that reduces the amount of L3 latency in Mobile IPv6 handover to zero. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kempf-beth-ipv6-00.txt 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-kempf-beth-ipv6-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-kempf-beth-ipv6-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: <20010629141401.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-kempf-beth-ipv6-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-kempf-beth-ipv6-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010629141401.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 2 11:18:16 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA27440 for ; Mon, 2 Jul 2001 11:18:16 -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 JAA26016; Mon, 2 Jul 2001 09:18: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 IAA23643; Mon, 2 Jul 2001 08:18:51 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f62FHxdP023650 for ; Mon, 2 Jul 2001 08:17:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f62FHxTN023649 for mobile-ip-dist; Mon, 2 Jul 2001 08:17: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.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f62FHtdP023642 for ; Mon, 2 Jul 2001 08:17:55 -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 IAA22379 for ; Mon, 2 Jul 2001 08:18:03 -0700 (PDT) Received: from meshpdc.meshnetworks.com ([205.245.27.196]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA24142 for ; Mon, 2 Jul 2001 09:19:02 -0600 (MDT) Received: by meshpdc.meshnetworks.com with Internet Mail Service (5.5.2653.19) id ; Mon, 2 Jul 2001 11:17:56 -0400 Message-ID: <0DF9FBC42474A24CA50F7A27FB08E04844556B@meshpdc.meshnetworks.com> From: Phillip Neumiller To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Extension proposal for FMIPv6 draft Date: Mon, 2 Jul 2001 11:17:55 -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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi James et al, My only reaction when I read this was WOW and great job BTW! I am really excited about the possibilities of this draft. I have a ?few? :-) comments on the draft. 1). In the introduction section 1 sentence (last) did you mean to use the word "defend"? Just seems like a peculiar choice of wording although it does seem appropriate. 2). In section 1, when the "added benefit" of compression state is discussed, you may need to be a bit careful with respect to soft handover and SDU location. IF you are assuming that the said AR is upstream from the SDU (when an SDU is used), then the text is OK for the network side. However, I was not sure if your proposal allowed macro-diversity legs to "travel" through newARs (i.e. concept of active set, etc. done with IP routing). Typically, a RAKE receiver in the MN would combine these seperate legs passed through seperate ARs. I know you are going to say "that is too RF specific Phil", but really it does not have to be, since the same generalized technique could apply to almost any RF technology (with some care). 3). When RF links are talked about as being slow, do you mean in the Burst speed, the round trip time over the air interface, the average throughput under workload conditions or something else? I was not sure what exactly was meant here. You compare wireless to wired here and I am not sure whether we have apples and apples. 4). When you talk about the "rapid fading" that may occur on radio links this is typically engineered out by the RF layer when macro-diversity is used, i.e. your MN is communicating with multiple base stations so chances are pretty good that not all of them will fade at once (except in the case of a shadow fade in which case I agree). The shadow fades will appear as brief interruptions of transport. 5). Also, in WLANs, if the WLAN does not have a RAKE receiver, as in most "standard" IEEE 802.11 implementations, fading is also a problem in campus and indoor communications environments. Also, shadow fades are even more prevelant indoors than outdoors. This suggests that macro-diverstiy (at the IP level) could be gainfully applied over the top of multiple access points to avoid shadow fades that will be prevelant when MNs only communicate with one AP (alas this would require IEEE involvement IF you wanted it to work with 802.11 type networks) see IEEE TG F activities. 6). Of course as I have mentioned many times, I believe we SHOULD allow SeaMoby Context to be coupled with the HRqst message so that the oAR and nAR can decide "intelligently" about admission of the mobile (from either perspective or both). Also, I have suggested sending the HRqst to the *candidate set* so parallelization of this decsion occurs. 7). In the underlying principles section, I am not sure I understand what you mean by micro-manage? IMHO ideally, the MN would be "in-the-loop" as far as handover candidates are concerned in most cases, since it is the only entity with a complete picture of the physical and logical network topology at the instant of handover. 8). I realize the draft is trying to be general purpose, but I don't think we can just "hand wave" soft handover away. The paragraph (page 7): "... as could happen in a three cell corner junction", is only REALLY applicable to a hard handoff based system, since it is actually desirable to have 3 active ARs as opposed to 2 or just one. I would like to see this clarified a bit more. 9). When you say that the "fixed network" is orders of magnitude faster, I get nervous. If an operator deploys a network they will put the minimal amount of bandwidth and AR capacity to handle the traffic generated at busy hour to keep their costs down. So what I am saying is that the signalling latency in the access network may need to be "slushed" or compensated for in a "soft way" as well as the wireless side. There is that nasty thing called congestion that is all-to-frequent in IP networks. UNLESS your assumption is QoS policy managed or reserved signalling bandwidth??? 10).I am also really nervous about your discussions about compression state. Compression decompression MUST be done pre- and post- selection/distribution in CDMA networks. Also, in a VOIP network this would likely be done up in the core by the VOIP gateway on the fixed side and in the MN on the mobile side. This ?ERROR? is spread throughout the document. If you are talking about a non CODEC compressor, i.e. a link compressor (Lempel Ziv or something) applied between the AR and the MN then I can almost see this working. However, this will not work well inside the SDU loop either. :-( 11).Poor radio conditions dropping MIP signalling packets CAN and most likely WILL be mitigated against by deploying macro-diverstiy in 3G networks. The paragraph discussing this seems to be discussing two orthogonal causes and is really not important to the draft (I would remove it). If you have poor radio conditions (that aren't handled by the radios) you no longer have a viable product and you are not in business long. 12). In figure 1. should the AR on the right be nAR? 13). In the requirements section. An L2 trigger at the AR is stated as a requirement. This is used in the "network directed" handover scenario I guess. Can we generalize to mobile and network directed handover scenarios? It seems to me that this trigger is ultimately dependent upon the mobile anyway. 14). It seems that nAR can only be "known" by the mobile so indeed this trigger is dependent on the mobile giving oAR the nAR IP address. What might be a better approach is for the MN to perodically send oAR a list of "candidate" nARs with their RSSI data (plus possibly other goodies) then the oAR can do a SeaMoby CT querry to get layer 3 info and make a better informed decsion about the HO. 15). The MN l2 address seems competely redundant in the L2 handover start since link addressing is already established in order to communicate between the MN and the oAR to begin with. All you need is an event notifier right? 16). In section 3.2 you state "if latency sensitive transfer is underway". I would remove this conditional. If its a better way, just do it that way all the time! I see no reason to distinguish in this instance. 17). NOTE: No consideration of multi-cast routing. 18). NOTE: No consideration of how SCTP multi-homing could dovetail beatifully with this approch. 19). I got confused in the two +three party handover stuff. I am wondering why there needs to be a distinction like this. NOTE: I need to read this long hairy section more carefully. 20). The two/three party stuff reminded me of why timers like TADD and TDROP are part of the soft handover spec. It would seem that more careful attention needs to be applied to link "add" timers and link "drop" parameters to get the hysteresis out of the system. A statement like "waiting until the probability of ping-pong is low" seems to hand wave this problem away. I am not convinced that we can wave ping-pong away so easily in this draft. 21). BTW, why doesn't this proposal support multiple active link layers? Many RF XCVRs of the future (particularly MANETs and hybrids)will have this support implicitly. Also, 3GPP, 3GPP2 (popular targets for MIP related work :-)) have this capability. 22). In section 3.5 I would say that the ITU bound on latency and gaps is no longer applicable to this proposal. What is really important is the end-to end latency reduction made possible for each MN in such a network under busy hour conditions and the fact that there are NO network introduced packet losses, hurray!!! 23). Regarding Handover Smoothing IMHO Buffering will not work. Bi-casting is the ONLY answer for real time latency sensitive traffic. Buffering introduces latency and forces packets to grow old. It is not appropriate for this proposal. 24). Since the ARs are indeed routers, multi-cast routing should be considered as a long term goal to replace temporary source routed tunnels -OR- alternatively, the tunnels can be "learned" and compressed bundles of traffic can be shuttled between the ARs that have "learned" the traffic patterns. This is a very Mesh-like thing to do. Also, in this case, using point-to-point physical links between heavy HO traffic AR pairs (those involved in lots of handover with each other) can help the physical network topology match the logical and aid greatly with QoS on the back haul (usually a big expense in cellular type systems). 25). Thanks for the plug in the acknowledgements. I would prefer that you reference the following if you could: [x] Phillip D. Neumiller, Peter L. Lei, and Michael L. Needham, "Open Base Station Transport (OBAST) Architecture, ACM SIGMOBLE Mobile Computing and Communication Review", Vol. 4, No. 3, July 2000. I really LIKE this draft. I will probably have more comments when I get some more time. Thanks, Phillip Neumiller Mesh Networks, Inc. From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 2 14:12:11 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA20330 for ; Mon, 2 Jul 2001 14:12:10 -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 LAB13445; Mon, 2 Jul 2001 11:12:35 -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 LAA13743; Mon, 2 Jul 2001 11:12:27 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f62IBDdP023931 for ; Mon, 2 Jul 2001 11:11:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f62IBChM023930 for mobile-ip-dist; Mon, 2 Jul 2001 11:11: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 heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f62IB9dP023923 for ; Mon, 2 Jul 2001 11:11:09 -0700 (PDT) Received: from heliopolis.Eng.Sun.COM (eastapp2.East.Sun.COM [129.148.162.99]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA18892; Mon, 2 Jul 2001 11:10:57 -0700 (PDT) From: James Kempf Message-Id: <200107021810.LAA18892@heliopolis.eng.sun.com> Date: Mon, 2 Jul 2001 23:11:04 -0700 To: , "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Extension proposal for FMIPv6 draft X-Mailer: Sun NetMail 2.3 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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Phil, >My only reaction when I read this was WOW and great job BTW! I am >really excited about the possibilities of this draft. I have a >?few? :-) comments on the draft. > Thanx. We look forward to any further comments. Replies to the existing ones below. >1). In the introduction section 1 sentence (last) did you mean to > use the word "defend"? Just seems like a peculiar choice of > wording although it does seem appropriate. > I believe this is the usual terminology in IPv6. A host that uses IP Address Autoconfig must defend the address by responding to other claims on it. >2). In section 1, when the "added benefit" of compression state is > discussed, you may need to be a bit careful with respect to > soft handover and SDU location. IF you are assuming that the > said AR is upstream from the SDU (when an SDU is used), then > the text is OK for the network side. However, I was not sure > if your proposal allowed macro-diversity legs to "travel" > through newARs (i.e. concept of active set, etc. done with > IP routing). Typically, a RAKE receiver in the MN would > combine these seperate legs passed through seperate ARs. I > know you are going to say "that is too RF specific Phil", but > really it does not have to be, since the same generalized > technique could apply to almost any RF technology (with some > care). > The draft is not primarily about radio access networks, though I think the technique could be used in radio access networks (but that is the subject of further work). Therefore, it is not anticipated that SDU functionality will be involved at all, at least initially. With regard to header compression, there is a mismatch between current header compression technology, being pursued in ROHC, and MIPv6. The ROHC group has been designing for IPv4 where there is no change in the over the air header after handover, because the FA strips off the tunnel header with CoA (ignoring route optimization for the moment). In MIPv6, co-located CoA is standard, so the header changes upon handover, which means the compressor needs to restart, reducing the bandwidth for real-time traffic. The mechanism described in the draft does not require the header to change since the CoA doesn't change. The lack of need to restart the header compressor is a serendipitous side effect. There are a couple other such side effects that fall out of this design, which were not mentioned in the draft but that I hope will show up in the list discussion. >3). When RF links are talked about as being slow, do you mean in the > Burst speed, the round trip time over the air interface, the > average throughput under workload conditions or something else? > I was not sure what exactly was meant here. You compare wireless > to wired here and I am not sure whether we have apples and > apples. > We are talking about expected user data performance for RTT over the air interface, so the latter of the three you mention. >4). When you talk about the "rapid fading" that may occur on radio > links this is typically engineered out by the RF layer when > macro-diversity is used, i.e. your MN is communicating with > multiple base stations so chances are pretty good that not all > of them will fade at once (except in the case of a shadow fade > in which case I agree). The shadow fades will appear as brief > interruptions of transport. > Right, typically L3 won't see rapid fading directly, but rather it would see a reduction in throughput as L2 compensated by using retransmits (for link protocols that do not support macrodiversity) or perhaps even no effect (for link protocols that do support macrodiversity). In a hard handover situation, however, rapid fade would even show up for macrodiversity supported protocols, since most such protocols would require breaking off the soft handover legs and restarting in the new RAN. >5). Also, in WLANs, if the WLAN does not have a RAKE receiver, as > in most "standard" IEEE 802.11 implementations, fading is also > a problem in campus and indoor communications environments. Also, > shadow fades are even more prevelant indoors than outdoors. This > suggests that macro-diverstiy (at the IP level) could be gainfully > applied over the top of multiple access points to avoid shadow > fades that will be prevelant when MNs only communicate with one > AP (alas this would require IEEE involvement IF you wanted it to > work with 802.11 type networks) see IEEE TG F activities. > The problem with 802.11 in particular is that it allows a mobile to be associated with only one access point at a time, as I understand it. I agree that it would be nice to be able to do macrodiversity at the IP layer, but I think it would take a major change in the 802.11 protocol. If you have been involved in 802.11, you would be in better position to say whether or not it IEEE would be interested in adding this mode (maybe a third mode, in addition to ad-hoc and infrastructure?). >6). Of course as I have mentioned many times, I believe we SHOULD > allow SeaMoby Context to be coupled with the HRqst message so that > the oAR and nAR can decide "intelligently" about admission of the > mobile (from either perspective or both). > > Also, I have suggested sending the HRqst to the *candidate set* so > parallelization of this decsion occurs. > Agreed. There are synchronization issues if Seamoby context transfer and handover are not tightly coupled. >7). In the underlying principles section, I am not sure I understand > what you mean by micro-manage? IMHO ideally, the MN would be > "in-the-loop" as far as handover candidates are concerned in most > cases, since it is the only entity with a complete picture of the > physical and logical network topology at the instant of handover. > The difficulty is that, unless signalling channels are used, traffic over the air at L3 to determine a handover candidate at the time the mobile and the network determine at L2 that a handover is necessary increases the latency at L3. Anything at L3 that is layered on top of the minimal amount needed for L2 handover will increase handover latency, unless it can be efficiently done on a parallel channel. As a consequence, the draft favors a negotiation between the mobile node and the network ahead of time in which the mobile node's preferences (more probably the user's preferences) for access points are expressed and the network then honors those when performing handover. For this to be possible, the ARs need to know what handover candidates are in their area, which is where the Seamoby handover candidate discovery protocol would come in. If the mobile node has a second radio interface, an alternative is for the mobile node to monitor the second interface and initiate a standard FMIPv6 handover to that interface when it sees that an access point has appeared. In this case, BETH isn't needed because the MN can set up the second interface in parallel and quickly switch the real time stream (by sending a BU to the sender) when the interface is completely up, the HA has been informed, etc. >8). I realize the draft is trying to be general purpose, but I don't > think we can just "hand wave" soft handover away. > > The paragraph (page 7): > > "... as could happen in a three cell corner junction", is only > REALLY applicable to a hard handoff based system, since it is > actually desirable to have 3 active ARs as opposed to 2 or just > one. I would like to see this clarified a bit more. > As mentioned above, I agree that soft handover is important. I can qualify this sentence to mention hard handover, but I think it would probably be better to keep this draft confined to the general case, and explore implications for specific radio protocols in other drafts (like the "IP on xxx Link Layer" draft that come by now and then). >9). When you say that the "fixed network" is orders of magnitude > faster, I get nervous. If an operator deploys a network they will > put the minimal amount of bandwidth and AR capacity to handle the > traffic generated at busy hour to keep their costs down. So what > I am saying is that the signalling latency in the access network > may need to be "slushed" or compensated for in a "soft way" as well > as the wireless side. There is that nasty thing called congestion > that is all-to-frequent in IP networks. UNLESS your assumption is > QoS policy managed or reserved signalling bandwidth??? > Well, I'm taking 9.6 kbps as a figure of merit for the air interface, and even if the access point (aka BTS) is connected back into the network (aka BSC) with a T1 line, it's more than an order of magnitude faster. Of course, the T1 is handling the aggregated traffic from however many mobile are in the cell. On the other hand, I agree that the operator will deploy the minimal mount of bandwidth to keep costs down. But I think they will need to engineer the wired side so that it has enough capacity, and it is easier to add wired capacity than to add air capacity. Adding wired capacity means simply stringing another wire or leasing another fixed microwave link. Adding wireless capacity means to redesign the cell layout to reduce cell size. >10).I am also really nervous about your discussions about compression > state. Compression decompression MUST be done pre- and post- > selection/distribution in CDMA networks. Also, in a VOIP network > this would likely be done up in the core by the VOIP gateway on > the fixed side and in the MN on the mobile side. This ?ERROR? is > spread throughout the document. If you are talking about a non > CODEC compressor, i.e. a link compressor (Lempel Ziv or something) > applied between the AR and the MN then I can almost see this working. > However, this will not work well inside the SDU loop either. :-( > The draft is just talking about header compression over the air, like the kind proposed by ROHC. Actually, wCDMA has a hook in L2 for header compression. You are right about voice compression, however. >11).Poor radio conditions dropping MIP signalling packets CAN and > most likely WILL be mitigated against by deploying macro-diverstiy > in 3G networks. The paragraph discussing this seems to be discussing > two orthogonal causes and is really not important to the draft (I would > remove it). If you have poor radio conditions (that aren't handled > by the radios) you no longer have a viable product and you are not > in business long. > OK. >12). In figure 1. should the AR on the right be nAR? Yes, thanx. > >13). In the requirements section. An L2 trigger at the AR is stated > as a requirement. This is used in the "network directed" handover > scenario I guess. Can we generalize to mobile and network directed > handover scenarios? It seems to me that this trigger is ultimately > dependent upon the mobile anyway. > Yes, in order for L2 handover to work, the mobile must be involved, but a trigger is not necessary on the mobile for the L3 signalling involved in BETH. It is necessary, for example, in FMIPv6 mobile initiated handover for L3 signalling. >14). It seems that nAR can only be "known" by the mobile so indeed this > trigger is dependent on the mobile giving oAR the nAR IP address. > What might be a better approach is for the MN to perodically > send oAR a list of "candidate" nARs with their RSSI data (plus > possibly other goodies) then the oAR can do a SeaMoby CT querry > to get layer 3 info and make a better informed decsion about the HO. > That is one possibile way the oAR could get the candidate handover nARs. As I mentioned, the L2 negotiation involved in handover is not addressed by the draft. >15). The MN l2 address seems competely redundant in the L2 handover start > since link addressing is already established in order to communicate > between the MN and the oAR to begin with. All you need is an > event notifier right? > The idea is the AR needs some indication of which MN to begin the handover for. >16). In section 3.2 you state "if latency sensitive transfer is underway". > I would remove this conditional. If its a better way, just do it > that way all the time! I see no reason to distinguish in this >instance. > The issue is that the mobile node will at some point want to initiate the CoA change. The BET from aAR actually constitutes a triangle route, and at some point it may get extended enough that the MN should change to the new subnet. An opportune time is when there is no real-time traffic underway. >17). NOTE: No consideration of multi-cast routing. > From the home network or the local subnet? Home network multi-cast is covered by standard Mobile IP. As for the local subnet, because the tunnel is from aAR, any changes in multicast routing would apply in that subnet. The MN would not get any traffic through the local AR except as detunneled from aAR. Depending on how location based services are set up, this may be a problem. It does require some more thought. >18). NOTE: No consideration of how SCTP multi-homing could dovetail >beatifully > with this approch. > ???? My understanding is that SCTP allows multiple streams but only between two IP addresses. Did you have this in mind for macrodiversity? >19). I got confused in the two +three party handover stuff. I am wondering > why there needs to be a distinction like this. NOTE: I need to read > this long hairy section more carefully. > The two are somewhat different. Basically, when a BET has already been placed, you need a way to move the wireless end from oAR to nAR. This is somewhat different from setting it up in the first place. >20). The two/three party stuff reminded me of why timers like TADD and > TDROP are part of the soft handover spec. It would seem that more > careful attention needs to be applied to link "add" timers and > link "drop" parameters to get the hysteresis out of the system. A > statement like "waiting until the probability of ping-pong is low" > seems to hand wave this problem away. I am not convinced that we > can wave ping-pong away so easily in this draft. > I agree that there may need to be some timers to take care of ping-pong (with all due respect to Kulwinder). If you look in the handover smoothing section, it talks about maintaining a sliding buffer on oAR until the probability of a ping-pong has decreased low enough. I suspect a timer would be needed there. >21). BTW, why doesn't this proposal support multiple active link layers? > Many RF XCVRs of the future (particularly MANETs and hybrids)will > have this support implicitly. Also, 3GPP, 3GPP2 (popular targets > for MIP related work :-)) have this capability. > I'm not sure I understand what you mean. Do you mean on the mobile? Or through the access router with the mobile running a software defined radio? >22). In section 3.5 > I would say that the ITU bound on latency and gaps is no longer > applicable to this proposal. What is really important is the end-to > end latency reduction made possible for each MN in such a network > under busy hour conditions and the fact that there are NO network > introduced packet losses, hurray!!! > The ITU bound is important in so far as it provides a number to guide the engineering. Without this, one could say that the 100-300 ms latency introduced at L3 by FMIPv6 is acceptable. The draft takes the position that any introduced L3 latency is unacceptable because L2 latency is unavoidable and depending on radio conditions, the combined L2 and L3 latency could exceed this bound and reduce the quality of the call. >23). Regarding Handover Smoothing IMHO > Buffering will not work. Bi-casting is the ONLY answer for real > time latency sensitive traffic. Buffering introduces latency and > forces packets to grow old. It is not appropriate for this proposal. > Both bi-casting and buffering have their drawbacks. Jitter on the wired link can cause duplicate packets or dropouts on nAR with bi-casting. Buffering clogs the radio channel after handover unless it is restricted to the smallest possible window. By combining the two (with appropriate L2 engineering) handover can be optimized to reduce the probability of duplicates and drop outs. The draft recommends a small buffer on nAR that just buffers radio frames during the progress of the L2 handover. >24). Since the ARs are indeed routers, multi-cast routing should be > considered as a long term goal to replace temporary source > routed tunnels -OR- alternatively, the tunnels can be "learned" and > compressed bundles of traffic can be shuttled between the ARs > that have "learned" the traffic patterns. This is a very Mesh-like > thing to do. Also, in this case, using point-to-point physical links > between heavy HO traffic AR pairs (those involved in lots of handover > with each other) can help the physical network topology match the > logical and aid greatly with QoS on the back haul (usually a big > expense in cellular type systems). > I'm not so sure about multicast, since it would require subscribing to a group address and managing that might be difficult, but I agree there are lots of alternatives for traffic engineering. For example, one is setting up MPLS LSPs between heavily used access routers, and switching the traffic through the LSPs instead of IP tunnels. >25). Thanks for the plug in the acknowledgements. I would prefer that > you reference the following if you could: >[x] Phillip D. Neumiller, Peter L. Lei, and Michael L. Needham, "Open > Base Station Transport (OBAST) Architecture, ACM SIGMOBLE Mobile > Computing and Communication Review", Vol. 4, No. 3, July 2000. > Sure, be happy to put it it. I should also probably look it up, sounds like an interesting article. >I really LIKE this draft. I will probably have more comments when I >get some more time. > Great, thanx. jak From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 2 14:48:18 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14483 for ; Mon, 2 Jul 2001 14:48:17 -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 MAA20785; Mon, 2 Jul 2001 12:48: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 LAA18336; Mon, 2 Jul 2001 11:48:42 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f62IlPdP023994 for ; Mon, 2 Jul 2001 11:47:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f62IlPfW023993 for mobile-ip-dist; Mon, 2 Jul 2001 11:47: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.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f62IlLdP023986 for ; Mon, 2 Jul 2001 11:47:21 -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 LAA18382 for ; Mon, 2 Jul 2001 11:47:29 -0700 (PDT) Received: from mail.verizonwireless.com ([199.74.158.61]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA00164 for ; Mon, 2 Jul 2001 12:48:26 -0600 (MDT) Received: from mail.verizonwireless.com by mail.verizonwireless.com (414/1100) with ESMTP id f62Ibfk16400 for ; Mon, 2 Jul 2001 14:37:41 -0400 (EDT) Received: by hqbedigwy1.corp.bam.com with Internet Mail Service (5.5.2653.19) id ; Mon, 2 Jul 2001 14:42:57 -0400 Message-ID: <43E8CCEAF148D211854C00805FA72E5807019872@rhqnneex1.corp.bam.com> From: "Carroll, Christopher X" To: "'mobile-ip@sunroof.eng.sun.com'" Cc: "Flynn, Gerry J" Subject: RE: [mobile-ip] Comments on draft-song-mobile-ipv4-auth-secgenera tion-00.txt Date: Mon, 2 Jul 2001 14:47: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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi JH SONG and CY Chong, I guess the main question between us is "What is the SA between the MN and AAAh?" From my perspective, the MN-AAA key (and associated policy info such as algorithms to be used, life timers, etc...) is effectively the SA between the MN and AAAh. However, in your proposal, a new level is added to the MIP cryptographic key hierarchy: Master/Initial MN-AAA key - session MN-AAA key - MN-HA and MN-FA key. I recommend that you clearly define the Master/Initial MN-AAA key within your proposal (and clearly define the subordinate session MN-AAA key). My confusion regarding your MN-AAA key generation is based on the following sections in your proposal: In section 1, you state "based on the assumption that the SA between the Mobile Node and Home AAA is strong, it is possible to use that SA to create SAs between the MN and its HA. This document specifies the method to dynamically update the shared secret used for MN-AAA extension and create shared secret used for MN-HA extension..." The inference appears to be that "SA" is equivalent to "shared secret" which implies that the MN-AAA key is the MN-AAA SA. According to Section 6 of your proposal, you state "Since the MN-AAA shared secret is dynamically updated for every MIP registration AFTER IT ASSIGNED FIRST TIME, therefore the risk of exposing the MN-AAA shared secret is minimal." This implies that the Initial MN-AAA key is modified. In Appendix A, you state "the MS shall update its pre-assigned MN-AAA shared secret by ...." This implies that the Initial MN-AAA key is modified. I recommend that you clarify these sections to reflect your intent to maintain a static root Secret/SA between the MN and AAAh. Let me address the merits of your proposal (as I currently understand it): My primary question is "What is the value of an additional level in the MIP cryptographic key hierarchy?" If a session MN-AAA key is generated, based on a Master MN-AAA key, is the system security improved? Possibly, but is it necessary. I suppose that an attacker doesn't have the opportunity to observe the challenge/response based on the Master MN-AAA key which prevents a possible cryptanalysis. However, a large key (e.g. 128 bits) should provide adequate security. Your Master MN-AAA key proposal is also similar to TR-45 authentication in which a secondary key, Shared Secret Data A (SSD-A), is derived from the root A-key. SSD-A, not the A-key, is used to calculate the authentication response. However, SSD-A is used to enable more efficient roaming authentication between the home and visited network. SSD-A is considered a temporary (semi-permanent) key that is sent to a visited network to enable Mobile Station (MS) authentication while the MS uses the visited network. SSD-A can be used to calculate multiple authentication responses. When the MS leaves the visited network, the home system can then Update SSD to a new value. The advantage of SSD-A is that network access authentication requests do not continuously have to be routed back to the home system (expensive in SS7 networks), i.e. they are calculated in the visited network, while the root A-key is not revealed to the visited network. GSM networks use crypto-triplets to enable visited network authentication without revealing the root GSM key. If you were proposing a method of enabling Local/Visited network MIP authentication (in which the authentication calculation was performed locally by the FA or local AAA), I think your session MN-AAA key proposal could have added value. With regard to the MN-HA key, is it efficient to update the MN-HA key during every Registration? If the AAAh must send a new MN-HA key to the HA during each registration, why not send the whole Registration Request via the AAAh (and skip sending it via the FA-HA link)? From my perspective, updating the MN-HA key per registration adds no significant security enhancement as long as the MN-HA key is long enough (e.g. 128 bits). However, it is valuable to have a method of initially loading or deriving the MN-HA key (via Key Agreement) and also updating the MN-HA key if compromised. The Perkins/Calhoun proposal allows the service provider to decide when to derive/update MN-HA key which appears more efficient. With regard to your concern that draft-ietf-mobileip-aaa-keys-06 will only apply to Diameter, I agree with your concern and will likely propose that the Perkins/Calhoun procedure be added to the 3GPP2 version of Radius AAA in the next revision of IS-835 (3GPP2 Packet Data/Mobile IP). In conclusion, I recommend the following: 1) You should expressly define and distinguish Master/Initial MN-AAA key and session MN-AAA key in your proposal. 2) I would prefer stronger justification of the need for creating an additional level in the MIP cryptographic key hierarchy. Let me know what you think? regards, chris -----Original Message----- From: junhyuk song [mailto:junhyuk@metro.telecom.samsung.co.kr] Sent: Friday, June 29, 2001 2:11 AM To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Comments on draft-song-mobile-ipv4-auth-secgeneration-00.txt Hi Chris, Thank you for giving us very long insightful comments, it took me a couple of hours to read it through. I agree with you some of your comments. Actually I myself believe distributing key by IKE like "key material" mechanism of draft-ietf-mobileip-aaa-keys-06.txt is the best security solution. Because in the security point of view, it gives master authority to AAA, and MN and any other entity, doesn't really have to care about KEY stuff. What we prpoposed is the interim solution, before we are eventually able to use such new Mobile IP extensions and DIAMETER. We will make necessary changes to our upcoming revision. So meanwhile, please read my comment below. ----- Original Message ----- From: "Carroll, Christopher X" To: Cc: "Flynn, Gerry J" Sent: Friday, June 29, 2001 2:18 AM Subject: Re: [mobile-ip] Comments on draft-song-mobile-ipv4-auth-secgeneration-00.txt > Hi Junhyuk, Dongkie, Chae Yong, and Raymond, > > I have the following comments regarding your draft MIPv4 key generation > proposal: > > Your proposal utilizes a Key Agreement protocol which is similar to the > methods used in TIA TR-45 and GSM cellular telephone networks to create > SESSION keys for privacy and authentication. Also, Bootstrapping the root > key (MN-AAA key, A-key, or GSM K key) is a difficult problem, i.e., > distributing secret keys to millions of handsets must be done securely and > efficiently. GSM / 3GPP distributes keys via SIMs (smart cards), while TIA > TR-45 / 3GPP2 primarily utilizes manufacturer pre-load and an out-of-band > distribution network to populate the network's HLR/AC (equivalent to AAA). I agree. > However, in those networks, the root key (A-key or GSM K key) is never > updated/modified by the visited network. The root keys for these networks > are jealously guarded by the Home Service provider. I suspect the MIPv4 > service providers will want to protect the MN-AAA and MN-HA keys to the same > degree. Unfortunately, your proposal enables a potentially devastating > Denial-of-Service attack in which a Rogue FA creates a mis-synchronization > of the MN-AAA and MN-HA keys between the MN and home network (AAA and HA). > Even if every FA acts properly, a hacker can create his own FA that > continuously initiates MN-AAA and MN-HA key updates with any MN within it's > vacinity. One device, strategically placed at an airport or in the center > of a city, could change the root keys in thousands of MNs. How will the > service provider re-syncronize the MN-AAA or MN-HA key? Perhaps by the > expensive process of manually re-loading the keys or distributing new smart > cards. Perhaps the user could log onto a protected (SSL) website and > download new keys (if they're allowed access). The master MN-AAA shared key never change in our Internet Draft. Only the session MN-AAA shared key is dynamically generated based on FAC. Speaking of DOS attack, are you implying that FA could do the DoS attack to HA with junk MN-AAA or MN-HA key? I believe it is the native problem that exist unless enforcing FA-HA securecy. In your example you mentioned that someone could change the root MN-AAA key in the airport, We DO NOT CHANGE initial MN-AAA key. We just update the it with new one. We always refer the intial MN-AAA key to create new one. Only each MN and each HA just remember the new key, it should always store the initial key. If someone failed to sync with AAA, the others could still have their MN-AAA key. All MN-AAA keys could be different. The Initial MN-AAA key is still intact. > Your proposed MN-AAA key chaining is inherently susceptable to > synchronization problems between the MN and AAA. Even the 3GPP AKA protocol > has elaborate procedures for re-synchronization of sequence numbers. How do > you propose to re-synchronize MN-AAA keys when there's a mismatch? How > would the network know whether a fraudulent access attempt or MN-AAA key > mismatch occurred? There is no synchronization problems between MN and AAA, because AAA alway create the session MN-AAA shared key based on Master MN-AAA shared key and FAC > One possible solution to this problem could be to use a Mutual > Authentication scheme between the MN and FA (or between the MN and AAA) to > ensure that the MN only updates these keys with a valid FA - however, this > may be impractical because the MN and FA must share a common secret in the > first place (Chicken-before-the-egg problem). Let's not talk about Public > key because MNs may not have the processing power to use Certificates and > service providers may not have the expertise to deal with PKI. I agree MN-FA is not practical at all. > The MN-AAAh key appears to be the root key for MIPv4 in which a > Radius/Diameter AAA server is used. It appears that the MN-AAAh key is > intended to be a subscription lifetime key (like the A-key and K in > TR-45/3GPP2 and GSM/3GPP networks). It is dangerous to allow a visited > system to update such a key during the subscription lifetime - such a > procedure should be initiate and controlled by the home system (AAAh). > (Note: your root key update procedure doesn't even enable secure recovery if > the MN-AAA key data base were compromised because the hacker/criminal will > only need to intercept the FAC to generate the new MN-AAA key). First 3GPP2 does not enforce any life time for MN-AAA key what so ever. And once again, the master MN-AAAH key never updated, it only used for creating session MN-AAA key. (Note: Hacker will not be able to compromise session MN-AAA key by FAC. This is simply because our solution has the same security assumption of MN-AAA authentication. In other words, even if Hacker intercept FAC to derive MN-HA shared key or even MN-AAA shared key, it costs the same amount of money and time to compromise MN-AAA shared key used in MN-AAA athenticator. If so it can be compromised anyway, it is same to MN-AAA authentication. ) > The MN-HA key may not be a subscription lifetime key, but it could be. > However, MN-HA key generation can be efficiently performed based on the > MN-AAA key which implies that AAAh must be involved in the process. Your > Dynamic / session generation of the MN-HA key appears inefficient from a > key management perspective because the AAAh must generate and distribute a > new MN-HA key for every system access. In the draft Perkins/Calhoun 06 > proposal, a new MN-HA key is generated only when necessary. Thus, even when > dynamic HA assignment occurs, the AAAh generates and distributes the new > MN-HA key for the new HA. It also issues the MN-HA key update to the MN. > It appears that the draft 06 proposal could allow the AAAh (and MN) to > manage the MN-HA keys for multiple HA simultaneously. The MN simply needs a > queue in which to store the different MN-HA keys or the AAAh could update > one MN-HA key during each dynamic HA assignment. From my perspective the > current Perkins/Calhoun proposal reduces the amount of MN-HA key generation > and distribution while maintaining the proper security. Speaking of key lifetime and key management perspective, we are working on the next revision. Our new revision has better Key management than current Internet Draft. In a nutshell, MN and AAAH has pre-fixed MN-HA shared key life time, and the lifetime will be sent with MN-HA shared key to HA by AAA message. So, when MN generates MN-HA shared key, MN will timestamp it. That timesamp is the same timestamp used to RRQ Identification. HA and AAA can derive the life time of MN-HA out of timestamp and the pre-fixed lifetime from AAA message. Key life time and key management perspective, we are working on the next revision. Well, I thought we are talking about our Internet Draft, but since you keep specifically refering to other Internet Draft. Let me compare our darft and draft-ietf-mobileip-aaa-keys-06.txt. Our solution works better for RADIUS based AAA in terms of DOS attack. The problem I have for draft-ietf-mobileip-aaa-keys-06.txt is that it only may works for DIAMETER based AAA. For example, it lets MN to send RRQ with MN-HA authenticator made "0" MN-HA shared key. So upon receiving of RRQ, HA must ask AAAH and fetch "Key Material" and "MN-HA shared key". And then HA will made binding table, other necessary processing, and made RRP with MN-HA Authenticator with newly assigned MN-HA shared key. But problem is HA does all of this work with no knowledge of whether MN is legimate or not, since it didn't perform MN-HA authentication. And it does not require or enforce FA-HA authentication. Someone, may argue that since there is MN-HA shared key was found in AAAH, it means that it is legimate RRQ, but that key may be supposed to be given to some other HA. That means that solution is vulnerable to DoS attack too. > It is likely most efficient to generate the MN-FA key as a session key > because the MN may interact with countless FAs (impractical for MN to store > MN-FA key for all FAs). In fact, I proposed a similar procedure to the > 3GPP2 TSG-P Subcommittee several months ago. However, dynamic generation of > the MN-FA key based on the FAC may not be significantly more efficeint than > having the MN-FA generated based on randomness provided by the AAAh. I agree, the randomness generated by the AAAh will be more secure, but I cannot agree with you on the 3GPP2 TSG-P network case. Becuase the FAC is 128 bit, randomness provided by PDSN. And it depends on the Random number generator of PDSN, it is supposed to be unique in each RRQ. RFC3012, state that if it is not unique number for the user, it will simply discard it. > I have a cryptographic concern with your method of generating a new MN-AAA > key based on the previous MN-AAA key. This key generation chaining may be > vulnerable to some type of cryptanalysis. Once again, we are not proposing to generate new MN-AAA master key, it is session MN-AAA key. And if it can be compromised then, the MN-AAA authenticator has the same security concern. I think the cryptocgraphic concern about the cryptanylysis should be resolved by some other context, but it is out of boundary of this document(In my undertanding, all plain-text form of AAA access request/response messages are vulnerable to cryptanaysis what you refering to) > In general, your proposed key generation scheme appears unacceptable because > it may expose MIPv4 networks to a devastating Denial-of-Service attack. > Like many security schemes that rely on synchronization, your key generation > scheme appears too unstable to be reliable. However, I do beleive that your > MN-FA key generation proposal has some merit. I am not sure what DOS attack you are implying to. Other internet draft has the same DOS issue in case of RADIUS based AAA. It could be solved only by using the FA-HA authentication. And, Please don't say "unacceptable" you haven't seen our revision yet. Regards, JH SONG, CY Chong > regards, > > chris > > ********************************************************************** > Christopher Carroll Office: 508-330-3401 > Senior Member Technical Staff fax: 508-330-3403 > Verizon Wireless cellular: 781-424-4131 > Chair TR-45 Adhoc Authentication Group > email: christopher.carroll@verizonwireless.com > ********************************************************************** > From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 3 03:19:59 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA07519 for ; Tue, 3 Jul 2001 03:19:58 -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 AAA25723; Tue, 3 Jul 2001 00:20:31 -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 AAA07312; Tue, 3 Jul 2001 00:20:26 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f637JXdP024778 for ; Tue, 3 Jul 2001 00:19:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f637JXIe024777 for mobile-ip-dist; Tue, 3 Jul 2001 00: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f637JTdP024770 for ; Tue, 3 Jul 2001 00:19:29 -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 AAA07246 for ; Tue, 3 Jul 2001 00:19:37 -0700 (PDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA18614 for ; Tue, 3 Jul 2001 01:19:35 -0600 (MDT) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f637JXO20070; Tue, 3 Jul 2001 09:19:33 +0200 (MEST) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id JAA25210; Tue, 3 Jul 2001 09:19:32 +0200 Message-ID: <3B4171B2.7098C705@era.ericsson.se> Date: Tue, 03 Jul 2001 09:18:10 +0200 From: Mattias Pettersson Organization: Ericsson Research X-Mailer: Mozilla 4.77 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: "Charles E. Perkins" CC: TJ@Kniveton.com, "Ulf =?iso-8859-1?Q?Bj=F6rklund?=" , "mobile-ip@sunroof.eng.sun.com" Subject: Re: [Fwd: [mobile-ip] Mobile IPv6 clarifications] References: <3B3B2E46.50E17D25@era.ericsson.se> <3B3E90F1.3F4AC384@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 [This is a resend - wrong mailing list address in previous mail] "Charles E. Perkins" wrote: > > > Our suggestion is that we instead define a new BA status code (139?) of > > "sequence number too small". If the HA recieves a BU where T <= S, it > > must instead send a BA back to MN with status = 139 and the sequence > > number field set to S. The MN will retransmit the BU and now use T = S + > > D (D=1 comes to mind as best choice). > > > > Does anyone see a security problem here? The HA only exposes what has > > already been transmitted over the wire. The HA doesn't need to keep > > state for this. > > I have followed your suggestion, and added the following text: > > If the mobile node sends a sequence number which is not greater than > the sequence number from the last successful Binding Update, then > the home agent MUST send back a Binding Acknowledgement with > status code 141, and the last accepted sequence number in the > Sequence Number field of the Binding Acknowledgement. > Sorry, I need to bother you again. I've discussed this with a security expert (thanks Andras!), and we could revise this slightly. There is a different approach to the sync problem, if I only had read section 13.1 better or studied IPSec more. We don't need to beware of replay attacks regarding the sequence number in the BU, as long as we stick to IPSec protection, since IPSec has its own sequence number. The mobile node may, upon it's first registration, use sequence number 0. If it gets no reply from the home agent, it may increase the sequence number with 32768. That will assure that, as long as packets are transmitted properly, either sequence number 0 or 32768 will be greater that the previous sequence number the home agent possibly has stored. This will assure that a registration will be accepted within one or two BUs sent if the mobile node has lost sync with the home agent. > > 2. There should be a statement about sequence numbers. According to the > > sequence number comparison method, the number 0 is smaller than 1 up to > > 32767, but greater than 32768 up to 65535. If MN sends a BU with > > sequence number 0 at some point, it can use all sequence numbers up to > > 32767. After that, it must renegotiate SA with the peer (HA/CN), or it > > will be exposed to a potential replay attack. > > I added the following text to the Security Considerations: > > After the Sequence Number space of the Binding Update and > Binding Acknowledgement options has been exhausted, the > mobile node and the home agent SHOULD renegotiate their > security association in order to prevent any possibility > of replay attacks. This part will not be needed if we stick to IPSec protection. However, I'm not sure what protection will be used for the MN-CN relation. /Mattias From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 3 06:58:05 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA24236 for ; Tue, 3 Jul 2001 06:58:03 -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 EAA23940; Tue, 3 Jul 2001 04:58: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 DAA07422; Tue, 3 Jul 2001 03:58:29 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f63AvIdP025090 for ; Tue, 3 Jul 2001 03:57:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f63AvIVL025089 for mobile-ip-dist; Tue, 3 Jul 2001 03:57: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f63AvCdP025079 for ; Tue, 3 Jul 2001 03:57:12 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA09555 for ; Tue, 3 Jul 2001 03:57:19 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA07597 for ; Tue, 3 Jul 2001 03:57:19 -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 GAA23218; Tue, 3 Jul 2001 06:56:35 -0400 (EDT) Message-Id: <200107031056.GAA23218@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-ipv6-14.txt Date: Tue, 03 Jul 2001 06:56:34 -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 : Mobility Support in IPv6 Author(s) : D. Johnson, C. Perkins Filename : draft-ietf-mobileip-ipv6-14.txt Pages : 120 Date : 02-Jul-01 This document specifies the operation of mobile computers using IPv6. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about the mobile node's current location. IPv6 packets addressed to a mobile node's home address are transparently routed to its care-of address. The protocol enables IPv6 nodes to cache the binding of a mobile node's home address with its care-of address, and to then send any packets destined for the mobile node directly to it at this care-of address. To support this operation, Mobile IPv6 defines four new IPv6 destination options, including one that MUST be supported in packets received by any node, whether mobile or stationary. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-ipv6-14.txt 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-ipv6-14.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-ipv6-14.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: <20010702161356.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-ipv6-14.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-ipv6-14.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010702161356.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 3 06:58:06 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA24242 for ; Tue, 3 Jul 2001 06:58:04 -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 EAA23936; Tue, 3 Jul 2001 04:58: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 DAA07421; Tue, 3 Jul 2001 03:58:29 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f63AvFdP025087 for ; Tue, 3 Jul 2001 03:57:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f63AvENR025086 for mobile-ip-dist; Tue, 3 Jul 2001 03:57: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.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f63Av9dP025072 for ; Tue, 3 Jul 2001 03:57:09 -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 DAA08571 for ; Tue, 3 Jul 2001 03:57:16 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA23388 for ; Tue, 3 Jul 2001 04:57:14 -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 GAA23169; Tue, 3 Jul 2001 06:56:30 -0400 (EDT) Message-Id: <200107031056.GAA23169@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-gen-key-00.txt Date: Tue, 03 Jul 2001 06:56:29 -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 : Generalized Key Distribution Extensions for Mobile IP Author(s) : C. Perkins, P. Calhoun Filename : draft-ietf-mobileip-gen-key-00.txt Pages : 8 Date : 02-Jul-01 Recent proposals have suggested several kinds of key extensions for Mobile IP registration messages. These keys may be used between the mobile node and mobility agents, or between the mobility agents themselves. This document specifies generalized extension formats that can be useful for several kinds of key distributions. Each generalized extension format will have subtypes which indicate the specific format for the key distribution data. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-gen-key-00.txt 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-gen-key-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-gen-key-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: <20010702161347.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-gen-key-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-gen-key-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010702161347.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 3 07:26:03 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA11830 for ; Tue, 3 Jul 2001 07:26:02 -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 EAA29736; Tue, 3 Jul 2001 04:26: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 EAA09698; Tue, 3 Jul 2001 04:26:36 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f63BPfdP025321 for ; Tue, 3 Jul 2001 04:25:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f63BPeYP025320 for mobile-ip-dist; Tue, 3 Jul 2001 04:25: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.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f63BPbdP025313 for ; Tue, 3 Jul 2001 04:25: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 EAA09650 for ; Tue, 3 Jul 2001 04:25:45 -0700 (PDT) Received: from RRMAIL01.RADIOROUTER_NT ([63.103.94.23]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA05209 for ; Tue, 3 Jul 2001 05:25:43 -0600 (MDT) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id <317T3PJB>; Tue, 3 Jul 2001 07:25:43 -0400 Message-ID: <8C92E23A3E87FB479988285F9E22BE46054617@ftmail> From: George Tsirtsis To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] Ext. for FMIPv6 - comments Date: Tue, 3 Jul 2001 07:25: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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Kempf et. al. First of all I want to say that this is good work and introduces a mode of operation (using oCOA at nAR + no L3 messages over the air) that in the FMIPv6 draft is only covered partially as an error case...I guess Gopal might have already told you that we discussed this before and we did want to support it in FMIPv6 but run out of time and... steam :(...so your extension draft is very welcome indeed! I do have some disagreements/comments regarding the comparison section 2 but I am not going to get into nit picking mode..there isn't much point ;-) since I agree with the essence of the proposal. Instead I have one observation to make and more may follow after further digestion of the new draft... I think the time has come to create a mobility aware "L2 API" for IP...and yes, I know the IETF does not usually do APIs but I know enough people in this and other WGs that KNOW this is needed and are willing to make it happen. I actually wonder if there is anything done in this direction already and I am not aware of it...I do not have much time to follow IETF gossip these days due to an increasingly demanding day job... I think the draft already describes a number of triggers but we should work on their meaning so they are abstract enough to be applicable in different technologies and maybe add more as needed (hopefully not too many)...BTW, I am not suggesting you should do anything different in this draft...just that we discuss this issue independently of this draft as well. Regards George From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 3 08:50:20 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA05966 for ; Tue, 3 Jul 2001 08:50:20 -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 EAA23941; Tue, 3 Jul 2001 04:58: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 DAA07420; Tue, 3 Jul 2001 03:58:29 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f63Av7dP025070 for ; Tue, 3 Jul 2001 03:57:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f63Av7dK025069 for mobile-ip-dist; Tue, 3 Jul 2001 03:57: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.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f63Av3dP025062 for ; Tue, 3 Jul 2001 03:57:03 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA07319 for ; Tue, 3 Jul 2001 03:57:11 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA22218 for ; Tue, 3 Jul 2001 03:57:10 -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 GAA23102; Tue, 3 Jul 2001 06:56:25 -0400 (EDT) Message-Id: <200107031056.GAA23102@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-aaa-key-07.txt Date: Tue, 03 Jul 2001 06:56:24 -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 : AAA Registration Keys for Mobile IP Author(s) : C. Perkins, P. Calhoun Filename : draft-ietf-mobileip-aaa-key-07.txt Pages : 14 Date : 02-Jul-01 AAA servers, such as RADIUS and DIAMETER, are in use within the Internet today to provide authentication and authorization services for dial-up computers. Mobile IP requires strong authentication between the mobile node and its home agent. When the mobile node shares a security association with its home AAA server, however, it is possible to use that security association to create derivative security associations between the mobile node and its home agent, and again between the mobile node and the foreign agent currently offering connectivity to the mobile node. This document specifies extensions to the Mobile IP Registration Reply packet that can be used to create such security information at the mobile node. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-aaa-key-07.txt 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-key-07.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-key-07.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: <20010702161339.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-aaa-key-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-aaa-key-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010702161339.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 3 12:35:27 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11719 for ; Tue, 3 Jul 2001 12:35:26 -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 KAA17040; Tue, 3 Jul 2001 10:35: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 JAA19233; Tue, 3 Jul 2001 09:35:41 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f63GYldP025839 for ; Tue, 3 Jul 2001 09:34:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f63GYkui025838 for mobile-ip-dist; Tue, 3 Jul 2001 09: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 centralmail1.Central.Sun.COM (centralmail1.Central.Sun.COM [129.147.62.10]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f63GYhdP025831 for ; Tue, 3 Jul 2001 09:34:43 -0700 (PDT) Received: from esun1as-mm. (esun1as-mm.Central.Sun.COM [129.147.34.144]) by centralmail1.Central.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id KAA28259 for ; Tue, 3 Jul 2001 10:34:52 -0600 (MDT) Received: from sunyata.sun.com by esun1as-mm. (SMI-8.6/SMI-SVR4) id KAA06518; Tue, 3 Jul 2001 10:39:11 -0600 Message-Id: <5.0.0.25.0.20010703213035.01ed8850@localhost> X-Sender: 5883@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Tue, 03 Jul 2001 21:34:40 -0700 To: mobile-ip@sunroof.eng.sun.com, "'mobile-ip@sunroof.eng.sun.com'" From: James Kempf Subject: Re: [mobile-ip] Ext. for FMIPv6 - comments In-Reply-To: <8C92E23A3E87FB479988285F9E22BE46054617@ftmail> 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: Hi George, At 07:25 AM 7/3/01 -0400, George Tsirtsis wrote: >Hi Kempf et. al. > >First of all I want to say that this is good work and introduces a mode of >operation (using oCOA at nAR + no L3 messages over the air) that in the >FMIPv6 draft is only covered partially as an error case...I guess Gopal >might have already told you that we discussed this before and we did want to >support it in FMIPv6 but run out of time and... steam :(...so your extension >draft is very welcome indeed! > >I do have some disagreements/comments regarding the comparison section 2 but >I am not going to get into nit picking mode..there isn't much point ;-) >since I agree with the essence of the proposal. OK. Ultimately, I think it would be beneficial to have both drafts merged into a single fast handoff protocol. Actually, I even think it would be worthwhile to have the IPv6 fast handoff work merged into the MIPv6 draft itself, but that is probably impractical at the moment because the base MIPv6 draft is much further along. Perhaps an item for moving to Draft Standard. At that point, the comparison material can be dropped. It is only there as motivation for why we feel the alternative is necessary. >Instead I have one observation to make and more may follow after further >digestion of the new draft... > >I think the time has come to create a mobility aware "L2 API" for IP...and >yes, I know the IETF does not usually do APIs but I know enough people in >this and other WGs that KNOW this is needed and are willing to make it >happen. I actually wonder if there is anything done in this direction >already and I am not aware of it...I do not have much time to follow IETF >gossip these days due to an increasingly demanding day job... > >I think the draft already describes a number of triggers but we should work >on their meaning so they are abstract enough to be applicable in different >technologies and maybe add more as needed (hopefully not too many)...BTW, I >am not suggesting you should do anything different in this draft...just that >we discuss this issue independently of this draft as well. In fact, I am preparing just such a draft as we speak. The intent is to take the material from the BETH draft and from the FMIPv4 draft and perhaps add something on the link with Seamoby context transfer. jak From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 3 13:51:46 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13832 for ; Tue, 3 Jul 2001 13:51: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 LAA24822; Tue, 3 Jul 2001 11:52: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 KAA29284; Tue, 3 Jul 2001 10:52:18 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f63HpKdP026073 for ; Tue, 3 Jul 2001 10:51:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f63HpKVE026072 for mobile-ip-dist; Tue, 3 Jul 2001 10:51: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.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f63HpGdP026065 for ; Tue, 3 Jul 2001 10:51:16 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA29093 for ; Tue, 3 Jul 2001 10:51:26 -0700 (PDT) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA02083 for ; Tue, 3 Jul 2001 10:51:11 -0700 (PDT) Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21) id ; Tue, 3 Jul 2001 13:50:31 -0400 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] http://www.ietf.org/internet-drafts/draft-ietf-mobileip-gen-key-0 0.txt Date: Tue, 3 Jul 2001 13:50:28 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) 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: Hi folks, this is just a heads up for people who may have noticed this is just now a WG doc. We'd agreed to make it so over a year ago. It hadn't happened and the situation has just now been rectified. As you know AAA Keys which just finished last call is dependent on this, so we'll be issueing a last call on this presently. Phil From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 3 13:52:00 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13850 for ; Tue, 3 Jul 2001 13:51:59 -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 LAA25050; Tue, 3 Jul 2001 11:52: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 KAA29352; Tue, 3 Jul 2001 10:52:34 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f63HpldP026083 for ; Tue, 3 Jul 2001 10:51:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f63HplUX026082 for mobile-ip-dist; Tue, 3 Jul 2001 10:51: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f63HphdP026075 for ; Tue, 3 Jul 2001 10:51:43 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA27403 for ; Tue, 3 Jul 2001 10:51:52 -0700 (PDT) Received: from RRMAIL01.RADIOROUTER_NT ([63.103.94.23]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA02395 for ; Tue, 3 Jul 2001 10:51:52 -0700 (PDT) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id <317T3P8W>; Tue, 3 Jul 2001 13:51:46 -0400 Message-ID: <8C92E23A3E87FB479988285F9E22BE46054621@ftmail> From: George Tsirtsis To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Ext. for FMIPv6 - comments Date: Tue, 3 Jul 2001 13:51:45 -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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: James, You may be doing this already but anyway... In the draft about L2 triggers and in addition to the triggers of the FMIP docs could you please add the very obvious and very useful messages for the MN's API: - Link Down (L2 ID of link) - Link UP (L2 ID of link) The first is obvious and actually not that useful but the second is also obvious but very important....and with the L2ID, indicates the much neglected (in RFC2002bis and the like) movement detection...I bet this is going to be the most useful of all :-) I will say more when you get the draft done...but do let me know if you want input earlier... Regards George -----Original Message----- From: James Kempf [mailto:james.kempf@Sun.COM] Sent: Wednesday, July 04, 2001 5:35 AM To: mobile-ip@sunroof.eng.sun.com; 'mobile-ip@sunroof.eng.sun.com' Subject: Re: [mobile-ip] Ext. for FMIPv6 - comments Hi George, At 07:25 AM 7/3/01 -0400, George Tsirtsis wrote: >Hi Kempf et. al. > >First of all I want to say that this is good work and introduces a mode of >operation (using oCOA at nAR + no L3 messages over the air) that in the >FMIPv6 draft is only covered partially as an error case...I guess Gopal >might have already told you that we discussed this before and we did want to >support it in FMIPv6 but run out of time and... steam :(...so your extension >draft is very welcome indeed! > >I do have some disagreements/comments regarding the comparison section 2 but >I am not going to get into nit picking mode..there isn't much point ;-) >since I agree with the essence of the proposal. OK. Ultimately, I think it would be beneficial to have both drafts merged into a single fast handoff protocol. Actually, I even think it would be worthwhile to have the IPv6 fast handoff work merged into the MIPv6 draft itself, but that is probably impractical at the moment because the base MIPv6 draft is much further along. Perhaps an item for moving to Draft Standard. At that point, the comparison material can be dropped. It is only there as motivation for why we feel the alternative is necessary. >Instead I have one observation to make and more may follow after further >digestion of the new draft... > >I think the time has come to create a mobility aware "L2 API" for IP...and >yes, I know the IETF does not usually do APIs but I know enough people in >this and other WGs that KNOW this is needed and are willing to make it >happen. I actually wonder if there is anything done in this direction >already and I am not aware of it...I do not have much time to follow IETF >gossip these days due to an increasingly demanding day job... > >I think the draft already describes a number of triggers but we should work >on their meaning so they are abstract enough to be applicable in different >technologies and maybe add more as needed (hopefully not too many)...BTW, I >am not suggesting you should do anything different in this draft...just that >we discuss this issue independently of this draft as well. In fact, I am preparing just such a draft as we speak. The intent is to take the material from the BETH draft and from the FMIPv4 draft and perhaps add something on the link with Seamoby context transfer. jak From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 3 13:59:33 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14089 for ; Tue, 3 Jul 2001 13:59: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 MAA28726; Tue, 3 Jul 2001 12: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 LAA00612; Tue, 3 Jul 2001 11:00:07 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f63HxNdP026188 for ; Tue, 3 Jul 2001 10:59:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f63HxNut026187 for mobile-ip-dist; Tue, 3 Jul 2001 10:59: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 centralmail1.Central.Sun.COM (centralmail1.Central.Sun.COM [129.147.62.10]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f63HxKdP026180 for ; Tue, 3 Jul 2001 10:59:20 -0700 (PDT) Received: from esun1as-mm. (esun1as-mm.Central.Sun.COM [129.147.34.144]) by centralmail1.Central.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id LAA13813 for ; Tue, 3 Jul 2001 11:59:27 -0600 (MDT) Received: from sunyata.sun.com by esun1as-mm. (SMI-8.6/SMI-SVR4) id MAA08148; Tue, 3 Jul 2001 12:03:46 -0600 Message-Id: <5.0.0.25.0.20010703225813.01eefeb0@localhost> X-Sender: 5883@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Tue, 03 Jul 2001 22:59:07 -0700 To: mobile-ip@sunroof.eng.sun.com, "'mobile-ip@sunroof.eng.sun.com'" From: James Kempf Subject: RE: [mobile-ip] Ext. for FMIPv6 - comments In-Reply-To: <8C92E23A3E87FB479988285F9E22BE46054621@ftmail> 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: OK, I will add those. jak At 01:51 PM 7/3/01 -0400, George Tsirtsis wrote: >James, > >You may be doing this already but anyway... > >In the draft about L2 triggers and in addition to the triggers of the FMIP >docs could you please add the very obvious and very useful messages for the >MN's API: >- Link Down (L2 ID of link) >- Link UP (L2 ID of link) >The first is obvious and actually not that useful but the second is also >obvious but very important....and with the L2ID, indicates the much >neglected (in RFC2002bis and the like) movement detection...I bet this is >going to be the most useful of all :-) > >I will say more when you get the draft done...but do let me know if you want >input earlier... > >Regards >George >-----Original Message----- >From: James Kempf [mailto:james.kempf@Sun.COM] >Sent: Wednesday, July 04, 2001 5:35 AM >To: mobile-ip@sunroof.eng.sun.com; 'mobile-ip@sunroof.eng.sun.com' >Subject: Re: [mobile-ip] Ext. for FMIPv6 - comments > > >Hi George, > >At 07:25 AM 7/3/01 -0400, George Tsirtsis wrote: > >Hi Kempf et. al. > > > >First of all I want to say that this is good work and introduces a mode of > >operation (using oCOA at nAR + no L3 messages over the air) that in the > >FMIPv6 draft is only covered partially as an error case...I guess Gopal > >might have already told you that we discussed this before and we did want >to > >support it in FMIPv6 but run out of time and... steam :(...so your >extension > >draft is very welcome indeed! > > > >I do have some disagreements/comments regarding the comparison section 2 >but > >I am not going to get into nit picking mode..there isn't much point ;-) > >since I agree with the essence of the proposal. > >OK. Ultimately, I think it would be beneficial to have both drafts merged >into >a single fast handoff protocol. Actually, I even think it would be >worthwhile >to have the IPv6 fast handoff work merged into the MIPv6 draft itself, but >that is probably impractical at the moment because the base MIPv6 draft >is much further along. Perhaps an item for moving to Draft Standard. At >that point, the comparison material can be dropped. It is only there as >motivation for why we feel the alternative is necessary. > > >Instead I have one observation to make and more may follow after further > >digestion of the new draft... > > > >I think the time has come to create a mobility aware "L2 API" for IP...and > >yes, I know the IETF does not usually do APIs but I know enough people in > >this and other WGs that KNOW this is needed and are willing to make it > >happen. I actually wonder if there is anything done in this direction > >already and I am not aware of it...I do not have much time to follow IETF > >gossip these days due to an increasingly demanding day job... > > > >I think the draft already describes a number of triggers but we should work > >on their meaning so they are abstract enough to be applicable in different > >technologies and maybe add more as needed (hopefully not too many)...BTW, I > >am not suggesting you should do anything different in this draft...just >that > >we discuss this issue independently of this draft as well. > > >In fact, I am preparing just such a draft as we speak. The intent is to take >the material from the BETH draft and from the FMIPv4 draft and perhaps >add something on the link with Seamoby context transfer. > > jak From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 3 20:42:52 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA03437 for ; Tue, 3 Jul 2001 20:42:51 -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 RAA05836; Tue, 3 Jul 2001 17:34:07 -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 QAA00639; Tue, 3 Jul 2001 16:34:04 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f63NXBdP026425 for ; Tue, 3 Jul 2001 16:33:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f63NXBX7026424 for mobile-ip-dist; Tue, 3 Jul 2001 16:33: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.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f63NX7dP026417 for ; Tue, 3 Jul 2001 16:33:07 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA02126 for ; Tue, 3 Jul 2001 16:33:16 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA26520 for ; Tue, 3 Jul 2001 16:33: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 QAA05979; Tue, 3 Jul 2001 16:33:13 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f63NXC513363; Tue, 3 Jul 2001 16:33:12 -0700 X-mProtect: Tue, 3 Jul 2001 16:33:12 -0700 Nokia Silicon Valley Messaging Protection Received: from maxdialin14.iprg.nokia.com (205.226.20.244, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpd4nVRhc; Tue, 03 Jul 2001 16:33:07 PDT Message-ID: <3B42565B.394B91D5@iprg.nokia.com> Date: Tue, 03 Jul 2001 16:33:47 -0700 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Mattias Pettersson CC: TJ@Kniveton.com, "Ulf =?iso-8859-1?Q?Bj=F6rklund?=" , "mobile-ip@sunroof.eng.sun.com" Subject: Re: [Fwd: [mobile-ip] Mobile IPv6 clarifications] References: <3B3B2E46.50E17D25@era.ericsson.se> <3B3E90F1.3F4AC384@iprg.nokia.com> <3B4171B2.7098C705@era.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 Mattias, I thought the very clear message was given to the mobile-ip working group that we couldn't use AH as originally specified for authenticating Binding Updates. I can recount the reasons if need be. The working group has to decide ASAP how to resolve this issue about using IPsec for authentication. I'm not a security expert (although I've learned a lot) and it seems to me that either way can be made into a reasonable specification; the non-AH way has some epsilon better properties from my standpoint, but nothing huge. I'll happily re-revise the specification so that the authentication data fields are removed and use of AH is once again specified -- after the decision is made. The recently released draft specification assumes AH is NOT being used for the purpose, and I believe the disruption to existing implementations is substantial but not devastating, since the same subroutines can be called but just from different places. Your document drone, Charlie P. Mattias Pettersson wrote: > [This is a resend - wrong mailing list address in previous mail] > > "Charles E. Perkins" wrote: > > > > > > Our suggestion is that we instead define a new BA status code (139?) of > > > "sequence number too small". If the HA recieves a BU where T <= S, it > > > must instead send a BA back to MN with status = 139 and the sequence > > > number field set to S. The MN will retransmit the BU and now use T = S + > > > D (D=1 comes to mind as best choice). > > > > > > Does anyone see a security problem here? The HA only exposes what has > > > already been transmitted over the wire. The HA doesn't need to keep > > > state for this. > > > > I have followed your suggestion, and added the following text: > > > > If the mobile node sends a sequence number which is not greater than > > the sequence number from the last successful Binding Update, then > > the home agent MUST send back a Binding Acknowledgement with > > status code 141, and the last accepted sequence number in the > > Sequence Number field of the Binding Acknowledgement. > > > > Sorry, I need to bother you again. I've discussed this with a security > expert (thanks Andras!), and we could revise this slightly. > > There is a different approach to the sync problem, if I only had read > section 13.1 better or studied IPSec more. We don't need to beware of > replay attacks regarding the sequence number in the BU, as long as we > stick to IPSec protection, since IPSec has its own sequence number. > > The mobile node may, upon it's first registration, use sequence number > 0. If it gets no reply from the home agent, it may increase the sequence > number with 32768. That will assure that, as long as packets are > transmitted properly, either sequence number 0 or 32768 will be greater > that the previous sequence number the home agent possibly has stored. > This will assure that a registration will be accepted within one or two > BUs sent if the mobile node has lost sync with the home agent. > > > > 2. There should be a statement about sequence numbers. According to the > > > sequence number comparison method, the number 0 is smaller than 1 up to > > > 32767, but greater than 32768 up to 65535. If MN sends a BU with > > > sequence number 0 at some point, it can use all sequence numbers up to > > > 32767. After that, it must renegotiate SA with the peer (HA/CN), or it > > > will be exposed to a potential replay attack. > > > > I added the following text to the Security Considerations: > > > > After the Sequence Number space of the Binding Update and > > Binding Acknowledgement options has been exhausted, the > > mobile node and the home agent SHOULD renegotiate their > > security association in order to prevent any possibility > > of replay attacks. > > This part will not be needed if we stick to IPSec protection. However, > I'm not sure what protection will be used for the MN-CN relation. > > /Mattias From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 4 03:14:10 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA01722 for ; Wed, 4 Jul 2001 03:14: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 BAA29445; Wed, 4 Jul 2001 01:14:41 -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 AAA28927; Wed, 4 Jul 2001 00:14:38 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f647DjdP026899 for ; Wed, 4 Jul 2001 00:13:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f647DjgI026898 for mobile-ip-dist; Wed, 4 Jul 2001 00:13: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f647DfdP026891 for ; Wed, 4 Jul 2001 00:13:41 -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 AAA28878 for ; Wed, 4 Jul 2001 00:13:50 -0700 (PDT) From: john.loughney@nokia.com Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA28614 for ; Wed, 4 Jul 2001 01:14:48 -0600 (MDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f647E8I03954 for ; Wed, 4 Jul 2001 10:14:08 +0300 (EET DST) Received: from esebh24nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 4 Jul 2001 10:13:43 +0300 Received: by esebh24nok with Internet Mail Service (5.5.2652.78) id ; Wed, 4 Jul 2001 10:13:43 +0300 Message-ID: <01D91AFB08B6D211BFD00008C7EABAE10680B265@eseis04nok> To: mobile-ip@sunroof.eng.sun.com, seamoby@cdma-2000.org Subject: [mobile-ip] L2 API (WAS: Ext. for FMIPv6 - comments) Date: Wed, 4 Jul 2001 10:13:40 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) 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: Hi James, > In fact, I am preparing just such a draft as we speak. The > intent is to take the material from the BETH draft and from > the FMIPv4 draft and perhaps add something on the link with > Seamoby context transfer. I think this would be extremely worthwhile. It seems that SeaMoby is currently struggling over terminology about triggers, etc. with respect to handovers. I'd even suggest that interested parties from both MIP & SeaMoby get together in London to discuss how to move forward. Perhaps it would be a good thing if MIP & SeaMoby could work together on this issue - in order to assure that the resultant work suits both groups. best regards, John From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 4 12:39:29 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09157 for ; Wed, 4 Jul 2001 12:39:28 -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 JAA04627; Wed, 4 Jul 2001 09:39: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 JAA04114; Wed, 4 Jul 2001 09:39:46 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f64GcEdP027572 for ; Wed, 4 Jul 2001 09:38:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f64GcEmL027571 for mobile-ip-dist; Wed, 4 Jul 2001 09:38: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.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f64GcAdP027564 for ; Wed, 4 Jul 2001 09:38:10 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA28627 for ; Wed, 4 Jul 2001 09:38:19 -0700 (PDT) Received: from p-mail2.cnet.fr (p-mail2.rd.francetelecom.fr [193.49.124.32]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id JAA01359 for ; Wed, 4 Jul 2001 09:38:18 -0700 (PDT) Received: by p-voyageur.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19) id <3HW5N38H>; Wed, 4 Jul 2001 18:38:01 +0200 Received: from francetelecom.com (p-dico.rd.francetelecom.fr [139.100.18.135]) by p-grive.rd.francetelecom.fr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3HWWHTQK; Wed, 4 Jul 2001 18:38:00 +0200 Message-ID: <3B434629.EF448286@francetelecom.com> Date: Wed, 04 Jul 2001 18:36:57 +0200 From: Jean-Michel COMBES Organization: France =?iso-8859-1?Q?T=E9l=E9com?= R&D X-Mailer: Mozilla 4.75 [fr] (Windows NT 5.0; U) X-Accept-Language: fr MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [Fwd: [mobile-ip] Mobile IPv6 clarifications] References: <3B3B2E46.50E17D25@era.ericsson.se> <3B3E90F1.3F4AC384@iprg.nokia.com> <3B4171B2.7098C705@era.ericsson.se> <3B42565B.394B91D5@iprg.nokia.com> 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: X-MIME-Autoconverted: from 8bit to quoted-printable by mercury.Sun.COM id JAA04627 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA09157 Hi , Charlie Perkins a écrit : > Hello Mattias, > > I thought the very clear message was given to the mobile-ip working > group that we couldn't use AH as originally specified for authenticating > Binding Updates. I can recount the reasons if need be. JMC : I think it would be a good idea to summarize these reasons and why not to launch a concrete debate. > > The working group has to decide ASAP how to resolve this issue about > using IPsec for authentication. I'm not a security expert (although I've > learned a lot) and it seems to me that either way can be made into a > reasonable specification; the non-AH way has some epsilon better > properties from my standpoint, but nothing huge. JMC : ... and IPsec is native in IPv6. Are the reasons (of not using IPsec with MIPv6) so strong to make things more complex ? > I'll happily re-revise > the specification so that the authentication data fields are removed and > use of AH is once again specified -- after the decision is made. The > recently released draft specification assumes AH is NOT being used for > the purpose, and I believe the disruption to existing implementations is > substantial but not devastating, since the same subroutines can be > called but just from different places. > > Your document drone, > Charlie P. 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 From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 4 21:13:17 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA14016 for ; Wed, 4 Jul 2001 21:13:17 -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 SAA28030; Wed, 4 Jul 2001 18:13:47 -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 SAA04343; Wed, 4 Jul 2001 18:13:42 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f651C9dP027845 for ; Wed, 4 Jul 2001 18:12:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f651C9Ql027844 for mobile-ip-dist; Wed, 4 Jul 2001 18:12: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.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f651C5dP027837 for ; Wed, 4 Jul 2001 18:12:05 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA25673 for ; Wed, 4 Jul 2001 18:12:15 -0700 (PDT) Received: from telecom.samsung.co.kr ([165.213.221.4]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA21515 for ; Wed, 4 Jul 2001 18:12:13 -0700 (PDT) Received: from metro (a22414 [165.213.224.14]) by telecom.samsung.co.kr (8.9.3/8.9.3) with SMTP id KAA28073 for ; Thu, 5 Jul 2001 10:14:39 +0900 (KST) Message-ID: <004401c104ef$b4b15560$0ee0d5a5@telecom.samsung.co.kr> From: "junhyuk song" To: Subject: [mobile-ip] Mobile IPv4 Authentication Internt Draft revision 0.1 Date: Thu, 5 Jul 2001 10:13:30 +0900 Organization: cdma2000 system MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0040_01C1053B.2412B660" 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: This is a multi-part message in MIME format. ------=_NextPart_000_0040_01C1053B.2412B660 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0041_01C1053B.2412B660" ------=_NextPart_001_0041_01C1053B.2412B660 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SGkgQWxsLA0KDQpXZSByZWNlbnRseSBzdWJtaXR0ZWQgdGhlIHJldmlzaW9uIG9mIEludGVybmV0 IGRyYWZ0IGRyYWZ0IG9uICJNSVB2NCBBdXRoZW50aWNhdGlvbiBTaGFyZWQgU2VjcmV0IEdlbmVy YXRpb24uDQoNCmRyYWZ0LXNvbmctbW9iaWxlaXAtbWlwdjQtYXV0aC1zZWNnZW5lcmF0aW9uLTAx LnR4dCAgDQoNCg0KUmVnYXJkcywNCkpIIFNPTkcNCg0K ------=_NextPart_001_0041_01C1053B.2412B660 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA1LjUwLjQ1MjIuMTgwMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPg0KPERJVj48 Rk9OVCBzaXplPTI+SGkgQWxsLDxCUj48QlI+V2UgcmVjZW50bHkgc3VibWl0dGVkJm5ic3A7dGhl IHJldmlzaW9uJm5ic3A7b2YgDQpJbnRlcm5ldCBkcmFmdCZuYnNwO2RyYWZ0IG9uICJNSVB2NCBB dXRoZW50aWNhdGlvbiBTaGFyZWQgU2VjcmV0IA0KR2VuZXJhdGlvbi48L0ZPTlQ+PC9ESVY+DQo8 RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5k cmFmdC1zb25nLW1vYmlsZWlwLW1pcHY0LWF1dGgtc2VjZ2VuZXJhdGlvbi0wMS50eHQmbmJzcDsg DQo8QlI+PC9ESVY+PEZPTlQgc2l6ZT0zPjwvRk9OVD48L0ZPTlQ+DQo8RElWPjxGT05UIHNpemU9 Mj48Rk9OVCBzaXplPTM+PEZPTlQgc2l6ZT0yPjwvRk9OVD48Rk9OVCBzaXplPTI+PC9GT05UPjxG T05UIA0Kc2l6ZT0yPjwvRk9OVD48QlI+PC9GT05UPlJlZ2FyZHMsPC9GT05UPjwvRElWPg0KPERJ Vj48Rk9OVCBzaXplPTI+SkggU09ORzxCUj48L0RJVj48L0ZPTlQ+PC9GT05UPjwvRElWPjwvQk9E WT48L0hUTUw+DQo= ------=_NextPart_001_0041_01C1053B.2412B660-- ------=_NextPart_000_0040_01C1053B.2412B660 Content-Type: text/plain; name="draft-song-mobileip-mipv4-auth-secgeneration-01.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-song-mobileip-mipv4-auth-secgeneration-01.txt" Content-Transfer-Encoding: quoted-printable JunHyuk Song INTERNET DRAFT ChaeYong Chong 04 July 2001 Emfro Kim Samsung Elec. Dongkie Leigh SK telecom Raymond Hsu Qualcomm Inc. =20 Mobile IPv4 Authentication Shared key Generation draft-song-mobile-ipv4-auth-secgeneration-01.txt Status of This Memo Distribution of this memo is unlimited. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at: http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at: http://www.ietf.org/shadow.html. Abstract Mobile Node and Home Agent servers used in nowadays can provide authentication and authorization services mostly by the MN-HA and=20 MN-AAA Authentication. However, this is only possible if Mobile Node = previously share the same shared secrets with Home Agent and AAA. =20 Based on the assumption that the SA between Mobile Node and Home AAA=20 is strong, and the FAC issued from a Foreign Agent can provide=20 reasonable randomness. It is possible to use that security=20 association and the FAC to create a security associations between the = Mobile Node and its Home Agent. This document specifies a method=20 to dynamically create a shared secret used for MN-HA extension=20 between Mobile Node and Home Agent, based on MN-AAA shared secret,=20 NAI, and Foreign Agent Challenge. Song et al. Expires 04 January 2002 [Page 1] =0C Internet Draft Mobile IP MN-HA Authentication 04 July 2001 Contents Status of This Memo 1 Abstract 1 1. Introduction.......................................................3 1.2 Acronym.......................................................3 2. The parameters used for Dynamic MN-HA shared secret generation ....4 2.1 Mobile IP Agent Advertisement Challenge Extension.............4 2.2 Network Access Identifier (NAI)...............................4 2.3 Master MN-AAA shared secret...................................5 3. MN-HA shared secret creation.......................................5 3.1 MN-HA shared key creation by Mobile Node......................5 3.2 MN-HA shared key creation by AAA..............................5 4. Key Management.....................................................6 4.1 MN-HA key management.........................................7 4.2 DIAMETER consideration........................................8 5. Operation description..............................................9 6. Security Considerations............................................9 Appendix A - 3G Wireless example......................................9 Appendix B - MN-FA shared key consideration..........................11 References...........................................................11 Addresses............................................................12 Song et al. Expires 04 January 2002 [Page 2] =0C 1. Introduction In Mobile IP, AAA servers is in use nowadays to identify and=20 authenticate the mobile node by the Network Access Identifier (NAI)=20 [1] and MN-AAA authenticator [3]. In addition, the mobile node is required to have a security association with its home agent [2]. =20 Mobile IP defines an MN-HA authentication extension by which a mobile = node can authenticate itself to a home agent. However it is not=20 currently defined how Mobile Node, Home Agent and AAA obtain=20 the shared secrets used in computing MN-AAA and MN-HA=20 authenticator. Based on the assumption that the SA between Mobile=20 Node and Home AAA is strong, and the FAC issued from a Foreign Agent=20 can provide reasonable randomness. It is possible to use that=20 security association and FAC to create security associations between=20 the Mobile Node and its Home Agent. This document specifies a method to dynamically a create shared secret used for MN-HA extension = between Mobile Node and Home Agent, based on the MN-AAA shared=20 secret, NAI, and Foreign Agent Challenge. =20 1.1 Acronym MN : Mobile Node FA : Foreign Agent HA : Home Agent AAA : Authentication, Authorization , and Accounting AAAH : Home AAA AAAF : Foreign AAA AR : Access Request AA : Access Accept FAC : Foreign Agent Challenge RRQ : Mobile IP Registration Request RRP : Mobile IP Registration Reply SPI : Security Parameter Index Key : Shared Secret PDSN : Packet Data Serving Node =20 Song et al. Expires 04 January 2002 [Page 3] =0C 2. The parameters used for Dynamic MN-HA shared secret generation This section defines the parameters used for the session MN-AAA=20 shared secret and MN-HA shared secret generation. 2.1 Mobile IP Agent Advertisement Challenge Extension Currently Foreign Agent Challenge extension [3] is defined and in use = for 3G wireless system. That challenge extension is sent with the=20 Agent Advertisement by the Foreign Agent, in order to be used by=20 Mobile Node to create the MN-AAA authentication extension for its=20 Mobile IP Registration Request. =20 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Challenge ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: The Challenge Extension [3] Type 24 Length The length of the Challenge value in bytes; SHOULD be at least 4 Challenge A random value that SHOULD be at least 32 bits. The challenge extension is used to give the randomness for dynamic=20 MN-HA shared secret to avoid possible replay attack. 2.2 Network Access Identifier (NAI) The Network Access Identifier (NAI) is the userID. The Mobile NAI extension in Mobile IP registration request is used=20 for AAA to identify the clients. =20 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | MN-NAI ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: The Mobile Node NAI Extension [9] Type 131 (skippable) Length The length in bytes of the MN-NAI field MN-NAI A string in the NAI format defined in [1] Song et al. Expires 04 January 2002 [Page 4] =0C 2.3 MN-AAA shared secret The MN-AAA shared secret is the key used to compute the MN-AAA=20 authentication extension. =20 =20 3. MN-HA shared secret creation This section describes the MN-HA shared secret creation by the Mobile = Node and AAA. 3.1 MN-HA key creation by Mobile Node 1. Mobile Node identifies Foreign Agent Challenge in Mobile IP Agent Advertisement [3].=20 =20 2. The mobile node uses the FA Challenge, its own NAI, and the=20 MN-AAA shared secret to calculate: MN-HA shared key =3D HMAC-MD5(MN-AAA-key | FA Challenge |=20 MN NAI | MN-AAA-key) =20 3.2 MN-HA shared key creation by AAA 1. AAA identifies Foreign Agent Challenge and the MN's NAI from the AAA message. 2. AAA uses the FA Challenge, MN's NAI, and MN-AAA shared=20 secret to calculate: MN-HA shared key =3D HMAC-MD5(MN-AAA-key | FA Challenge |=20 MN NAI | MN-AAA-key) Song et al. Expires 04 January 2002 [Page 5] =0C 4. Key Management =20 MN-HA shared key lifetime management is OPTIONAL. It MAY be used to increase the entropy of MN-HA shared key, or reduce the MN-HA=20 shared key fetching between the HA and the AAA server if RADIUS is=20 used. =20 (Note: In real time, it in not likely MN-HA shared secret is ever=20 refreshed during MIP session, because MN-HA shared secret is=20 session specific, and MN-HA shared secret lifetime must be reasonably greater than MIP re-registration lifetime. =20 The lifetime of MN-HA shared secret is operator configurable. MN-HA shared secret may be refreshed on every re-registration=20 or used for until user terminate the session.) =20 Mobile Node MAY optionally configured with a lifetime of MN-HA shared = secret. Home Agent MAY optionally have a lifetime of MN-HA shared=20 key, as received from AAAH along with MN-HA shared key, according to=20 a user profile. =20 The length of the lifetime is operator configurable and it SHOULD be=20 greater than the MIP re-registration time. Home Agent MUST fetch the pre-fixed MN-HA shared secret lifetime and MN-HA shared secret from=20 AAAH. The Identification field in Mobile IP Registration Request is used=20 for preventing possible replay attack and delayed duplicate message=20 to arrive at the home agent. It contains mandatory timestamp and=20 optional nonce [2]. This Identification field in Mobile IP=20 Registration Request is used to let Home Agent to check the validity=20 of MN-HA shared secret. =20 Song et al. Expires 04 January 2002 [Page 6] =0C Below is 64 bits Identification field of MIP RRQ message. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Identification + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 When MN creates MN-HA shared secret, the timestamp is issued. The timestamp of MN-HA shared key is placed in the high-order 32 bits of MIP RRQ Identification field. This high order bit of=20 Identification field is from MN's own time of day [2]. =20 The high-order 32 bits of MIP RRQ Identification field is used for the HA to configure the expiration time for the MN-HA shared key. =20 The low-order 32 bits of MIP RRQ Identification field MAY be=20 optionally used to enable FA and HA to refresh shared key. 4.1 MN-HA shared key lifetime Management for Dynamic Mobile IP Home=20 Agent Allocation case with RADIUS based AAA (see Appendix A) =20 When HA receives RRQ, the HA fetches MN-HA shared secret from AAA in=20 the following case 1 and 3 =20 1. New MIP registration case. In this case, there is no previously assigned MN-HA shared secret=20 for the matching NAI or MN IP address. Even if there is a=20 previously assigned MN-HA shared secret for the matching NAI or MN=20 IP address, HA should not use that MN-HA shared key, because it is=20 new Mobile IP session. The HA SHOULD use the home agent field or the home address field in=20 the MIP RRQ to differentiate the new MIP registration case from the MIP re-registration case. If the home agent field or home address=20 field of MIP RRQ is equal to "0.0.0.0", the HA identifies this as a new MIP registration. =20 Mobile Node MAY optionally use the low-order 32 bits of MIP RRQ Identification field as the indicator whether MN-HA shared secret is refreshed. If the low-order 32 bits of MIP RRQ Identification field is equal to current MN-HA shared secret's timestamp, HA MAY=20 identify this as a new MIP registration or MN-HA shared secret is=20 currently refreshed.=20 =20 Upon identifying MIP RRQ as a new registration message, HA MUST=20 send AAA message to fetch MN-HA shared secret and its lifetime. Song et al. Expires 04 January 2002 [Page 7] =0C 2. Re-registration case with valid MN-HA shared key. In this case, there is a previously assigned MN-HA shared secret=20 for the matching NAI or MN IP address and the lifetime of MN-HA=20 shared key is valid. =20 Upon the receipt of an MIP RRQ, if there is previously assigned=20 MN-HA shared key and it is not new MIP registration case, the Home=20 Agent MUST check the validity of the lifetime of MN-HA shared key. If the high order bit of Identification field is smaller than=20 the expected lifetime of MN-HA shared secret, Home Agent=20 shall authenticate RRQ with stored MN-HA shared secret, and send RRP=20 after necessary MIP processing. The expected lifetime of=20 MN-HA is derived by adding a lifetime of MN-HA shared key and the=20 timestamp of MN-HA shared key. 3. Re-registration case with expired MN-HA shared key lifetime. =20 In this case, there is previously assigned MN-HA shared secret for=20 matching NAI or MN IP address. But the lifetime of stored MN-HA=20 shared key is already expired. Upon the receipt of an MIP RRQ, the HA MUST check if it is an=20 initial MIP registration or MIP re-registration. In the case of=20 MIP re-registration, the HA shall check whether or not the lifetime of MN-HA shared key is expired. If the high order bit of=20 Identification field is greater than the expected lifetime of MN-HA=20 shared secret, HA shall send AAA message to fetch MN-HA shared=20 secret and its lifetime. After the receipt of MN-HA shared secret and = lifetime, Home Agent MUST authenticate the MIP RRQ, and the HA shall=20 set the timer for MN-HA shared secret according to the timestamp in=20 the high-order 32 bits of the MIP RRQ Identification field.=20 =20 4.2 DIAMETER consideration For DIAMETER based AAA, the MN-HA shared secret key management=20 described in section 4.1 may not be needed for home agent. Because MN will decide the lifetime of updating MN-HA shared secret, and the=20 updated MN-HA shared key will be delivered to HA by DIAMETER HAR =20 message. =20 Song et al. Expires 04 January 2002 [Page 8] =0C 5. Operation description Home Agent MUST obtain MN-HA shared secret from AAA. The MN-HA=20 shared key is session specific, and shall be used until termination=20 of MIP session or MIP re-registration. =20 The home agent MAY optionally set the lifetime of MN-HA shared=20 secret. The lifetime of MN-HA shared key is operator configurable. =20 The key fetching method varies from RADIUS [7] to DIAMETER [8] and it = is outside the scope of this document. 6. Security Considerations The key generation method described in this document provides the=20 reasonable level of security by dynamically creating the=20 shared secrets. Since this key generation method depends on the key materials(i.e., NAI, FAC, MN-AAA shared secret) that are=20 available already in Mobile IP, it does not require any new key=20 materials. =20 =20 Foreign Agent Challenge is used to avoid replay attack and enhance=20 entropy. It is the same FAC that used for MN-AAA authentication=20 extension generation. The randomness of FAC depends on random=20 number generator in the Foreign Agent. However, if FA is malicious=20 and is sending static FAC continuously rather than random FAC,=20 "chosen cipher text attack" is possible. Although the cost and time to reverse engineering the value generated by MD5 is not practical,=20 it is not impossible. Therefore in order to counter this potential attack, FAC extension sent from the FA to AAAF SHOULD be=20 authenticated by the shared secret between the FA and AAAF.=20 Furthermore, it is assumed that the communication between AAAF and AAAH is secured. Based on the assumptions, the randomness of FAC is guaranteed;=20 therefore, the security of this method is as good as the MN-AAA=20 authentication based on RFC-3012 =20 Appendix A - 3G Wireless Example In 3GPP2 Wireless system, both RADIUS and DIAMETER is supported as=20 the AAA protocols. This document suggests a method of dynamically creating and maintaining the MN-HA shared secret. This scheme is=20 especially beneficial for the case of dynamic HA allocation. =20 Song et al. Expires 04 January 2002 [Page 9] =0C In 3G wireless systems, if each Mobile Node and Home Agent has the=20 same static shared secret for MN-HA authentication, it would be=20 problematic for dynamic HA allocation because each HA generally has=20 no knowledge of all the MN-HA shared secrets. On the other hand,=20 configuring all the HAs with all the MN-HA shared secrets in an=20 administration domain raises concerns in security and scalability. +--------------+ AR +--------------+ | |------------------>| | | AAAF | | AAAH | | RADIUS |<------------------| RADIUS | +--------------+ AA +--------------+ ^ | ^ | | | | | AR | | AA AR | | AA | v | v +-----+ +--------------+ +--------------+ | | RRQ | | RRQ | | | MS |-------->| PDSN/FA |------------------>| Home Agent | | |<--------| |<------------------| | +-----+ RRP +--------------+ RRP +--------------+ Figure 3 (3G Wireless Network) If this scheme applied to the 3GPP2 Wireless Network in figure 3,=20 MS shall create the MN-HA shared secret by running HMAC-MD5 with=20 input of its NAI, Foreign Agent challenge, and MN-AAA key. =20 In the case of RADIUS based AAA, two scenarios MAY be possible depends on how PDSN is configured. Currently IS-835 only optionally=20 support MN-AAA authentication in case of MIP re-registration. 1. PDSN configured to send Access Request message extension to AAAH=20 for MN-AAA authentication=20 2. PDSN configured not to send Access Request message to AAAH for=20 MN-HA authentication =20 In the first case, the mobile will create the MN-HA shared key with input of NAI, FAC, and MN-AAA shared key. The mobile shall send RRQ with "0.0.0.0" in the Home Agent Address field. Upon successfully completing the MN-AAA authentication, AAAH shall generate the MN-HA=20 shared secret by using the same parameters that the MS used. Home=20 Agent MAY fetch MN-HA shared key for each re-registration happens=20 or MAY cache MN-HA shared key during certain period of time defined=20 in the lifetime of MN-HA shared secret. Song et al. Expires 04 January 2002 [Page 10] =0C=20 In the second case, MIP re-registration totally depends on the MN-HA=20 authentication, since MN-AAA authentication shall only performed for=20 the first MIP registration. The mobile will create the MN-HA shared=20 key with input of NAI, FAC, and MN-AAA shared key. The mobile shall=20 send RRQ with "0.0.0.0" in the Home Agent Address field. After=20 successful MN-AAA authentication by AAAH, HA shall receive RRQ from=20 PDSN. When HA receives RRQ, HA SHOULD send RADIUS Access Request=20 message with NAI and FAC. Upon receiving the Access Request, AAA SHOULD generate the MN-HA shared key by using the same parameters=20 that the MS used. HA will receive MN-HA shared key along with=20 lifetime. HA MAY optionally sends fetching message along with FAC=20 and NAI upon every re-registration happens or MAY cache MN-HA shared=20 key during certain period of time defined in the lifetime of MN-HA=20 shared secret. The main difference from the first case is that HA=20 identifies FAC from RRQ and sends Access Request with FAC to AAAH.=20 =20 In the case of using DIAMETER protocol, the MN-HA Shared Secret will=20 be sent to HA by the HAR message. [10] =20 Appendix B - MN-FA shared key consideration =20 Mobile Node and AAA now can easily derive MN-FA shared key by running = the HMAC-MD5 with input of MN-HA shared secret, FA's IP address, FAC and MN's NAI. This method has better scalability and less=20 administrative effort than provisioning MN-FA shared secrets. =20 In face it is administrative prohibitive to provision all MNs and FAs = with static shared secrets.=20 =20 References [1] B. Aboba and M. Beadles. The Network Access Identifier. Request for Comments (Proposed Standard) 2486, Internet Engineering Task Force, January 1999. =20 [2] C. Perkins. IP Mobility Support. Request for Comments (Proposed Standard) 2002, Internet Engineering Task Force, October 1996. [3] P. Calhoun and C. E. Perkins. Mobile IP Foreign Agent Challenge/Response Extension. Request for Comments (Proposed Standard) 3012, Internet Engineering Task Force, January 2000. [4] H. Krawczyk, M. Bellare, and R. Canetti. HMAC: Keyed-Hashing for Message Authentication. Request for Comments (Informational) 2104, Internet Engineering Task Force, February 1997. Song et al. Expires 04 January 2002 [Page 11] =0C [5] P. Calhoun and C. E. Perkins. AAA Registration Keys for=20 Mobile IP Internet Draft, Internet Engineering Task Force. draft-ietf-mobileip-aaa-key-06.txt (work in progress) January 2001. [6] H. Krawczyk, M. Bellare, and R. Canetti. HMAC: Keyed-Hashing for Message Authentication. Request for Comments (Informational) 2104, Internet Engineering Task Force, February 1997. [7] C. Rigney, A. Rubens, W. Simpson, and S. Willens. Remote Authentication Dial In User Service (RADIUS). Request for Comments (Proposed Standard) 2865, Internet Engineering Task Force, June 2000. [8] P. Calhoun, A. Rubens, H. Akhtar, and E. Guttman. DIAMETER Base Protocol (work in progress). Internet Draft, Internet Engineering Task Force. draft-ietf-aaa-diameter-03.txt, May 2001. [9] P. Calhoun and C. E. Perkins. Mobile IP Network Access=20 Identifier Extension for IPv4. Request for Comments=20 (Proposed Standard) 2794, Internet Engineering Task Force, March 2000 [10] P. Calhoun and C. E. Perkins. Diamter Mobile IP Extensions Internet Draft, Internet Engineering Task Force. draft-ietf-aaa-diameter-mobileip-01.txt Addresses Questions about this memo can be directed to the authors: JUNHYUK SONG DongKie Leigh =20 SAMSUNG ELECTRONICS. SK TELECOM Mobile Development Team Core Network Development Team Network Systems Division Network R&D Center =09 Phone: +82-31-779-6822 Phone +82-2-829-4640 Email: santajun@lycos.co.kr Email: galahad@netsgo.com FAX: +82-31-7798769 FAX:+82-2-829-4612 Raymond Hsu CHAE YONG CHONG Qualcomm Inc. SAMSUNG ELECTRONICS. Corporate R&D Mobile Development Team Phone: 1-858-651-3623 Network Systems Division Email: rhsu@qualcomm.com Phone: +82-31-779-6822 FAX: 1-858-658-5006 Email:cychong@samsung.com Emfro ZuYong Kim SAMSUNG ELECTRONICS. Mobile Development Team Phone: +82-31-779-6764 emfro@samsung.co.kr Song et al. Expires 04 January 2002 [Page 12] =0C ------=_NextPart_000_0040_01C1053B.2412B660-- From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 5 06:57:28 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA06843 for ; Thu, 5 Jul 2001 06:57:27 -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 DAA11843; Thu, 5 Jul 2001 03:58:00 -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 DAA18122; Thu, 5 Jul 2001 03:57:48 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f65ArodP028368 for ; Thu, 5 Jul 2001 03:53:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f65ArnJh028367 for mobile-ip-dist; Thu, 5 Jul 2001 03:53: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.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f65ArjdP028360 for ; Thu, 5 Jul 2001 03:53:45 -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 DAA24364 for ; Thu, 5 Jul 2001 03:53:53 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA05579 for ; Thu, 5 Jul 2001 04:53:51 -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 GAA06466; Thu, 5 Jul 2001 06:53:07 -0400 (EDT) Message-Id: <200107051053.GAA06466@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: mobile-ip@sunroof.eng.sun.com, nat@ietf.org From: Internet-Drafts@ietf.org Subject: [mobile-ip] I-D ACTION:draft-levkowetz-mobileip-nat-tunnel-00.txt Date: Thu, 05 Jul 2001 06:53:07 -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. Title : NAT Traversal for Mobile IP using UDP Tunnelling Author(s) : O. Levkowetz, J. Forslow, H. Sjostrand Filename : draft-levkowetz-mobileip-nat-tunnel-00.txt Pages : 16 Date : 03-Jul-01 Mobile IP is now being deployed, providing connectivity to mobile users. This is happening well ahead of the widespread use of IPv6, which may not have been expected at the time when the Mobile IP standard was originally formulated. At the same time, networks with private address spaces are proliferating, using NAT devices to reach the public internet. Today NATs are widely deployed in home gateways, as well as in other locations likely to be used by mobile users, such as hotels. The result is that MIP-NAT incompatibility issues have become a major barrier to deployment of Mobile IP in one of its principal uses. This draft describes a known incompatibility between NAT and Mobile IP, and also describes a possible solution using Mobile IP's vendor specific extensions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-levkowetz-mobileip-nat-tunnel-00.txt 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-levkowetz-mobileip-nat-tunnel-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-levkowetz-mobileip-nat-tunnel-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: <20010703124608.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-levkowetz-mobileip-nat-tunnel-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-levkowetz-mobileip-nat-tunnel-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010703124608.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 5 06:57:32 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA06860 for ; Thu, 5 Jul 2001 06:57: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 DAA11854; Thu, 5 Jul 2001 03:58:01 -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 DAA18121; Thu, 5 Jul 2001 03:57:47 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f65As6dP028378 for ; Thu, 5 Jul 2001 03:54:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f65As5AS028377 for mobile-ip-dist; Thu, 5 Jul 2001 03:54: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f65As1dP028370 for ; Thu, 5 Jul 2001 03:54:01 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA17741 for ; Thu, 5 Jul 2001 03:54:09 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA18929 for ; Thu, 5 Jul 2001 03:54:08 -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 GAA06498; Thu, 5 Jul 2001 06:53:22 -0400 (EDT) Message-Id: <200107051053.GAA06498@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: mobile-ip@sunroof.eng.sun.com, nat@ietf.org From: Internet-Drafts@ietf.org Subject: [mobile-ip] I-D ACTION:draft-levkowetz-mobileip-nat-ipu-tunnel-00.txt Date: Thu, 05 Jul 2001 06:53:22 -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. Title : ipUnplugged's NAT Traversal for Mobile IP Author(s) : O. Levkowetz, J. Forslow, H. Sjostrand Filename : draft-levkowetz-mobileip-nat-ipu-tunnel-00.txt Pages : 6 Date : 03-Jul-01 Mobile IP is now being deployed, providing connectivity to mobile users. This is happening well ahead of the widespread use of IPv6, which may not have been expected at the time when the Mobile IP standard was originally formulated. At the same time, networks with private address spaces are proliferating, using NAT devices to reach the public internet. Today NATs are widely deployed in home gateways, as well as in other locations likely to be used by mobile users, such as hotels. The result is that MIP-NAT incompatibility issues have become a major barrier to deployment of Mobile IP in one of its principal uses. This draft describes a known incompatibility between NAT and Mobile IP, and also describes a possible solution. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-levkowetz-mobileip-nat-ipu-tunnel-00.txt 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-levkowetz-mobileip-nat-ipu-tunnel-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-levkowetz-mobileip-nat-ipu-tunnel-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: <20010703124625.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-levkowetz-mobileip-nat-ipu-tunnel-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-levkowetz-mobileip-nat-ipu-tunnel-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010703124625.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 5 10:30:50 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA14424 for ; Thu, 5 Jul 2001 10:30:49 -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 IAA08640; Thu, 5 Jul 2001 08:31: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 HAA10718; Thu, 5 Jul 2001 07:31:15 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f65ET6dP028958 for ; Thu, 5 Jul 2001 07:29:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f65ET6J1028957 for mobile-ip-dist; Thu, 5 Jul 2001 07:29: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.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f65ET2dP028950 for ; Thu, 5 Jul 2001 07:29:02 -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 HAA10412 for ; Thu, 5 Jul 2001 07:29:10 -0700 (PDT) Received: from netmail2.alcatel.com (netmail2.alcatel.com [128.251.168.51]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA07279 for ; Thu, 5 Jul 2001 08:29:08 -0600 (MDT) Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6]) by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id JAA25752 for ; Thu, 5 Jul 2001 09:29:05 -0500 (CDT) Received: from usa.alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f65ET5D19038 for ; Thu, 5 Jul 2001 09:29:05 -0500 (CDT) Message-ID: <3B446AEA.CCB65CC0@usa.alcatel.com> Date: Thu, 05 Jul 2001 09:26:03 -0400 From: Behcet Sarikaya X-Mailer: Mozilla 4.76 [en]C-CCK-MCD BDPjm-Sony3 (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] L2 API (WAS: Ext. for FMIPv6 - comments) References: <01D91AFB08B6D211BFD00008C7EABAE10680B265@eseis04nok> 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 John, john.loughney@nokia.com wrote: > I think this would be extremely worthwhile. It seems that > SeaMoby is currently struggling over terminology about > triggers, etc. with respect to handovers. I'd even suggest > that interested parties from both MIP & SeaMoby get together > in London to discuss how to move forward. Perhaps it would > be a good thing if MIP & SeaMoby could work together on this > issue - in order to assure that the resultant work suits both > groups. > > best regards, > John No, not another design team. Dijsktra once said design teams are considered harmful Design teams are 3GPP, 3GPP2, TIA, etc. not IETF. Regards, -- Behcet From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 5 11:03:28 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15813 for ; Thu, 5 Jul 2001 11:03: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 JAA25041; Thu, 5 Jul 2001 09:04:03 -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 IAA13370; Thu, 5 Jul 2001 08:04:01 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f65F1gdP029035 for ; Thu, 5 Jul 2001 08:01:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f65F1gOj029034 for mobile-ip-dist; Thu, 5 Jul 2001 08:01: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.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f65F1cdP029027 for ; Thu, 5 Jul 2001 08:01:39 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA23803 for ; Thu, 5 Jul 2001 08:01:47 -0700 (PDT) Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA05137 for ; Thu, 5 Jul 2001 08:01:46 -0700 (PDT) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate4.mot.com (motgate4 2.1) with ESMTP id IAA12545 for ; Thu, 5 Jul 2001 08:01:46 -0700 (MST)] Received: [from m-il06-r4.mot.com (m-il06-r4.mot.com [129.188.137.196]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id HAA09932 for ; Thu, 5 Jul 2001 07:54:43 -0700 (MST)] Received: from [140.101.173.9] by m-il06-r4.mot.com with ESMTP for mobile-ip@sunroof.eng.sun.com; Thu, 5 Jul 2001 10:01:44 -0500 Received: (from root@localhost) by zorglub.crm.mot.com (8.8.8/8.8.8/crm-1.6) id RAA07930 for mobile-ip@sunroof.eng.sun.com.DELIVER; Thu, 5 Jul 2001 17:01:42 +0200 (METDST) Received: from crm.mot.com (nero.crm.mot.com [140.101.173.36]) by zorglub.crm.mot.com (8.8.8/8.8.8/crm-1.6) with ESMTP id RAA07896; Thu, 5 Jul 2001 17:01:42 +0200 (METDST) Message-Id: <3B448146.5112F7C9@crm.mot.com> Date: Thu, 05 Jul 2001 17:01:26 +0200 From: Alexis Olivereau Organization: Centre de Recherche de Motorola - Paris X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com, Charlie Perkins CC: Alexis Subject: Re: [Fwd: [mobile-ip] Mobile IPv6 clarifications] References: <3B3B2E46.50E17D25@era.ericsson.se> <3B3E90F1.3F4AC384@iprg.nokia.com> <3B4171B2.7098C705@era.ericsson.se> <3B42565B.394B91D5@iprg.nokia.com> Content-Type: multipart/mixed; boundary="------------226661FEA5F4321E71855685" 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. --------------226661FEA5F4321E71855685 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Charlie, Frankly, I would be quite reluctant to discard IPsec that way, not only from a 'existing implementations' point of view but also taking into consideration the future enhancements that are likely to be added to MIP in the next few years. I am quite convinced that more powerful terminals, general AAA framework, will re-enable the use of IPsec (let's say ESP/NULL) to secure BUs and BAcks. Shouldn't we consider these future prospects before such a decision? IKE is heavy and PKI is not scalable, that is quite a consensus. On the other hand BAKE (for example :-) is scalable but the key it provides is not as secure as the one IKE provides. As an example of alternative, I would like to make a very basic proposal that will neither modify heavily MIP nor IPsec. The idea is to let IPsec use the key that BAKE (for example :-) gives. Now this can not be done without telling the upper layer about the (poor) level of security this Security Association would provide. I suggest that we use a new protocol flag to mark the SA as a MIP one. For example, along with MD5, SHA1, SHA2 algorithms that ESP uses for its authentication part, we would add MIP-MD5 as if it was a new authentication algorithm. Concretely the MN-CN key could be copied into IPsec part within a new SA after its distribution has taken place. SPI and SN would have to be synchronized, let's say during key distribution. And the algorithm would just be marked as 'MIP-MD5'... Anyway, the point here is not to write new scenarios, but to emphasize some other ways that I think we have not paid enough attention to: splitting Mobility from Security would surely discredit the very reason for IPv6... No need to say that comments are welcomed! Regards, Alexis Charlie Perkins wrote: > > Hello Mattias, > > I thought the very clear message was given to the mobile-ip working > group that we couldn't use AH as originally specified for authenticating > Binding Updates. I can recount the reasons if need be. > > The working group has to decide ASAP how to resolve this issue about > using IPsec for authentication. I'm not a security expert (although I've > learned a lot) and it seems to me that either way can be made into a > reasonable specification; the non-AH way has some epsilon better > properties from my standpoint, but nothing huge. I'll happily re-revise > the specification so that the authentication data fields are removed and > use of AH is once again specified -- after the decision is made. The > recently released draft specification assumes AH is NOT being used for > the purpose, and I believe the disruption to existing implementations is > substantial but not devastating, since the same subroutines can be > called but just from different places. > > Your document drone, > Charlie P. > > Mattias Pettersson wrote: > > > [This is a resend - wrong mailing list address in previous mail] > > > > "Charles E. Perkins" wrote: > > > > > > > > > Our suggestion is that we instead define a new BA status code (139?) of > > > > "sequence number too small". If the HA recieves a BU where T <= S, it > > > > must instead send a BA back to MN with status = 139 and the sequence > > > > number field set to S. The MN will retransmit the BU and now use T = S + > > > > D (D=1 comes to mind as best choice). > > > > > > > > Does anyone see a security problem here? The HA only exposes what has > > > > already been transmitted over the wire. The HA doesn't need to keep > > > > state for this. > > > > > > I have followed your suggestion, and added the following text: > > > > > > If the mobile node sends a sequence number which is not greater than > > > the sequence number from the last successful Binding Update, then > > > the home agent MUST send back a Binding Acknowledgement with > > > status code 141, and the last accepted sequence number in the > > > Sequence Number field of the Binding Acknowledgement. > > > > > > > Sorry, I need to bother you again. I've discussed this with a security > > expert (thanks Andras!), and we could revise this slightly. > > > > There is a different approach to the sync problem, if I only had read > > section 13.1 better or studied IPSec more. We don't need to beware of > > replay attacks regarding the sequence number in the BU, as long as we > > stick to IPSec protection, since IPSec has its own sequence number. > > > > The mobile node may, upon it's first registration, use sequence number > > 0. If it gets no reply from the home agent, it may increase the sequence > > number with 32768. That will assure that, as long as packets are > > transmitted properly, either sequence number 0 or 32768 will be greater > > that the previous sequence number the home agent possibly has stored. > > This will assure that a registration will be accepted within one or two > > BUs sent if the mobile node has lost sync with the home agent. > > > > > > 2. There should be a statement about sequence numbers. According to the > > > > sequence number comparison method, the number 0 is smaller than 1 up to > > > > 32767, but greater than 32768 up to 65535. If MN sends a BU with > > > > sequence number 0 at some point, it can use all sequence numbers up to > > > > 32767. After that, it must renegotiate SA with the peer (HA/CN), or it > > > > will be exposed to a potential replay attack. > > > > > > I added the following text to the Security Considerations: > > > > > > After the Sequence Number space of the Binding Update and > > > Binding Acknowledgement options has been exhausted, the > > > mobile node and the home agent SHOULD renegotiate their > > > security association in order to prevent any possibility > > > of replay attacks. > > > > This part will not be needed if we stick to IPSec protection. However, > > I'm not sure what protection will be used for the MN-CN relation. > > > > /Mattias --------------226661FEA5F4321E71855685 Content-Type: text/x-vcard; charset=us-ascii; name="Alexis.Olivereau.vcf" Content-Description: Card for Alexis Olivereau Content-Disposition: attachment; filename="Alexis.Olivereau.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Olivereau;Alexis tel;fax:+33 (0)1 69 35 25 01 tel;work:+33 (0)1 69 35 25 16 x-mozilla-html:TRUE org:MOTOROLA LABS;Networking and Applications Lab version:2.1 email;internet:Alexis.Olivereau@crm.mot.com title:Research Engineer adr;quoted-printable:;;Immeuble "Le Columbia"=0D=0AEspace Technologique St Aubin=0D=0A;Gif-sur-Yvette;;91193;FRANCE fn:Alexis Olivereau end:vcard --------------226661FEA5F4321E71855685-- From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 5 11:40:26 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16943 for ; Thu, 5 Jul 2001 11:40:25 -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 IAA21366; Thu, 5 Jul 2001 08:41: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 IAA16976; Thu, 5 Jul 2001 08:40:56 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f65FcXdP029121 for ; Thu, 5 Jul 2001 08:38:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f65FcWM2029120 for mobile-ip-dist; Thu, 5 Jul 2001 08:38: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.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f65FcSdP029113 for ; Thu, 5 Jul 2001 08:38:28 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA07504 for ; Thu, 5 Jul 2001 08:38:36 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA18946 for ; Thu, 5 Jul 2001 08:38:36 -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 IAA24180; Thu, 5 Jul 2001 08:36:38 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f65Faat32058; Thu, 5 Jul 2001 08:36:36 -0700 X-mProtect: Thu, 5 Jul 2001 08:36:36 -0700 Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdwtLYNV; Thu, 05 Jul 2001 08:36:35 PDT Message-ID: <3B448983.B50FE7AE@iprg.nokia.com> Date: Thu, 05 Jul 2001 08:36:35 -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: Alexis CC: mobile-ip@sunroof.eng.sun.com, Phil Roberts , "Basavaraj Patil (NTC/Dallas)" , Abha Ahuja , Thomas Narten , Dave Johnson , Jeff Schiller , Marcus Leech , Pekka Nikander Subject: Re: [Fwd: [mobile-ip] Mobile IPv6 clarifications] References: <3B3B2E46.50E17D25@era.ericsson.se> <3B3E90F1.3F4AC384@iprg.nokia.com> <3B4171B2.7098C705@era.ericsson.se> <3B42565B.394B91D5@iprg.nokia.com> <3B448146.5112F7C9@crm.mot.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 Alexis, First, I need to doubly emphasize that I have no part in any decision to discard IPsec. However, statements have been made by the Security Area Directors (and other very knowledgeable people within the IPsec working group) that we couldn't use IPsec that way. When I asked how we might go about making changes that would enable the use of IPsec, I was told it would take a very long time (possibly years) of IPsec working group action. If somebody in the Security area wants to tell a different story, that will be just very fine with me. I'll try in a later note to describe my perhaps-inadequate understanding of the reasons why. I wish they would carry out the conversation on the [mobile-ip] mailing list instead of telling me in person or making statements in the face-to-face Mobile IP meetings. That way we could get it in writing and bring into the conversation the Mobile IP experts and IPsec experts from around the world. Furthermore, in no way does the current document split Mobile IP away from security. The current Binding Update is quite secure, as was the previous Binding Update which relied on AH. The difference is that the current Binding Update can have _EXACTLY_ the semantics that need to be specified for Mobile IPv6. Relying on AH, which in my opinion SHOULD still be O.K. but that's just my opinion and not going to matter when the IESG reviews the document, has the effect of leaving the Mobile IPv6 vulnerable to outside forces who may claim (and have claimed) that we have made inappropriate use of the protocol. Please note that this discussion is quite independent of any discussion about BAKE or PKI, at least to my understanding. But since you mentioned it, I believe that BAKE is amenable to further extension that would allow: - Better security with Diffie-Hellman (as an optional feature) - Identity authentication by way of PKI (as an optional feature), and I expect to do something along those lines before London. BAKE must be considered to be an individual submission, not a working group document, and as such the Mobile IPv6 document has zero reliance on BAKE. Having said that, however, I absolutely agree with your statements that BAKEd keys COULD be used with IPsec if such a thing were classifiable as a good feature by the appropriate security folks. It's crucial to identify what is needed for implementation from _every_ IPv6 node, vs. what can be implemented by IPv6 nodes that need additional features. I'm sympathetic to arguments about what needs to go into IPv6 lightbulbs, as well as cellphones, laptops, workstations, and mainframes. Regards, Charlie P. Alexis Olivereau wrote: > > Hello Charlie, > > Frankly, I would be quite reluctant to discard IPsec that way, not only > from a 'existing implementations' point of view but also taking into > consideration the future enhancements that are likely to be added to MIP > in the next few years. I am quite convinced that more powerful > terminals, general AAA framework, will re-enable the use of IPsec (let's > say ESP/NULL) to secure BUs and BAcks. Shouldn't we consider these > future prospects before such a decision? > > IKE is heavy and PKI is not scalable, that is quite a consensus. On the > other hand BAKE (for example :-) is scalable but the key it provides is > not as secure as the one IKE provides. As an example of alternative, I > would like to make a very basic proposal that will neither modify > heavily MIP nor IPsec. The idea is to let IPsec use the key that BAKE > (for example :-) gives. Now this can not be done without telling the > upper layer about the (poor) level of security this Security Association > would provide. I suggest that we use a new protocol flag to mark the SA > as a MIP one. For example, along with MD5, SHA1, SHA2 algorithms that > ESP uses for its authentication part, we would add MIP-MD5 as if it was > a new authentication algorithm. Concretely the MN-CN key could be > copied into IPsec part within a new SA after its distribution has taken > place. SPI and SN would have to be synchronized, let's say during key > distribution. And the algorithm would just be marked as 'MIP-MD5'... > > Anyway, the point here is not to write new scenarios, but to emphasize > some other ways that I think we have not paid enough attention to: > splitting Mobility from Security would surely discredit the very reason > for IPv6... > > No need to say that comments are welcomed! > > Regards, > Alexis From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 5 12:47:43 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA19230 for ; Thu, 5 Jul 2001 12:47: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 KAA18384; Thu, 5 Jul 2001 10:48: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 JAA24178; Thu, 5 Jul 2001 09:48:11 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f65GkOdP029322 for ; Thu, 5 Jul 2001 09:46:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f65GkOlf029321 for mobile-ip-dist; Thu, 5 Jul 2001 09: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f65GkLdP029314 for ; Thu, 5 Jul 2001 09:46:21 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA23971 for ; Thu, 5 Jul 2001 09:46:26 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA15121 for ; Thu, 5 Jul 2001 09:46:26 -0700 (PDT) Received: from mira-sjcm-3.cisco.com (mira-sjcm-3.cisco.com [171.69.24.15]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f65GkQh01389; Thu, 5 Jul 2001 09:46:26 -0700 (PDT) Received: from GDOMMETY-W2K2.cisco.com (gdommety-dsl4.cisco.com [10.19.17.141]) by mira-sjcm-3.cisco.com (Mirapoint) with ESMTP id AII01609; Thu, 5 Jul 2001 09:46:24 -0700 (PDT) Message-Id: <4.3.2.7.2.20010705093109.0164d070@mira-sjcm-3.cisco.com> X-Sender: gdommety@mira-sjcm-3.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 05 Jul 2001 09:48:53 -0700 To: "Mayank Chaudhary" From: Gopal Dommety Subject: RE: FW: [mobile-ip] Ext. for FMIPv6 - comments Cc: mobile-ip@sunroof.eng.sun.com In-Reply-To: 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: Mayank, What you are suggesting is a technique called Chaining (where in as you move create a tunnel between the old AR and new AR). Chaining and Anchoring are two possible techniques. Typically in a connectionless environment Anchoring tends to do well for the following reasons: 1. The latency involved in the message transfer between the new and the anchor is comparable to that of message transfer between the oldAR and the new AR (in connection oriented networks it involves redoing the circuits, therefore chaining could do better). 2. The performance of ARs might be impacted in chaining as the path has a higher degree of suboptimaility compared to that of anchoring (each AR on the path has to de-cap a packet and then encap it again) 3. It introduces additional single points of failure (i.e, the ARs in between the Anchor AR and the New AR). 4. since different ARs could potentially have different timers for the tunnel, it complicates the problem (obvioiusly this can be solved). 5. Routing loop detection could be tricky (this again can be solved). Thanks Gopal At 04:18 PM 7/3/2001 -0700, Mayank Chaudhary wrote: >jak> With regard to relay tunnels, the problem with relay tunnels is >that >they can lead to routing loops. Suppose MN moves from aAR >to AR1 to AR2 ... to ARn then back to aAR again. There would >need to be some kind of protocol to detect and break the loop. >If the wireless end of the BET gets moved every time the >MN moves, there is no need for such a protocol. > >mayank> true. but this can be easily avoided by maintaining some state >information is each AR that is part of the relay(such as IP addresses >for ARs that are already part of this session). current signalling >networks like SS7 already use this technique so i'm sure that we can >borrow from those solutions. besides the advantages outweigh the >additional overhead of loop detection :) > >So in such an architecture - >1) a relay tunnel is setup between the oAR and the nAR. Since no >HRqst/Hrply messages need to be exchanged between aAR and nAR this >allows for quick setup of the BET. also this has additional advantages >of reducing the buffering in the network(no bicasting required) that >must ensure when the oAR starts bicasting before BET setup in the >current proposal >2) the relay tunnel can be maintained as long as the network determines >that ping-pong of the MN is likely between the oAR and nAR >3) additionally the network can intitate Path Minimization at any time >to reduce additional hops. this is done by creating a BET between the >aAR and nAR and tearing down any relay tunnels that may exist > >now for the advantages - >1) reduced signalling during tunnel setup because no messages need be >exchanged between nAR and aAR reducing setup times and buffering load in >the network >2) bicasting is not required. the aAR continues to send data to the oAR >as usual. buffering needs to be performed at the oAR if the oAR-nAR >relay tunnel is not up, but then you cant avoid that in the current >proposal either :( >3) path minimization can be performed during periods of inactivity in >the session(how does one determine this ?) thus avoiding interruptions >in real-time traffic > > >what do you think ? >-mayank > > >-----Original Message----- > >From: Mayank Chaudhary > >Sent: Tuesday, July 03, 2001 1:08 PM > >To: 'gdommety@cisco.com'; > >Subject: FW: [mobile-ip] Ext. for FMIPv6 - comments > > > > > >I wanted to point out a couple of mistakes in the draft > > > >1) Section 3.3. , page 17, item 4) states > >"A BET is placed between oAR and nAR". I think you meant > >"A BET is placed between aAR and nAR" > > > >2) In the timing diagram for Three Party Source Trigger Handover > >an HTT Request should be followed by an HTT Reply from the nAR to the > >oAR. > >This is not really a mistake (as i initially thought) but will make the > >timing > >diagram much clearer > > > >as i understand there is never a relay tunnel established between oAR > >and nAR > >in BETH . instead tunnels are always anchored at aAR. if this is true, >i > >will propose > >an architecture where relay tunnels can be established to the authors >of > >the draft(much like in SS7 networks), with the advantages of that > >architecture. If i am wrong about this > >then i'll take it as premature enthusiasm :-) > > > >Mayank Chaudhary > >Seven Networks From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 5 14:32:37 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22840 for ; Thu, 5 Jul 2001 14:32:37 -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 LAA27081; Thu, 5 Jul 2001 11:32:54 -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 LAA24490; Thu, 5 Jul 2001 11:32:43 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f65IVidP029604 for ; Thu, 5 Jul 2001 11:31:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f65IViYB029603 for mobile-ip-dist; Thu, 5 Jul 2001 11:31: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.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f65IVedP029596 for ; Thu, 5 Jul 2001 11:31:40 -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 LAA05882 for ; Thu, 5 Jul 2001 11:31:47 -0700 (PDT) Received: from tailor.sailpix.com (ns1.sailpix.com [155.53.1.250]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA01764 for ; Thu, 5 Jul 2001 12:31:45 -0600 (MDT) Received: from atty.lounge.org (tycho-205-179-127-182.tychonet.com [205.179.127.182]) by tailor.sailpix.com (Postfix) with ESMTP id 4B37154C41 for ; Thu, 5 Jul 2001 11:31:46 -0700 (PDT) Received: from lounge.org (localhost [127.0.0.1]) by dharkins@lounge.orgatty.lounge.org (8.11.0/8.11.0) with ESMTP id f65ILNi01063 for ; Thu, 5 Jul 2001 11:21:24 -0700 (PDT) (envelope-from dharkins@lounge.org) Message-Id: <200107051821.f65ILNi01063@dharkins@lounge.orgatty.lounge.org> To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile IPv4 Authentication Internt Draft revision 0.1 In-Reply-To: Your message of "Thu, 05 Jul 2001 10:13:30 +0900." <004401c104ef$b4b15560$0ee0d5a5@telecom.samsung.co.kr> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1060.994357283.1@lounge.org> Date: Thu, 05 Jul 2001 11:21:23 -0700 From: Dan Harkins 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: HMAC-MD5 requires two parameters: a key, and the data to MAC. You're specification on how to derive a key has just one. Dan. On Thu, 05 Jul 2001 10:13:30 +0900 junhyuk@metro.telecom.samsung.co.kr wrote > > MN-HA shared key = HMAC-MD5(MN-AAA-key | FA Challenge | > MN NAI | MN-AAA-key) > From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 5 14:35:09 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22931 for ; Thu, 5 Jul 2001 14:35:09 -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 LAA27793; Thu, 5 Jul 2001 11:35: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 LAA24758; Thu, 5 Jul 2001 11:35:39 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f65IYpdP029665 for ; Thu, 5 Jul 2001 11:34:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f65IYpdj029664 for mobile-ip-dist; Thu, 5 Jul 2001 11: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f65IYldP029657 for ; Thu, 5 Jul 2001 11:34: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 LAA15132 for ; Thu, 5 Jul 2001 11:34:55 -0700 (PDT) Received: from mail.cs.umn.edu (mail.cs.umn.edu [128.101.36.200]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA03049 for ; Thu, 5 Jul 2001 12:34:53 -0600 (MDT) Received: from mercury.cs.umn.edu (rakshe@mercury.cs.umn.edu [128.101.34.120]) by mail.cs.umn.edu (8.11.3/8.11.3) with ESMTP id f65IYs123839 for ; Thu, 5 Jul 2001 13:34:54 -0500 (CDT) Received: from localhost (rakshe@localhost) by mercury.cs.umn.edu (8.9.3/8.9.0) with ESMTP id NAA19351 for ; Thu, 5 Jul 2001 13:33:50 -0500 (CDT) X-Authentication-Warning: mercury.cs.umn.edu: rakshe owned process doing -bs Date: Thu, 5 Jul 2001 13:33:50 -0500 (CDT) From: Munna Pavitra To: "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] Mobile IPv4 Authentication Internt Draft revision 0.1 In-Reply-To: <200107051821.f65ILNi01063@dharkins@lounge.orgatty.lounge.org> 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 Thu, 5 Jul 2001, Dan Harkins wrote: When do we expect to start the work ? > specification on how to derive a key has just one. > > Dan. > > On Thu, 05 Jul 2001 10:13:30 +0900 junhyuk@metro.telecom.samsung.co.kr wrote > > > > MN-HA shared key = HMAC-MD5(MN-AAA-key | FA Challenge | > > MN NAI | MN-AAA-key) > > > From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 5 14:41:16 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA23236 for ; Thu, 5 Jul 2001 14:41: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 MAA06233; Thu, 5 Jul 2001 12:41: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 LAA25592; Thu, 5 Jul 2001 11:41:43 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f65IerdP029729 for ; Thu, 5 Jul 2001 11:40:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f65IerCL029728 for mobile-ip-dist; Thu, 5 Jul 2001 11:40: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.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f65IeodP029721 for ; Thu, 5 Jul 2001 11:40:50 -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 LAA15824 for ; Thu, 5 Jul 2001 11:40:58 -0700 (PDT) Received: from mail.cs.umn.edu (mail.cs.umn.edu [128.101.35.200]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA11992 for ; Thu, 5 Jul 2001 12:42:01 -0600 (MDT) Received: from mercury.cs.umn.edu (rakshe@mercury.cs.umn.edu [128.101.34.120]) by mail.cs.umn.edu (8.11.3/8.11.3) with ESMTP id f65Ieu124731 for ; Thu, 5 Jul 2001 13:40:56 -0500 (CDT) Received: from localhost (rakshe@localhost) by mercury.cs.umn.edu (8.9.3/8.9.0) with ESMTP id NAA19401 for ; Thu, 5 Jul 2001 13:39:52 -0500 (CDT) X-Authentication-Warning: mercury.cs.umn.edu: rakshe owned process doing -bs Date: Thu, 5 Jul 2001 13:39:52 -0500 (CDT) From: Munna To: "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] Mobile IPv4 Authentication Internt Draft revision 0.1 In-Reply-To: <200107051821.f65ILNi01063@dharkins@lounge.orgatty.lounge.org> 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 Thu, 5 Jul 2001, Dan Harkins wrote: > specification on how to derive a key has just one. Sorry for the last weird mail I sent. But at least I found a way to post my message, because the last two emails I sent did not appear on the list at all... I have done everything possible to unsubscribe this email address of mine from this list. But nothing works. "Unsubscribe" command does not work. The administrator does not reply. Any ideas ? Thanks. > > Dan. > > On Thu, 05 Jul 2001 10:13:30 +0900 junhyuk@metro.telecom.samsung.co.kr wrote > > > > MN-HA shared key = HMAC-MD5(MN-AAA-key | FA Challenge | > > MN NAI | MN-AAA-key) > > > From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 5 15:36:32 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24797 for ; Thu, 5 Jul 2001 15:36:31 -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 NAA27130; Thu, 5 Jul 2001 13:37: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 MAA13226; Thu, 5 Jul 2001 12:37:05 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f65JYtdP029845 for ; Thu, 5 Jul 2001 12:34:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f65JYtA9029844 for mobile-ip-dist; Thu, 5 Jul 2001 12:34: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.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f65JYodP029837 for ; Thu, 5 Jul 2001 12:34:50 -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 MAA21253 for ; Thu, 5 Jul 2001 12:34:59 -0700 (PDT) Received: from tailor.sailpix.com (ns1.sailpix.com [155.53.1.250]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA26181 for ; Thu, 5 Jul 2001 13:34:57 -0600 (MDT) Received: from atty.lounge.org (tycho-205-179-127-182.tychonet.com [205.179.127.182]) by tailor.sailpix.com (Postfix) with ESMTP id C454F54C41 for ; Thu, 5 Jul 2001 12:34:57 -0700 (PDT) Received: from lounge.org (localhost [127.0.0.1]) by dharkins@lounge.orgatty.lounge.org (8.11.0/8.11.0) with ESMTP id f65JOZi01239 for ; Thu, 5 Jul 2001 12:24:36 -0700 (PDT) (envelope-from dharkins@lounge.org) Message-Id: <200107051924.f65JOZi01239@dharkins@lounge.orgatty.lounge.org> To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile IPv4 Authentication Internt Draft revision 0.1 In-Reply-To: Your message of "Thu, 05 Jul 2001 11:21:23 PDT." <200107051821.f65ILNi01063@dharkins@lounge.orgatty.lounge.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1236.994361075.1@lounge.org> Date: Thu, 05 Jul 2001 12:24:35 -0700 From: Dan Harkins 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: Chop this line, please! It appears my last message got chopped by the list and didn't make sense. What I was saying is that HMAC-MD5 takes two parameters but the specification of how to derive a key in the referenced I-D has only one. And it would be nice to know the rationale for using the MN-AAA-key twice in the derivation. thanks, Dan. On Thu, 05 Jul 2001 11:21:23 PDT you wrote > specification on how to derive a key has just one. > > Dan. > > On Thu, 05 Jul 2001 10:13:30 +0900 junhyuk@metro.telecom.samsung.co.kr wrote > > > > MN-HA shared key = HMAC-MD5(MN-AAA-key | FA Challenge | > > MN NAI | MN-AAA-key) > > From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 5 17:47:08 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA28223 for ; Thu, 5 Jul 2001 17:47:07 -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 PAA14640; Thu, 5 Jul 2001 15: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 OAA24488; Thu, 5 Jul 2001 14:47:30 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f65LjxdP000049 for ; Thu, 5 Jul 2001 14:45:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f65LjxrH000047 for mobile-ip-dist; Thu, 5 Jul 2001 14:45: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.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f65LjudP000039 for ; Thu, 5 Jul 2001 14:45:56 -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 OAA03191 for ; Thu, 5 Jul 2001 14:46:06 -0700 (PDT) Received: from k2.watercove.com ([12.104.0.98]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA14048 for ; Thu, 5 Jul 2001 15:46:04 -0600 (MDT) Received: by k2 with Internet Mail Service (5.5.2650.21) id <3FN08BG6>; Thu, 5 Jul 2001 17:47:53 -0400 Message-ID: <8D9C6ADAD0DBD4119F8D00508BF7CBD1FB5D@apo.watercove.com> From: Shaji Radhakrishnan To: "'mobile-ip@sunroof.eng.sun.com'" Subject: Re:[mobile-ip] Mobile IPv4 Authentication Internt Draft revision 0.1 Date: Thu, 5 Jul 2001 17:45:48 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1059C.24B3A6B8" 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_01C1059C.24B3A6B8 Content-Type: text/plain; charset="euc-kr" Hi JH Song, I have a small doubt regarding your draft. According to RFC 3012, each re-registration by the mobile node SHOULD use different challenge provided by the Foreign Agent (either in Agent advertisements or last registration reply). From your draft it is not clear that the mobile node continue using the old key generated from the old challenge (i.e , the very first challenge in the advertisement) or each generate a new key based on the new challenge received in the reply or advertisements. One solutions to this is that HA must also check the received challenge value in the registration request, along with NAI and or Home IP address. Also if mobile node is using new key (since it used the new challenge) in the re-registration, it MUST include the NAI in the registration request eventhough MN-AAA extension is not present, and only MN-HA authentication extension is present. Then only AAAh can compute the key in this re-registration case. Thanks - shaji -----Original Message----- From: junhyuk song [mailto:junhyuk@metro.telecom.samsung.co.kr] Sent: Wednesday, July 04, 2001 8:14 PM To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Mobile IPv4 Authentication Internt Draft revision 0.1 Hi All, We recently submitted the revision of Internet draft draft on "MIPv4 Authentication Shared Secret Generation. draft-song-mobileip-mipv4-auth-secgeneration-01.txt Regards, JH SONG ------_=_NextPart_001_01C1059C.24B3A6B8 Content-Type: text/html; charset="euc-kr"
Hi JH Song,
 
I have a small doubt regarding your draft.
 
According to RFC 3012, each re-registration by the mobile node SHOULD use different
challenge provided by the Foreign Agent (either in Agent advertisements or last registration reply).
From your draft it is not clear that  the mobile node continue using the old key generated from the old challenge
(i.e , the very first challenge in the advertisement) or each generate a new key based on the new challenge
received in the reply or advertisements. One solutions to this is that HA must also check the received challenge
value in the registration request, along with NAI and or Home IP address.
 
Also if mobile node is using new key (since it used the new challenge) in the re-registration, it MUST include
the NAI in the registration request eventhough MN-AAA extension is not present, and only MN-HA authentication extension
is present. Then only AAAh can compute the key in this re-registration case.
 
Thanks
- shaji
 
-----Original Message-----
From: junhyuk song [mailto:junhyuk@metro.telecom.samsung.co.kr]
Sent: Wednesday, July 04, 2001 8:14 PM
To: mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] Mobile IPv4 Authentication Internt Draft revision 0.1

Hi All,

We recently submitted the revision of Internet draft draft on "MIPv4 Authentication Shared Secret Generation.
 
draft-song-mobileip-mipv4-auth-secgeneration-01.txt 

Regards,
JH SONG
------_=_NextPart_001_01C1059C.24B3A6B8-- From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 6 06:20:34 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA25328 for ; Fri, 6 Jul 2001 06:20:34 -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 EAA07191; Fri, 6 Jul 2001 04:20:59 -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 DAA14010; Fri, 6 Jul 2001 03:20:51 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f66AJVdP000754 for ; Fri, 6 Jul 2001 03:19:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f66AJUxs000753 for mobile-ip-dist; Fri, 6 Jul 2001 03:19: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.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f66AJRdP000746 for ; Fri, 6 Jul 2001 03:19:27 -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 DAA19135 for ; Fri, 6 Jul 2001 03:19:34 -0700 (PDT) Received: from telecom.samsung.co.kr ([165.213.221.4]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA19200 for ; Fri, 6 Jul 2001 04:20:37 -0600 (MDT) Received: from metro (a22414 [165.213.224.14]) by telecom.samsung.co.kr (8.9.3/8.9.3) with SMTP id TAA13827 for ; Fri, 6 Jul 2001 19:21:53 +0900 (KST) Message-ID: <00f601c10605$53d5acc0$0ee0d5a5@telecom.samsung.co.kr> From: "junhyuk song" To: References: <8D9C6ADAD0DBD4119F8D00508BF7CBD1FB5D@apo.watercove.com> Subject: Re: [mobile-ip] Mobile IPv4 Authentication Internt Draft revision 0.1 Date: Fri, 6 Jul 2001 19:20:48 +0900 Organization: cdma2000 system MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00F3_01C10650.C3157C00" 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: This is a multi-part message in MIME format. ------=_NextPart_000_00F3_01C10650.C3157C00 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SGkgU2hhamksDQoNClBsZWFzZSByZWFkIG15IGNvbW1lbnQgYmVsb3csDQoNCiAgLS0tLS0gT3Jp Z2luYWwgTWVzc2FnZSAtLS0tLSANCiAgRnJvbTogU2hhamkgUmFkaGFrcmlzaG5hbiANCiAgVG86 ICdtb2JpbGUtaXBAc3Vucm9vZi5lbmcuc3VuLmNvbScgDQogIFNlbnQ6IEZyaWRheSwgSnVseSAw NiwgMjAwMSA2OjQ1IEFNDQogIFN1YmplY3Q6IFJlOlttb2JpbGUtaXBdIE1vYmlsZSBJUHY0IEF1 dGhlbnRpY2F0aW9uIEludGVybnQgRHJhZnQgcmV2aXNpb24gMC4xDQoNCg0KICBIaSBKSCBTb25n LA0KDQogIEkgaGF2ZSBhIHNtYWxsIGRvdWJ0IHJlZ2FyZGluZyB5b3VyIGRyYWZ0Lg0KDQogIEFj Y29yZGluZyB0byBSRkMgMzAxMiwgZWFjaCByZS1yZWdpc3RyYXRpb24gYnkgdGhlIG1vYmlsZSBu b2RlIFNIT1VMRCB1c2UgZGlmZmVyZW50IA0KICBjaGFsbGVuZ2UgcHJvdmlkZWQgYnkgdGhlIEZv cmVpZ24gQWdlbnQgKGVpdGhlciBpbiBBZ2VudCBhZHZlcnRpc2VtZW50cyBvciBsYXN0IHJlZ2lz dHJhdGlvbiByZXBseSkuDQogIEZyb20geW91ciBkcmFmdCBpdCBpcyBub3QgY2xlYXIgdGhhdCAg dGhlIG1vYmlsZSBub2RlIGNvbnRpbnVlIHVzaW5nIHRoZSBvbGQga2V5IGdlbmVyYXRlZCBmcm9t IHRoZSBvbGQgY2hhbGxlbmdlDQogIChpLmUgLCB0aGUgdmVyeSBmaXJzdCBjaGFsbGVuZ2UgaW4g dGhlIGFkdmVydGlzZW1lbnQpIG9yIGVhY2ggZ2VuZXJhdGUgYSBuZXcga2V5IGJhc2VkIG9uIHRo ZSBuZXcgY2hhbGxlbmdlDQogIHJlY2VpdmVkIGluIHRoZSByZXBseSBvciBhZHZlcnRpc2VtZW50 cy4gT25lIHNvbHV0aW9ucyB0byB0aGlzIGlzIHRoYXQgSEEgbXVzdCBhbHNvIGNoZWNrIHRoZSBy ZWNlaXZlZCBjaGFsbGVuZ2UNCiAgdmFsdWUgaW4gdGhlIHJlZ2lzdHJhdGlvbiByZXF1ZXN0LCBh bG9uZyB3aXRoIE5BSSBhbmQgb3IgSG9tZSBJUCBhZGRyZXNzLg0KDQogIFRoZSBNTiB3aWxsIGJl IHVzaW5nIG5ldyBjaGFsbGVuZ2UgZm9yIGNyZWF0aW5nIE1OLUhBIHNoYXJlZCB0aGF0IGNhbWUg YWxvbmcgUlJQIHVwb24gZXZlcnkgcmUtcmVnaXN0cmF0aW9uLg0KICBIb3dldmVyLCBpdCBpcyBu b3QgbmVjZXNzYXJ5IHRvIGtlZXAgdXBkYXRpbmcgTU4tSEEgc2hhcmVkIGtleSB1cG9uIGV2ZXJ5 IHJlLXJlZ2lzdHJhdGlvbiwgDQogIGJlY2F1c2UgTU4tSEEgc2hhcmVkIGtleSBjYW4gYmUgdXNl ZCB1bnRpbCB1c2VyIHRlcm1pbmF0ZSB0aGUgTUlQIHNlc3Npb24uICANCiAgSW4gYWRkaXRpb24g aWYgdGhlIG9wdGlvbmFsIGxpZmV0aW1lIG9mIE1OLUhBIGtleSBpcyB1c2VkLCANCiAgTU4gYW5k IEhBIHdpbGwgcmVmcmVzaCBNTi1IQSBzaGFyZWQga2V5IG9ubHkgaWYgdGhlIE1OLUhBIHNoYXJl IGtleSBsaWZldGltZSBpcyBleHBpcmVkLg0KICBQbGVhc2Ugc2VlIHNlY3Rpb24gNCwgS2V5IE1h bmFnZW1lbnQgb2Ygb3VyIEludGVybmV0IERyYWZ0IDAuMSB2ZXJzaW9uLg0KDQogIEFsc28gaWYg bW9iaWxlIG5vZGUgaXMgdXNpbmcgbmV3IGtleSAoc2luY2UgaXQgdXNlZCB0aGUgbmV3IGNoYWxs ZW5nZSkgaW4gdGhlIHJlLXJlZ2lzdHJhdGlvbiwgaXQgTVVTVCBpbmNsdWRlDQogIHRoZSBOQUkg aW4gdGhlIHJlZ2lzdHJhdGlvbiByZXF1ZXN0IGV2ZW50aG91Z2ggTU4tQUFBIGV4dGVuc2lvbiBp cyBub3QgcHJlc2VudCwgYW5kIG9ubHkgTU4tSEEgYXV0aGVudGljYXRpb24gZXh0ZW5zaW9uDQog IGlzIHByZXNlbnQuIFRoZW4gb25seSBBQUFoIGNhbiBjb21wdXRlIHRoZSBrZXkgaW4gdGhpcyBy ZS1yZWdpc3RyYXRpb24gY2FzZS4NCg0KICBJZiB5b3VyIGNvbmNlcm4gaXMgbm90IHJlc29sdmVk IHVudGlsIHlvdSByZWFkIHRoaXMsIEkgbXVzdCBiZSBtaXN1bmRlcnN0YW5kIHlvdXIgcXVlc3Rp b24uDQoNCiAgVGhlIHJlYXNvbiBJIHVzZSB0aGUgTkFJIHJhdGhlciB0aGFuIElQIGFkZHJlc3Mg b24gY29tcHV0aW5nIE1OLUhBIHNoYXJlZCBrZXkgaXMgdG8gc3VwcG9ydCBEeW5hbWljIE1JUCBj YXNlLg0KICBJbiB0aGF0IGNhc2UsIE5BSSBtdXN0IGJlIHByZXNlbmNlLCB0aGVyZWZvcmUgTkFJ IGNhbiBiZSByZXBsYWNlZCBieSBNTiBJUCBhZGRyZXNzLiANCiAgQW5kIFJGQy0zMDEyIHN0YXRl IHRoZSBjYXNlIEhBIHJlY2VpdmVkIE1OLUFBQSBhdXRoZW50aWNhdGlvbiB3aXRoIEZBQyBleHRl bnNpb24uDQogIEJlc2lkZXMsIEFBQSBpcyB0aGUgZW50aXR5IHRoYXQgY3JlYXRlIHRoZSBuZXcg TU4tSEEgc2hhcmVkIGtleSwgSEEgc2hhbGwgZmV0Y2ggb3IgcmVjZWl2ZSBNTi1IQSBzaGFyZWQg a2V5IGZyb20gQUFBLg0KDQogIENvdWxkIHlvdSBlbGFib3JhdGUgeW91ciBxdWVzdGlvbj8NCg0K ICBSZWdhcmRzLA0KICBKSCBTT05HDQoNCiAgVGhhbmtzDQogIC0gc2hhamkNCg0KICAgIC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQogICAgRnJvbToganVuaHl1ayBzb25nIFttYWlsdG86anVu aHl1a0BtZXRyby50ZWxlY29tLnNhbXN1bmcuY28ua3JdDQogICAgU2VudDogV2VkbmVzZGF5LCBK dWx5IDA0LCAyMDAxIDg6MTQgUE0NCiAgICBUbzogbW9iaWxlLWlwQHN1bnJvb2YuZW5nLnN1bi5j b20NCiAgICBTdWJqZWN0OiBbbW9iaWxlLWlwXSBNb2JpbGUgSVB2NCBBdXRoZW50aWNhdGlvbiBJ bnRlcm50IERyYWZ0IHJldmlzaW9uIDAuMQ0KDQoNCiAgICBIaSBBbGwsDQoNCiAgICBXZSByZWNl bnRseSBzdWJtaXR0ZWQgdGhlIHJldmlzaW9uIG9mIEludGVybmV0IGRyYWZ0IGRyYWZ0IG9uICJN SVB2NCBBdXRoZW50aWNhdGlvbiBTaGFyZWQgU2VjcmV0IEdlbmVyYXRpb24uDQoNCiAgICBkcmFm dC1zb25nLW1vYmlsZWlwLW1pcHY0LWF1dGgtc2VjZ2VuZXJhdGlvbi0wMS50eHQgIA0KDQoNCiAg ICBSZWdhcmRzLA0KICAgIEpIIFNPTkcNCg0K ------=_NextPart_000_00F3_01C10650.C3157C00 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA1LjUwLjQ1MjIuMTgwMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPkhpIFNoYWpp LDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxE SVY+PEZPTlQgc2l6ZT0yPlBsZWFzZSByZWFkIG15IGNvbW1lbnQgYmVsb3csPC9GT05UPjwvRElW Pg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPEJMT0NLUVVPVEUgZGly PWx0ciANCnN0eWxlPSJQQURESU5HLVJJR0hUOiAwcHg7IFBBRERJTkctTEVGVDogNXB4OyBNQVJH SU4tTEVGVDogNXB4OyBCT1JERVItTEVGVDogIzAwMDAwMCAycHggc29saWQ7IE1BUkdJTi1SSUdI VDogMHB4Ij4NCiAgPERJViBzdHlsZT0iRk9OVDogMTBwdCCxvLiyIj4tLS0tLSBPcmlnaW5hbCBN ZXNzYWdlIC0tLS0tIDwvRElWPg0KICA8RElWIA0KICBzdHlsZT0iQkFDS0dST1VORDogI2U0ZTRl NDsgRk9OVDogMTBwdCCxvLiyOyBmb250LWNvbG9yOiBibGFjayI+PEI+RnJvbTo8L0I+IDxBIA0K ICB0aXRsZT1zcmFkaGFrcmlzaG5hbkB3YXRlcmNvdmUuY29tIA0KICBocmVmPSJtYWlsdG86c3Jh ZGhha3Jpc2huYW5Ad2F0ZXJjb3ZlLmNvbSI+U2hhamkgUmFkaGFrcmlzaG5hbjwvQT4gPC9ESVY+ DQogIDxESVYgc3R5bGU9IkZPTlQ6IDEwcHQgsby4siI+PEI+VG86PC9CPiA8QSB0aXRsZT1tb2Jp bGUtaXBAc3Vucm9vZi5lbmcuc3VuLmNvbSANCiAgaHJlZj0ibWFpbHRvOidtb2JpbGUtaXBAc3Vu cm9vZi5lbmcuc3VuLmNvbSciPidtb2JpbGUtaXBAc3Vucm9vZi5lbmcuc3VuLmNvbSc8L0E+IA0K ICA8L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDogMTBwdCCxvLiyIj48Qj5TZW50OjwvQj4gRnJp ZGF5LCBKdWx5IDA2LCAyMDAxIDY6NDUgQU08L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDogMTBw dCCxvLiyIj48Qj5TdWJqZWN0OjwvQj4gUmU6W21vYmlsZS1pcF0gTW9iaWxlIElQdjQgDQogIEF1 dGhlbnRpY2F0aW9uIEludGVybnQgRHJhZnQgcmV2aXNpb24gMC4xPC9ESVY+DQogIDxESVY+PEZP TlQgc2l6ZT0yPjwvRk9OVD48Rk9OVCBzaXplPTI+PC9GT05UPjxCUj48L0RJVj4NCiAgPERJVj48 Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjxTUEFOIGNsYXNzPTI4NTE1MzEy MS0wNTA3MjAwMT5IaSANCiAgSkggU29uZyw8L1NQQU4+PC9GT05UPjwvRElWPg0KICA8RElWPjxG T05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiBzaXplPTI+PFNQQU4gDQogIGNsYXNzPTI4NTE1 MzEyMS0wNTA3MjAwMT48L1NQQU4+PC9GT05UPiZuYnNwOzwvRElWPg0KICA8RElWPjxGT05UIGZh Y2U9QXJpYWwgY29sb3I9IzAwMDBmZiBzaXplPTI+PFNQQU4gY2xhc3M9Mjg1MTUzMTIxLTA1MDcy MDAxPkkgDQogIGhhdmUgYSBzbWFsbCBkb3VidCByZWdhcmRpbmcgeW91ciBkcmFmdC48L1NQQU4+ PC9GT05UPjwvRElWPg0KICA8RElWPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiBzaXpl PTI+PFNQQU4gDQogIGNsYXNzPTI4NTE1MzEyMS0wNTA3MjAwMT48L1NQQU4+PC9GT05UPiZuYnNw OzwvRElWPg0KICA8RElWPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiBzaXplPTI+PFNQ QU4gDQogIGNsYXNzPTI4NTE1MzEyMS0wNTA3MjAwMT5BY2NvcmRpbmcgdG8gUkZDIDMwMTIsIGVh Y2ggcmUtcmVnaXN0cmF0aW9uIGJ5IHRoZSANCiAgbW9iaWxlIG5vZGUgU0hPVUxEIHVzZSBkaWZm ZXJlbnQgPC9TUEFOPjwvRk9OVD48L0RJVj4NCiAgPERJVj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9y PSMwMDAwZmYgc2l6ZT0yPjxTUEFOIA0KICBjbGFzcz0yODUxNTMxMjEtMDUwNzIwMDE+Y2hhbGxl bmdlIHByb3ZpZGVkIGJ5IHRoZSBGb3JlaWduIEFnZW50IChlaXRoZXIgaW4gDQogIEFnZW50IGFk dmVydGlzZW1lbnRzIG9yIGxhc3QgcmVnaXN0cmF0aW9uIHJlcGx5KS48L1NQQU4+PC9GT05UPjwv RElWPg0KICA8RElWPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiBzaXplPTI+PFNQQU4g Y2xhc3M9Mjg1MTUzMTIxLTA1MDcyMDAxPkZyb20gDQogIHlvdXImbmJzcDtkcmFmdCBpdCBpcyBu b3QgY2xlYXIgdGhhdCAmbmJzcDt0aGUgbW9iaWxlIG5vZGUgY29udGludWUgdXNpbmcgdGhlIA0K ICBvbGQga2V5IGdlbmVyYXRlZCBmcm9tIHRoZSBvbGQgY2hhbGxlbmdlPC9TUEFOPjwvRk9OVD48 L0RJVj4NCiAgPERJVj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjxTUEFO IGNsYXNzPTI4NTE1MzEyMS0wNTA3MjAwMT4oaS5lIA0KICAsIHRoZSB2ZXJ5IGZpcnN0IGNoYWxs ZW5nZSBpbiB0aGUgYWR2ZXJ0aXNlbWVudCkgb3IgZWFjaCBnZW5lcmF0ZSBhIG5ldyBrZXkgDQog IGJhc2VkIG9uIHRoZSBuZXcgY2hhbGxlbmdlPC9TUEFOPjwvRk9OVD48L0RJVj4NCiAgPERJVj48 Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjxTUEFOIA0KICBjbGFzcz0yODUx NTMxMjEtMDUwNzIwMDE+cmVjZWl2ZWQgaW4gdGhlIHJlcGx5IG9yIGFkdmVydGlzZW1lbnRzLiBP bmUgDQogIHNvbHV0aW9ucyB0byB0aGlzIGlzIHRoYXQgSEEmbmJzcDttdXN0IGFsc28gY2hlY2sg dGhlIHJlY2VpdmVkIA0KICBjaGFsbGVuZ2U8L1NQQU4+PC9GT05UPjxGT05UIGZhY2U9QXJpYWwg Y29sb3I9IzAwMDBmZiBzaXplPTI+PFNQQU4gDQogIGNsYXNzPTI4NTE1MzEyMS0wNTA3MjAwMT48 L1NQQU4+PC9GT05UPjwvRElWPg0KICA8RElWPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBm ZiBzaXplPTI+PFNQQU4gDQogIGNsYXNzPTI4NTE1MzEyMS0wNTA3MjAwMT52YWx1ZSZuYnNwO2lu IHRoZSByZWdpc3RyYXRpb24gcmVxdWVzdCwgYWxvbmcgd2l0aCANCiAgTkFJIGFuZCBvciBIb21l IElQIGFkZHJlc3MuPC9TUEFOPjwvRk9OVD48L0RJVj4NCiAgPERJVj48Rk9OVCBmYWNlPUFyaWFs IGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjxTUEFOIA0KICBjbGFzcz0yODUxNTMxMjEtMDUwNzIwMDE+ PC9TUEFOPjwvRk9OVD4mbmJzcDs8L0RJVj4NCiAgPERJVj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9y PSMwMDAwZmYgc2l6ZT0yPjxTUEFOIA0KICBjbGFzcz0yODUxNTMxMjEtMDUwNzIwMDE+PEZPTlQg Y29sb3I9IzAwMDAwMD5UaGU8L0ZPTlQ+IDxGT05UIGNvbG9yPSMwMDAwMDA+TU4gDQogIHdpbGwg YmUgdXNpbmcgbmV3IGNoYWxsZW5nZSZuYnNwO2ZvciBjcmVhdGluZyBNTi1IQSBzaGFyZWQgdGhh dCBjYW1lIGFsb25nIFJSUCANCiAgdXBvbiBldmVyeSByZS1yZWdpc3RyYXRpb24uPC9GT05UPjwv U1BBTj48L0ZPTlQ+PC9ESVY+DQogIDxESVY+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZm IHNpemU9Mj48U1BBTiANCiAgY2xhc3M9Mjg1MTUzMTIxLTA1MDcyMDAxPjxGT05UIGNvbG9yPSMw MDAwMDA+SG93ZXZlciwmbmJzcDtpdCZuYnNwO2lzIG5vdCANCiAgbmVjZXNzYXJ5IHRvJm5ic3A7 a2VlcCB1cGRhdGluZyBNTi1IQSBzaGFyZWQga2V5IHVwb24gZXZlcnkgcmUtcmVnaXN0cmF0aW9u LCANCiAgPC9GT05UPjwvU1BBTj48L0ZPTlQ+PC9ESVY+DQogIDxESVY+PEZPTlQgZmFjZT1Bcmlh bCBjb2xvcj0jMDAwMGZmIHNpemU9Mj48U1BBTiANCiAgY2xhc3M9Mjg1MTUzMTIxLTA1MDcyMDAx PjxGT05UIGNvbG9yPSMwMDAwMDA+YmVjYXVzZSBNTi1IQSBzaGFyZWQga2V5Jm5ic3A7Y2FuIA0K ICBiZSB1c2VkJm5ic3A7dW50aWwgdXNlciB0ZXJtaW5hdGUgdGhlIE1JUCBzZXNzaW9uLiZuYnNw OyANCiAgPC9GT05UPjwvU1BBTj48L0ZPTlQ+PC9ESVY+DQogIDxESVY+PEZPTlQgZmFjZT1Bcmlh bCBjb2xvcj0jMDAwMGZmIHNpemU9Mj48U1BBTiANCiAgY2xhc3M9Mjg1MTUzMTIxLTA1MDcyMDAx PjxGT05UIGNvbG9yPSMwMDAwMDA+SW4gYWRkaXRpb24gaWYgdGhlJm5ic3A7b3B0aW9uYWwgDQog IGxpZmV0aW1lIG9mIE1OLUhBIGtleSBpcyB1c2VkLCA8L0ZPTlQ+PC9TUEFOPjwvRk9OVD48L0RJ Vj4NCiAgPERJVj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjxTUEFOIA0K ICBjbGFzcz0yODUxNTMxMjEtMDUwNzIwMDE+PEZPTlQgY29sb3I9IzAwMDAwMD5NTiBhbmQgSEEg d2lsbCByZWZyZXNoIE1OLUhBIA0KICBzaGFyZWQga2V5IG9ubHkgaWYgdGhlIE1OLUhBIHNoYXJl IGtleSBsaWZldGltZSBpcyANCiAgZXhwaXJlZC48L0ZPTlQ+PC9TUEFOPjwvRk9OVD48L0RJVj4N CiAgPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48U1BBTiBjbGFzcz0yODUxNTMxMjEtMDUw NzIwMDE+UGxlYXNlIHNlZSBzZWN0aW9uIA0KICA0LCBLZXkgTWFuYWdlbWVudCZuYnNwO29mIG91 ciBJbnRlcm5ldCBEcmFmdCAwLjEgdmVyc2lvbi48L1NQQU4+PC9GT05UPjwvRElWPg0KICA8RElW PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiBzaXplPTI+PFNQQU4gDQogIGNsYXNzPTI4 NTE1MzEyMS0wNTA3MjAwMT48L1NQQU4+PC9GT05UPiZuYnNwOzwvRElWPg0KICA8RElWPjxGT05U IGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiBzaXplPTI+PFNQQU4gY2xhc3M9Mjg1MTUzMTIxLTA1 MDcyMDAxPkFsc28gDQogIGlmIG1vYmlsZSBub2RlIGlzIHVzaW5nIG5ldyBrZXkgKHNpbmNlIGl0 IHVzZWQgdGhlIG5ldyBjaGFsbGVuZ2UpIGluIHRoZSANCiAgcmUtcmVnaXN0cmF0aW9uLCBpdCBN VVNUIGluY2x1ZGU8L1NQQU4+PC9GT05UPjwvRElWPg0KICA8RElWPjxGT05UIGZhY2U9QXJpYWwg Y29sb3I9IzAwMDBmZiBzaXplPTI+PFNQQU4gY2xhc3M9Mjg1MTUzMTIxLTA1MDcyMDAxPnRoZSAN CiAgTkFJIGluIHRoZSByZWdpc3RyYXRpb24gcmVxdWVzdCBldmVudGhvdWdoIE1OLUFBQSBleHRl bnNpb24gaXMgbm90IHByZXNlbnQsIA0KICBhbmQgb25seSBNTi1IQSBhdXRoZW50aWNhdGlvbiBl eHRlbnNpb248L1NQQU4+PC9GT05UPjwvRElWPg0KICA8RElWPjxGT05UIGZhY2U9QXJpYWwgY29s b3I9IzAwMDBmZiBzaXplPTI+PFNQQU4gY2xhc3M9Mjg1MTUzMTIxLTA1MDcyMDAxPmlzIA0KICBw cmVzZW50LjwvU1BBTj48L0ZPTlQ+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9 Mj48U1BBTiANCiAgY2xhc3M9Mjg1MTUzMTIxLTA1MDcyMDAxPiBUaGVuIG9ubHkgQUFBaCBjYW4g Y29tcHV0ZSB0aGUga2V5Jm5ic3A7aW4gdGhpcyANCiAgcmUtcmVnaXN0cmF0aW9uIGNhc2UuPC9T UEFOPjwvRk9OVD48L0RJVj4NCiAgPERJVj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYg c2l6ZT0yPjxTUEFOIA0KICBjbGFzcz0yODUxNTMxMjEtMDUwNzIwMDE+PC9TUEFOPjwvRk9OVD4m bmJzcDs8L0RJVj4NCiAgPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48U1BBTiBjbGFzcz0y ODUxNTMxMjEtMDUwNzIwMDE+SWYgeW91ciBjb25jZXJuIGlzIA0KICBub3QgcmVzb2x2ZWQgdW50 aWwgeW91IHJlYWQgdGhpcywgSSBtdXN0IGJlIG1pc3VuZGVyc3RhbmQgeW91ciANCiAgcXVlc3Rp b24uPC9TUEFOPjwvRk9OVD48L0RJVj4NCiAgPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48 U1BBTiANCiAgY2xhc3M9Mjg1MTUzMTIxLTA1MDcyMDAxPjwvU1BBTj48L0ZPTlQ+Jm5ic3A7PC9E SVY+DQogIDxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gY2xhc3M9Mjg1MTUzMTIx LTA1MDcyMDAxPlRoZSByZWFzb24gSSB1c2UgDQogIHRoZSBOQUkgcmF0aGVyIHRoYW4gSVAgYWRk cmVzcyBvbiBjb21wdXRpbmcgTU4tSEEgc2hhcmVkIGtleSBpcyB0byBzdXBwb3J0IA0KICBEeW5h bWljIE1JUCBjYXNlLjwvU1BBTj48L0ZPTlQ+PC9ESVY+DQogIDxESVY+PEZPTlQgZmFjZT1Bcmlh bCBzaXplPTI+PFNQQU4gY2xhc3M9Mjg1MTUzMTIxLTA1MDcyMDAxPkluIHRoYXQgY2FzZSwgTkFJ IA0KICBtdXN0IGJlIHByZXNlbmNlLCB0aGVyZWZvcmUgTkFJIGNhbiBiZSByZXBsYWNlZCBieSBN TiBJUCBhZGRyZXNzLiANCiAgPC9TUEFOPjwvRk9OVD48L0RJVj4NCiAgPERJVj48Rk9OVCBmYWNl PUFyaWFsIHNpemU9Mj48U1BBTiBjbGFzcz0yODUxNTMxMjEtMDUwNzIwMDE+QW5kIFJGQy0zMDEy IHN0YXRlIA0KICB0aGUgY2FzZSBIQSByZWNlaXZlZCA8L1NQQU4+PC9GT05UPjxGT05UIGZhY2U9 QXJpYWwgc2l6ZT0yPjxTUEFOIA0KICBjbGFzcz0yODUxNTMxMjEtMDUwNzIwMDE+TU4tQUFBIGF1 dGhlbnRpY2F0aW9uIHdpdGggRkFDIA0KICBleHRlbnNpb24uPC9TUEFOPjwvRk9OVD48L0RJVj4N CiAgPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48U1BBTiBjbGFzcz0yODUxNTMxMjEtMDUw NzIwMDE+QmVzaWRlcywgQUFBIGlzIA0KICB0aGUgZW50aXR5IHRoYXQgY3JlYXRlIHRoZSBuZXcg TU4tSEEgc2hhcmVkIGtleSwgSEEgc2hhbGwgZmV0Y2ggb3IgcmVjZWl2ZSANCiAgTU4tSEEgc2hh cmVkIGtleSBmcm9tIEFBQS48L1NQQU4+PC9GT05UPjwvRElWPg0KICA8RElWPjxGT05UIGZhY2U9 QXJpYWwgc2l6ZT0yPjxTUEFOIA0KICBjbGFzcz0yODUxNTMxMjEtMDUwNzIwMDE+PC9TUEFOPjwv Rk9OVD4mbmJzcDs8L0RJVj4NCiAgPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48U1BBTiBj bGFzcz0yODUxNTMxMjEtMDUwNzIwMDE+Q291bGQgeW91IA0KICBlbGFib3JhdGUgeW91ciBxdWVz dGlvbj88L1NQQU4+PC9GT05UPjwvRElWPg0KICA8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0y PjxTUEFOIA0KICBjbGFzcz0yODUxNTMxMjEtMDUwNzIwMDE+PC9TUEFOPjwvRk9OVD4mbmJzcDs8 L0RJVj4NCiAgPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48U1BBTiANCiAgY2xhc3M9Mjg1 MTUzMTIxLTA1MDcyMDAxPlJlZ2FyZHMsPC9TUEFOPjwvRk9OVD48L0RJVj4NCiAgPERJVj48Rk9O VCBmYWNlPUFyaWFsIHNpemU9Mj48U1BBTiBjbGFzcz0yODUxNTMxMjEtMDUwNzIwMDE+SkggDQog IFNPTkc8L1NQQU4+PC9GT05UPjwvRElWPg0KICA8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0y PjxTUEFOIA0KICBjbGFzcz0yODUxNTMxMjEtMDUwNzIwMDE+PC9TUEFOPjwvRk9OVD4mbmJzcDs8 L0RJVj4NCiAgPERJVj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjxTUEFO IA0KICBjbGFzcz0yODUxNTMxMjEtMDUwNzIwMDE+VGhhbmtzPC9TUEFOPjwvRk9OVD48L0RJVj4N CiAgPERJVj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjxTUEFOIGNsYXNz PTI4NTE1MzEyMS0wNTA3MjAwMT4tIA0KICBzaGFqaTwvU1BBTj48L0ZPTlQ+PC9ESVY+DQogIDxE SVY+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj48U1BBTiANCiAgY2xhc3M9 Mjg1MTUzMTIxLTA1MDcyMDAxPjwvU1BBTj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQogIDxCTE9DS1FV T1RFIHN0eWxlPSJNQVJHSU4tUklHSFQ6IDBweCI+DQogICAgPERJViBjbGFzcz1PdXRsb29rTWVz c2FnZUhlYWRlciBkaXI9bHRyIGFsaWduPWxlZnQ+PEZPTlQgZmFjZT1UYWhvbWEgDQogICAgc2l6 ZT0yPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPEJSPjxCPkZyb206PC9CPiBqdW5oeXVrIHNv bmcgDQogICAgW21haWx0bzpqdW5oeXVrQG1ldHJvLnRlbGVjb20uc2Ftc3VuZy5jby5rcl08QlI+ PEI+U2VudDo8L0I+IFdlZG5lc2RheSwgSnVseSANCiAgICAwNCwgMjAwMSA4OjE0IFBNPEJSPjxC PlRvOjwvQj4gDQogICAgbW9iaWxlLWlwQHN1bnJvb2YuZW5nLnN1bi5jb208QlI+PEI+U3ViamVj dDo8L0I+IFttb2JpbGUtaXBdIE1vYmlsZSBJUHY0IA0KICAgIEF1dGhlbnRpY2F0aW9uIEludGVy bnQgRHJhZnQgcmV2aXNpb24gMC4xPEJSPjxCUj48L0RJVj48L0ZPTlQ+DQogICAgPERJVj48Rk9O VCBzaXplPTI+DQogICAgPERJVj48Rk9OVCBzaXplPTI+SGkgQWxsLDxCUj48QlI+V2UgcmVjZW50 bHkgc3VibWl0dGVkJm5ic3A7dGhlIA0KICAgIHJldmlzaW9uJm5ic3A7b2YgSW50ZXJuZXQgZHJh ZnQmbmJzcDtkcmFmdCBvbiAiTUlQdjQgQXV0aGVudGljYXRpb24gU2hhcmVkIA0KICAgIFNlY3Jl dCBHZW5lcmF0aW9uLjwvRk9OVD48L0RJVj4NCiAgICA8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+ Jm5ic3A7PC9ESVY+DQogICAgPERJVj48Rk9OVCBzaXplPTI+ZHJhZnQtc29uZy1tb2JpbGVpcC1t aXB2NC1hdXRoLXNlY2dlbmVyYXRpb24tMDEudHh0Jm5ic3A7IA0KICAgIDxCUj48L0RJVj48Rk9O VCBzaXplPTM+PC9GT05UPjwvRk9OVD4NCiAgICA8RElWPjxGT05UIHNpemU9Mj48Rk9OVCBzaXpl PTM+PEZPTlQgc2l6ZT0yPjwvRk9OVD48Rk9OVCBzaXplPTI+PC9GT05UPjxGT05UIA0KICAgIHNp emU9Mj48L0ZPTlQ+PEJSPjwvRk9OVD5SZWdhcmRzLDwvRk9OVD48L0RJVj4NCiAgICA8RElWPjxG T05UIHNpemU9Mj5KSCANClNPTkc8QlI+PC9ESVY+PC9GT05UPjwvRk9OVD48L0RJVj48L0JMT0NL UVVPVEU+PC9CTE9DS1FVT1RFPjwvQk9EWT48L0hUTUw+DQo= ------=_NextPart_000_00F3_01C10650.C3157C00-- From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 6 06:53:08 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA26332 for ; Fri, 6 Jul 2001 06:53:08 -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 EAA18015; Fri, 6 Jul 2001 04:53: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 DAA15635; Fri, 6 Jul 2001 03:53:29 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f66Aq7dP000887 for ; Fri, 6 Jul 2001 03:52:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f66Aq7Vc000886 for mobile-ip-dist; Fri, 6 Jul 2001 03: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f66Aq2dP000879 for ; Fri, 6 Jul 2001 03:52:02 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA20646 for ; Fri, 6 Jul 2001 03:52:10 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA15377 for ; Fri, 6 Jul 2001 03:52:10 -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 GAA26053; Fri, 6 Jul 2001 06:51:24 -0400 (EDT) Message-Id: <200107061051.GAA26053@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-song-mobile-ipv4-auth-secgeneration-01.txt Date: Fri, 06 Jul 2001 06:51:24 -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. Title : Mobile IPv4 Authentication Shared key Generation Author(s) : J. Song et al. Filename : draft-song-mobile-ipv4-auth-secgeneration-01.txt Pages : 12 Date : 05-Jul-01 Mobile Node and Home Agent servers used in nowadays can provide authentication and authorization services mostly by the MN-HA and MN-AAA Authentication. However, this is only possible if Mobile Node previously share the same shared secrets with Home Agent and AAA. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-song-mobile-ipv4-auth-secgeneration-01.txt 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-song-mobile-ipv4-auth-secgeneration-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-song-mobile-ipv4-auth-secgeneration-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: <20010705114011.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-song-mobile-ipv4-auth-secgeneration-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-song-mobile-ipv4-auth-secgeneration-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010705114011.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 6 07:51:42 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA27840 for ; Fri, 6 Jul 2001 07:51:41 -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 EAA04729; Fri, 6 Jul 2001 04:52: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 EAA19526; Fri, 6 Jul 2001 04:52:04 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f66Bp9dP001088 for ; Fri, 6 Jul 2001 04:51:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f66Bp9B2001087 for mobile-ip-dist; Fri, 6 Jul 2001 04: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f66Bp5dP001080 for ; Fri, 6 Jul 2001 04:51:05 -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 EAA19494 for ; Fri, 6 Jul 2001 04:51:14 -0700 (PDT) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA06087 for ; Fri, 6 Jul 2001 05:51:12 -0600 (MDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (motgate2 2.1) with ESMTP id EAA03766 for ; Fri, 6 Jul 2001 04:51:13 -0700 (MST)] Received: [from m-il06-r3.mot.com (m-il06-r3.mot.com [129.188.137.194]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id EAA27544 for ; Fri, 6 Jul 2001 04:51:12 -0700 (MST)] Received: from [140.101.173.9] by m-il06-r3.mot.com with ESMTP for mobile-ip@sunroof.eng.sun.com; Fri, 6 Jul 2001 06:51:10 -0500 Received: (from root@localhost) by zorglub.crm.mot.com (8.8.8/8.8.8/crm-1.6) id NAA22648 for mobile-ip@sunroof.eng.sun.com.DELIVER; Fri, 6 Jul 2001 13:51:08 +0200 (METDST) Received: from crm.mot.com (nero.crm.mot.com [140.101.173.36]) by zorglub.crm.mot.com (8.8.8/8.8.8/crm-1.6) with ESMTP id NAA22523; Fri, 6 Jul 2001 13:51:02 +0200 (METDST) Message-Id: <3B45A614.45C1767F@crm.mot.com> Date: Fri, 06 Jul 2001 13:50:44 +0200 From: Alexis Olivereau Organization: Centre de Recherche de Motorola - Paris X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Charles E. Perkins" CC: Alexis , mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] MIPv6: the case for IPsec References: <3B3B2E46.50E17D25@era.ericsson.se> <3B3E90F1.3F4AC384@iprg.nokia.com> <3B4171B2.7098C705@era.ericsson.se> <3B42565B.394B91D5@iprg.nokia.com> <3B448146.5112F7C9@crm.mot.com> <3B448983.B50FE7AE@iprg.nokia.com> Content-Type: multipart/mixed; boundary="------------85D175BF4A014C283AF1E272" 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. --------------85D175BF4A014C283AF1E272 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Charlie, Please find my comments inline! "Charles E. Perkins" wrote: > > Hello Alexis, > > First, I need to doubly emphasize that I have no part in any decision > to discard IPsec. However, statements have been made by the Security > Area Directors (and other very knowledgeable people within the IPsec > working group) that we couldn't use IPsec that way. When I asked how > we might go about making changes that would enable the use of IPsec, > I was told it would take a very long time (possibly years) of IPsec > working group action. Actually I was expecting that some "security people" would react to that thread, telling us all the very reasons why we should not make use of IPsec. This is a tough decision, I am a bit surprised to see that very few people (even on this mailing list) appear to be affected; hey folks, are you all on holidays ?! :-) > If somebody in the Security area wants to tell a different story, > that will be just very fine with me. I'll try in a later note to > describe my perhaps-inadequate understanding of the reasons why. > I wish they would carry out the conversation on the [mobile-ip] > mailing list instead of telling me in person or making statements > in the face-to-face Mobile IP meetings. That way we could get it > in writing and bring into the conversation the Mobile IP experts > and IPsec experts from around the world. I plainly agree with you; I would even say that it seems essential to obtain a real consensus. We *do* need that reasons, plus the reasons why IPsec could not be easily made able to cooperate with MIP. > Furthermore, in no way does the current document split Mobile IP > away from security. The current Binding Update is quite secure, > as was the previous Binding Update which relied on AH. The difference > is that the current Binding Update can have _EXACTLY_ the semantics > that need to be specified for Mobile IPv6. Relying on AH, which in > my opinion SHOULD still be O.K. but that's just my opinion and not > going to matter when the IESG reviews the document, has the effect > of leaving the Mobile IPv6 vulnerable to outside forces who may claim > (and have claimed) that we have made inappropriate use of the protocol. Of course! Actually, I did not mean that we had lost any security service or that the security level afforded to BU was weaker. What I meant is that mandatory IPsec and MIPv6 within IPv6 are 2 essential blocks, which are now said not to be able to work together! Personally I do not find that very clean to go back to a specific security solution for MIPv6 as it was the case with MIPv4... > Please note that this discussion is quite independent of > any discussion about BAKE or PKI, at least to my understanding. > But since you mentioned it, I believe that BAKE is amenable to > further extension that would allow: > - Better security with Diffie-Hellman (as an optional feature) > - Identity authentication by way of PKI (as an optional feature), > and I expect to do something along those lines before London. > BAKE must be considered to be an individual submission, not a > working group document, and as such the Mobile IPv6 document has > zero reliance on BAKE. Having said that, however, I absolutely > agree with your statements that BAKEd keys COULD be used with > IPsec if such a thing were classifiable as a good feature by the > appropriate security folks. Once again, I wish I were able to get some feedback from IPsec people on this point! > It's crucial to identify what is needed for implementation from > _every_ IPv6 node, vs. what can be implemented by IPv6 nodes that > need additional features. I'm sympathetic to arguments about > what needs to go into IPv6 lightbulbs, as well as cellphones, > laptops, workstations, and mainframes. I try to keep in mind future needs too, and IMHO the future will be based on IPsec. We may certainly use both MIP-only security mechanism and IPsec but in my (protocol-oriented) point of view, it is not only a waste of bandwidth: it is something that would definitely go against IPv6 spirit. Now the question is "do we have any other solution?..." Regards, Alexis --------------85D175BF4A014C283AF1E272 Content-Type: text/x-vcard; charset=us-ascii; name="Alexis.Olivereau.vcf" Content-Description: Card for Alexis Olivereau Content-Disposition: attachment; filename="Alexis.Olivereau.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Olivereau;Alexis tel;fax:+33 (0)1 69 35 25 01 tel;work:+33 (0)1 69 35 25 16 x-mozilla-html:TRUE org:MOTOROLA LABS;Networking and Applications Lab version:2.1 email;internet:Alexis.Olivereau@crm.mot.com title:Research Engineer adr;quoted-printable:;;Immeuble "Le Columbia"=0D=0AEspace Technologique St Aubin=0D=0A;Gif-sur-Yvette;;91193;FRANCE fn:Alexis Olivereau end:vcard --------------85D175BF4A014C283AF1E272-- From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 6 09:37:38 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA01974 for ; Fri, 6 Jul 2001 09:37:37 -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 GAA27290; Fri, 6 Jul 2001 06:38:02 -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 GAA27632; Fri, 6 Jul 2001 06:37:52 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f66DXtdP001249 for ; Fri, 6 Jul 2001 06:33:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f66DXt8j001248 for mobile-ip-dist; Fri, 6 Jul 2001 06:33: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.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f66DXpdP001241 for ; Fri, 6 Jul 2001 06:33:51 -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 GAA01252 for ; Fri, 6 Jul 2001 06:34:00 -0700 (PDT) Received: from telecom.samsung.co.kr ([165.213.221.4]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA18476 for ; Fri, 6 Jul 2001 07:33:58 -0600 (MDT) Received: from metro (a22414 [165.213.224.14]) by telecom.samsung.co.kr (8.9.3/8.9.3) with SMTP id WAA19262 for ; Fri, 6 Jul 2001 22:36:22 +0900 (KST) Message-ID: <016001c10620$7e981220$0ee0d5a5@telecom.samsung.co.kr> From: "junhyuk song" To: References: <200107051924.f65JOZi01239@dharkins@lounge.orgatty.lounge.org> Subject: Re: [mobile-ip] Mobile IPv4 Authentication Internt Draft revision 0.1 Date: Fri, 6 Jul 2001 22:35:16 +0900 Organization: cdma2000 system 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.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by sunroof.eng.sun.com id f66DXqdP001242 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 Sorry, it is typo. It is MD5. Our Internet Draft support MD5 as a default configuration. And AAA depends on Algorithm Identifier in MN-AAA authentication extention. The default SPI is CHAP_SPI. I will add this on upcoming revision. ----- Original Message ----- From: "Dan Harkins" To: Sent: Friday, July 06, 2001 4:24 AM Subject: Re: [mobile-ip] Mobile IPv4 Authentication Internt Draft revision 0.1 > It appears my last message got chopped by the list and didn't make > sense. What I was saying is that HMAC-MD5 takes two parameters but > the specification of how to derive a key in the referenced I-D has > only one. > > And it would be nice to know the rationale for using the MN-AAA-key > twice in the derivation. > > thanks, > > Dan. > > On Thu, 05 Jul 2001 11:21:23 PDT you wrote > > specification on how to derive a key has just one. > > > > Dan. > > > > On Thu, 05 Jul 2001 10:13:30 +0900 junhyuk@metro.telecom.samsung.co.kr wrote > > > > > > MN-HA shared key = HMAC-MD5(MN-AAA-key | FA Challenge | > > > MN NAI | MN-AAA-key) > > > > From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 6 10:51:11 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05384 for ; Fri, 6 Jul 2001 10:51: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 IAA24760; Fri, 6 Jul 2001 08:51: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 HAA07580; Fri, 6 Jul 2001 07:51:28 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f66EoadP001401 for ; Fri, 6 Jul 2001 07:50:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f66Eoagt001400 for mobile-ip-dist; Fri, 6 Jul 2001 07:50: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.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f66EoVdP001386 for ; Fri, 6 Jul 2001 07:50:31 -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 HAA09242 for ; Fri, 6 Jul 2001 07:50:39 -0700 (PDT) From: Internet-Drafts@ietf.org Received: from NEXUS.replicants.org.uk (pc-62-30-167-16-ca.blueyonder.co.uk [62.30.167.16]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA24314 for ; Fri, 6 Jul 2001 08:50:36 -0600 (MDT) Received: from mail pickup service by NEXUS.replicants.org.uk with Microsoft SMTPSVC; Fri, 6 Jul 2001 15:54:47 +0100 X-From_: ietf-123-owner@loki.ietf.org Tue Jun 26 16:02:05 2001 Envelope-to: david@REPLICANTS.FREESERVE.CO.UK Delivery-date: Tue, 26 Jun 2001 16:02:05 +0100 Received: from [132.151.1.177] (helo=loki.ietf.org) by imailg2.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 15EuLt-00079u-00; Tue, 26 Jun 2001 16:02:05 +0100 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id JAA19873 for ietf-123-outbound.10@ietf.org; Tue, 26 Jun 2001 09:55:02 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA18631 for ; Tue, 26 Jun 2001 07:02:57 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27339; Tue, 26 Jun 2001 07:02:56 -0400 (EDT) Message-Id: <200106261102.HAA27339@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] I-D ACTION:draft-subbarao-mobileip-redundancy-00.txt Date: Tue, 26 Jun 2001 07:02:55 -0400 X-OriginalArrivalTime: 06 Jul 2001 14:54:47.0633 (UTC) FILETIME=[99C5EC10:01C1062B] 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 : Home Agent Redundancy in Mobile IP Author(s) : K. Leung, M. Subbarao Filename : draft-subbarao-mobileip-redundancy-00.txt Pages : Date : 11-Jun-01 In Mobile IP, a Home Agent (HA) creates a mobility binding table that tracks the association of a Mobile Node's (MN) home address with its current Care-of Address (CoA). If the HA fails, the mobility binding table will be lost and all MNs registered with the HA will lose connectivity. In this draft, we propose a Mobile IP Home Agent Redundancy framework mechanism that provides the essential robust redundancy needed at the HA. The mechanism described herein can also be used to provide the redundancy needed at any 'regional/local' HAs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-subbarao-mobileip-redundancy-00.txt 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-subbarao-mobileip-redundancy-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-subbarao-mobileip-redundancy-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: <20010625110710.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-subbarao-mobileip-redundancy-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-subbarao-mobileip-redundancy-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 6 11:31:01 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08305 for ; Fri, 6 Jul 2001 11:31:00 -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 JAA13462; Fri, 6 Jul 2001 09:31:24 -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 IAA16244; Fri, 6 Jul 2001 08:31:12 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f66FTQdP001515 for ; Fri, 6 Jul 2001 08:29:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f66FTQJG001514 for mobile-ip-dist; Fri, 6 Jul 2001 08:29: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.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f66FTMdP001507 for ; Fri, 6 Jul 2001 08:29: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 IAA21234 for ; Fri, 6 Jul 2001 08:29:31 -0700 (PDT) Received: from k2.watercove.com ([12.104.0.98]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA12405 for ; Fri, 6 Jul 2001 09:29:29 -0600 (MDT) Received: by k2 with Internet Mail Service (5.5.2650.21) id <3FN08C19>; Fri, 6 Jul 2001 11:31:18 -0400 Message-ID: <8D9C6ADAD0DBD4119F8D00508BF7CBD1FB64@apo.watercove.com> From: Shaji Radhakrishnan To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Mobile IPv4 Authentication Internt Draft revision 0.1 Date: Fri, 6 Jul 2001 11:29:14 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10630.B39A8B32" 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_01C10630.B39A8B32 Content-Type: text/plain; charset="euc-kr" Hi JH Song, Thanks for the reply. Please see my comments. Thanks - shaji -----Original Message----- From: junhyuk song [mailto:junhyuk@metro.telecom.samsung.co.kr] Sent: Friday, July 06, 2001 5:21 AM To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile IPv4 Authentication Internt Draft revision 0.1 Hi Shaji, Please read my comment below, ----- Original Message ----- From: Shaji Radhakrishnan To: 'mobile-ip@sunroof.eng.sun.com' Sent: Friday, July 06, 2001 6:45 AM Subject: Re:[mobile-ip] Mobile IPv4 Authentication Internt Draft revision 0. 1 Hi JH Song, I have a small doubt regarding your draft. According to RFC 3012, each re-registration by the mobile node SHOULD use different challenge provided by the Foreign Agent (either in Agent advertisements or last registration reply). From your draft it is not clear that the mobile node continue using the old key generated from the old challenge (i.e , the very first challenge in the advertisement) or each generate a new key based on the new challenge received in the reply or advertisements. One solutions to this is that HA must also check the received challenge value in the registration request, along with NAI and or Home IP address. The MN will be using new challenge for creating MN-HA shared that came along RRP upon every re-registration. However, it is not necessary to keep updating MN-HA shared key upon every re-registration, because MN-HA shared key can be used until user terminate the MIP session. In addition if the optional lifetime of MN-HA key is used, MN and HA will refresh MN-HA shared key only if the MN-HA share key lifetime is expired. Please see section 4, Key Management of our Internet Draft 0.1 version. ........ <> I agree that it is not necessay to update MN-HA key for each re- registration. But how does the HA know that mobile node is using the new key (generated from the new challenge in latest RRP) or the old key? This is because for each registration reply, the Foreign Agent sends a new challenge and mobile node sends this challenge to HA in the next re-registration request. At this moment, which key the mobile node should uses. The old one from already generated for the previous request or a new one generated from the last received challenge? Here two cases If the mobile node uses the old key and the new challenge, what should HA do? If the mobile ndoe uses the old key and old challenge, and is this case, the FA may reject the RRQ with STALE_CHALLENGE or UNKOWN_CHALLENGE. Also what happens for the following scenario: The mobile node is not having any idea about the lifetime of the share-key. The mobile node uses the old key, and the new challenge received from the last RRP, for the re- registration. Now when HA receives this RRQ, suppose the life time is expired. So it will get the new key based on the new challenge? What I meant is that HA should compare the challenge value in the re- registration message to see whether it should use the old cached key or to get a new key from AAAh. If HA receives a challenge value different that that it used to get the shared key from AAAh earlier, it should not matter whether previous key lifetime valid or not, HA should get the new key since Mobile node is using the new key. ...... <> Also if mobile node is using new key (since it used the new challenge) in the re-registration, it MUST include the NAI in the registration request eventhough MN-AAA extension is not present, and only MN-HA authentication extension is present. Then only AAAh can compute the key in this re-registration case. If your concern is not resolved until you read this, I must be misunderstand your question. The reason I use the NAI rather than IP address on computing MN-HA shared key is to support Dynamic MIP case. In that case, NAI must be presence, therefore NAI can be replaced by MN IP address. And RFC-3012 state the case HA received MN-AAA authentication with FAC extension. Besides, AAA is the entity that create the new MN-HA shared key, HA shall fetch or receive MN-HA shared key from AAA. Could you elaborate your question? ...... << my new reply begin>> ... You misunderstood my question. What I meant is that mobile node uses MN-AAA authentication with NAI for the initial registartion. Then it uses MN-HA authenitcation and Home IP address for all subsequest re-registration. Is this case possible that it is not using NAI for subsequent re-registrations, but only non-zero home ip address. If this is the case, no NAI present for the home agent to get the new shared key for the re-registrations. This make mandatory for the mobile node to send NAI in the re-registration messages along with MN-HA authentication extension. This point was not clearly stated in your document, (sorry if I might have missed it). ...... << my new reply ends>> ... Regards, JH SONG Thanks - shaji -----Original Message----- From: junhyuk song [mailto:junhyuk@metro.telecom.samsung.co.kr] Sent: Wednesday, July 04, 2001 8:14 PM To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Mobile IPv4 Authentication Internt Draft revision 0.1 Hi All, We recently submitted the revision of Internet draft draft on "MIPv4 Authentication Shared Secret Generation. draft-song-mobileip-mipv4-auth-secgeneration-01.txt Regards, JH SONG ------_=_NextPart_001_01C10630.B39A8B32 Content-Type: text/html; charset="euc-kr" Content-Transfer-Encoding: quoted-printable
Hi JH=20 Song,
Thanks=20 for the reply. Please see my comments.
Thanks
-=20 shaji
 
-----Original Message-----
From: junhyuk song=20 [mailto:junhyuk@metro.telecom.samsung.co.kr]
Sent: Friday, = July 06,=20 2001 5:21 AM
To: = mobile-ip@sunroof.eng.sun.com
Subject:=20 Re: [mobile-ip] Mobile IPv4 Authentication Internt Draft revision=20 0.1

Hi Shaji,
 
Please read my comment below,
 
----- Original Message ----- =
From:=20 Shaji Radhakrishnan
To: 'mobile-ip@sunroof.eng.sun.com'=20
Sent: Friday, July = 06, 2001 6:45 AM
Subject: = Re:[mobile-ip] Mobile IPv4=20 Authentication Internt Draft revision 0.1

Hi=20 JH Song,
 
I=20 have a small doubt regarding your draft.
 
According to RFC 3012, each = re-registration by the=20 mobile node SHOULD use different
challenge provided by the Foreign Agent = (either in=20 Agent advertisements or last registration = reply).
From your draft it is not clear = that  the=20 mobile node continue using the old key generated from the old=20 challenge
(i.e , the very first challenge in the=20 advertisement) or each generate a new key based on the new=20 challenge
received in the reply or advertisements. = One=20 solutions to this is that HA must also check the received=20 challenge
value in the registration request, = along with=20 NAI and or Home IP address.
 
The MN will be using new challenge for creating = MN-HA shared=20 that came along RRP upon every = re-registration.
However, it is not=20 necessary to keep updating MN-HA shared key upon every = re-registration,=20
because MN-HA = shared=20 key can be used until user terminate the MIP = session. =20
In addition if=20 the optional lifetime of MN-HA key is used, =
MN and HA will = refresh MN-HA=20 shared key only if the MN-HA share key lifetime is=20 expired.
Please see=20 section 4, Key Management of our Internet Draft 0.1=20 version.
 
........ <<my new reply=20 begins>>
 
I=20 agree that it is not necessay to update MN-HA key for each = re-registration.=20 But how does the HA
know that mobile node is using the = new key=20 (generated from the new challenge in latest RRP) or =
the old key? This is because for each = registration=20 reply, the Foreign Agent sends a new challenge
and mobile node sends this challenge to = HA in the=20 next re-registration request. At this moment, = which
key the mobile node should uses. The old = one from=20 already generated for the previous request or a = new
one generated from the last received = challenge?=20 Here two cases
If=20 the mobile node uses the old key and the new challenge, what should = HA=20 do?
If=20 the mobile ndoe uses the old key and old challenge, and is this = case, the FA=20 may reject the RRQ
with STALE_CHALLENGE or=20 UNKOWN_CHALLENGE.
Also what happens for the following=20 scenario:
The mobile node is not having any = idea about=20 the lifetime of the share-key. The mobile node = uses 
the old key, and the new challenge = received from=20 the last RRP, for the re-registration. Now=20 when
HA=20 receives this RRQ, suppose the life time is expired. So it will get = the new=20 key based on the
new challenge? 
 
What I meant is that HA should = compare the=20 challenge value in the re-registration
message to see whether it should use the = old cached key or to get a new key from = AAAh.
If=20 HA receives a challenge value different that that it used to get = the shared=20 key from AAAh earlier,  
it=20 should not matter whether previous key lifetime valid or not,=20 HA should get the new key since
Mobile node is using the new=20 key.
 
...... <<my new reply=20 ends>>
 
Also if mobile node is using new key = (since it used=20 the new challenge) in the re-registration, it MUST=20 include
the NAI in the registration request = eventhough=20 MN-AAA extension is not present, and only MN-HA authentication=20 extension
is=20 present. Then only AAAh can compute the = key in this=20 re-registration case.
 
If your concern=20 is not resolved until you read this, I must be misunderstand your=20 question.
 
The reason I use=20 the NAI rather than IP address on computing MN-HA shared key is to = support=20 Dynamic MIP case.
In that case,=20 NAI must be presence, therefore NAI can be replaced by MN IP = address.=20
And RFC-3012=20 state the case HA received MN-AAA authentication with FAC=20 extension.
Besides, AAA is=20 the entity that create the new MN-HA shared key, HA shall fetch or = receive=20 MN-HA shared key from AAA.
 
Could you=20 elaborate your question?
 
...... << my new reply begin>> = ...
 
You misunderstood my question. What I = meant is that=20 mobile node uses MN-AAA authentication with NAI
for the initial registartion. Then it = uses MN-HA=20 authenitcation and Home IP address for all subsequest =
re-registration. Is this case possible = that it is=20 not using NAI for subsequent re-registrations, but = only
non-zero home ip address. If this is the = case, no=20 NAI present for the home agent to get the new shared key=20 for
the re-registrations. This make=20 mandatory for the mobile node to send NAI in the re-registration = messages=20 along
with MN-HA = authentication extension.=20 This point was not clearly stated in your = document, =20
(sorry if I might have missed=20 it).
 
...... << my new reply ends>>=20 ...
 
Regards,
JH=20 SONG
 
Thanks
-=20 shaji
 
-----Original Message-----
From: junhyuk song=20 [mailto:junhyuk@metro.telecom.samsung.co.kr]
Sent: = Wednesday,=20 July 04, 2001 8:14 PM
To:=20 mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] = Mobile IPv4=20 Authentication Internt Draft revision 0.1

Hi All,

We recently submitted the = revision of Internet draft draft on "MIPv4 = Authentication Shared=20 Secret Generation.
 
draft-song-mobileip-mipv4-auth-secgeneration-01.txt =20

Regards,
JH=20 = SONG
------_=_NextPart_001_01C10630.B39A8B32-- From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 6 12:29:12 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11511 for ; Fri, 6 Jul 2001 12:29:11 -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 JAA06311; Fri, 6 Jul 2001 09:29: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 JAA27279; Fri, 6 Jul 2001 09:29:37 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f66GSYdP001620 for ; Fri, 6 Jul 2001 09:28:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f66GSXTP001619 for mobile-ip-dist; Fri, 6 Jul 2001 09:28: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.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f66GSUdP001612 for ; Fri, 6 Jul 2001 09:28:30 -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 JAA27108 for ; Fri, 6 Jul 2001 09:28:39 -0700 (PDT) Received: from rwc-ex0.corp.seven.com (rwc-ex0.windmz.seven.com [209.19.68.39]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA08887 for ; Fri, 6 Jul 2001 10:28:37 -0600 (MDT) x-mimeole: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message Subject: RE: [mobile-ip] I-D ACTION:draft-levkowetz-mobileip-nat-ipu-tunnel-00.txt MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 6 Jul 2001 09:29:35 -0700 Message-ID: Thread-Topic: [mobile-ip] I-D ACTION:draft-levkowetz-mobileip-nat-ipu-tunnel-00.txt Thread-Index: AcEFQbOyt2q5zKcqS96eFF1h6Nr1XAA9sDrg From: "Mayank Chaudhary" To: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f66GSUdP001613 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 Hi Henrik, good work. can you cite the patents that you mention in Section 6. Mayank Chaudhary Seven Networks From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 6 12:35:22 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11809 for ; Fri, 6 Jul 2001 12:35:22 -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 JAA07431; Fri, 6 Jul 2001 09:35:54 -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 JAA28081; Fri, 6 Jul 2001 09:35:50 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f66GZ0dP001672 for ; Fri, 6 Jul 2001 09:35:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f66GZ0gu001671 for mobile-ip-dist; Fri, 6 Jul 2001 09:35: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f66GYudP001664 for ; Fri, 6 Jul 2001 09:34:56 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA20871 for ; Fri, 6 Jul 2001 09:35:05 -0700 (PDT) From: Franck.Le@nokia.com Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA24008 for ; Fri, 6 Jul 2001 09:35:05 -0700 (PDT) Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f66GZSI27582 for ; Fri, 6 Jul 2001 11:35:38 -0500 (CDT) Received: from daebh02nok.americas.nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Fri, 6 Jul 2001 11:34:54 -0500 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id ; Fri, 6 Jul 2001 11:34:54 -0500 Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B041F8839@daeis07nok> To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Dynamic Home Agent Address Discovery mechanism Date: Fri, 6 Jul 2001 11:34:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) 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: Hello, The Mobile IPv6 specification (draft-ietf-mobileip-ipv6-14.txt) defines a Dynamic Home Agent Address Discovery mechanism (section 10.8): This mechanism offers more flexibility to the specification by allowing the mobile node to dynamically find the address of a suitable Home agent on its Home link. The mobile node may not know the address of any router on its home link that can serve as a home agent for it. Such mechanisms can for example be used when the router that was operating as the mobile node's home agent is being reconfigured or has been replaced by a different router serving this role. In order to provide the possibility of securing the home-agent discovery feature when required, the following improvements to the Mobile IPv6 specifications are proposed. The changes suggested which are a SHOULD and NOT a MUST are: * the home agents could require the ICMP Home Agent Address Discovery Request message to be authenticated and they will only reply to valid requests. Requests that do not pass authentication could be silently dropped. (or an error message be sent back, but without the source address being that of a valid home agent) * The Home Agent Discovery reply message could be authenticated, and whereas the currently specified ICMP Home Agent Address Discovery Reply message contains one or a list of the global unicast IP address of home agent operating on the home link; this information could be encrypted. * Finally the source IP address of the response packet sent to the originator SHOULD NOT be that of a Home Agent but some virtual address. Comments are welcome, Thank you, Franck From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 6 12:57:35 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12550 for ; Fri, 6 Jul 2001 12:57:34 -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 KAA21504; Fri, 6 Jul 2001 10:57: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 JAA20803; Fri, 6 Jul 2001 09:57:56 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f66GuwdP001733 for ; Fri, 6 Jul 2001 09:56:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f66GuvNk001732 for mobile-ip-dist; Fri, 6 Jul 2001 09: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f66GusdP001725 for ; Fri, 6 Jul 2001 09:56:54 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA24636 for ; Fri, 6 Jul 2001 09:57:03 -0700 (PDT) Received: from mailb.telia.com (mailb.telia.com [194.22.194.6]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA00757 for ; Fri, 6 Jul 2001 09:57:02 -0700 (PDT) Received: from parchment (h242n1fls33o801.telia.com [213.64.180.242]) by mailb.telia.com (8.9.3/8.9.3) with SMTP id SAA06754 for ; Fri, 6 Jul 2001 18:56:57 +0200 (CEST) From: "Henrik Levkowetz" To: Subject: RE: [mobile-ip] I-D ACTION:draft-levkowetz-mobileip-nat-ipu-tunnel-00.txt Date: Fri, 6 Jul 2001 18:57:40 +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: X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 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 Mayank, Thanks. ipUnplugged has one patent application which may be relevant to this draft, but no awarded patents currently. Best, Henrik Mayank wrote: > > > Hi Henrik, > good work. can you cite the patents that you mention in Section > 6. > > Mayank Chaudhary > Seven Networks > From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 6 13:14:23 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13081 for ; Fri, 6 Jul 2001 13:14: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 LAA28180; Fri, 6 Jul 2001 11:14: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 KAA22934; Fri, 6 Jul 2001 10:14:47 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f66HDZdP001788 for ; Fri, 6 Jul 2001 10:13:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f66HDZur001787 for mobile-ip-dist; Fri, 6 Jul 2001 10:13: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 centralmail1.Central.Sun.COM (centralmail1.Central.Sun.COM [129.147.62.10]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f66HDWdP001780 for ; Fri, 6 Jul 2001 10:13:32 -0700 (PDT) Received: from esun1as-mm. (esun1as-mm.Central.Sun.COM [129.147.34.144]) by centralmail1.Central.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id LAA13497; Fri, 6 Jul 2001 11:13:41 -0600 (MDT) Received: from sunyata.sun.com by esun1as-mm. (SMI-8.6/SMI-SVR4) id LAA07473; Fri, 6 Jul 2001 11:18:15 -0600 Message-Id: <5.0.0.25.0.20010706220851.01f18030@localhost> X-Sender: 5883@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Fri, 06 Jul 2001 22:13:26 -0700 To: mobile-ip@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com, seamoby@cdma-2000.org From: James Kempf Subject: Re: [mobile-ip] L2 API (WAS: Ext. for FMIPv6 - comments) In-Reply-To: <01D91AFB08B6D211BFD00008C7EABAE10680B265@eseis04nok> 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: John, (Folks, sorry for the cross posting, please try to respond on one or the other list unless the topic affects both...) There is a draft in preparation with people from both Seamoby and MIP on the author list. These are people with whom I have talked and who have expressed interest in working on such a draft over the last year. The draft has a section on L2 triggers that came out of the MIP fast handoff work, then a section that describes connections with Seamoby context transfer. I expect we will have it complete by next Fri.'s 00 deadline. We have already talked to the MIP WG chairs about getting time on the agenda to discuss the draft, what I'd like to suggest is that we do the same for Seamoby. That will give both WGs the opportunity to review and comment on the draft. I will talk with Pat about that when he gets back from vacation. jak At 10:13 AM 7/4/01 +0300, john.loughney@nokia.com wrote: >Hi James, > > > In fact, I am preparing just such a draft as we speak. The > > intent is to take the material from the BETH draft and from > > the FMIPv4 draft and perhaps add something on the link with > > Seamoby context transfer. > >I think this would be extremely worthwhile. It seems that >SeaMoby is currently struggling over terminology about >triggers, etc. with respect to handovers. I'd even suggest >that interested parties from both MIP & SeaMoby get together >in London to discuss how to move forward. Perhaps it would >be a good thing if MIP & SeaMoby could work together on this >issue - in order to assure that the resultant work suits both >groups. > >best regards, >John From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 6 13:56:46 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14458 for ; Fri, 6 Jul 2001 13:56:46 -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 LAA13917; Fri, 6 Jul 2001 11:57: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 KAA00654; Fri, 6 Jul 2001 10:57:05 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f66HtldP001852 for ; Fri, 6 Jul 2001 10:55:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f66HtkYe001851 for mobile-ip-dist; Fri, 6 Jul 2001 10:55: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f66HthdP001844 for ; Fri, 6 Jul 2001 10:55:43 -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 KAA00551 for ; Fri, 6 Jul 2001 10:55:53 -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 LAA13406 for ; Fri, 6 Jul 2001 11:55:50 -0600 (MDT) Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21) id ; Fri, 6 Jul 2001 13:55:06 -0400 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] WG last call: draft-ietf-mobileip-gen-key-00.txt Date: Fri, 6 Jul 2001 13:55:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) 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: This is a Mobile IP WG last call for the I-D draft-ietf-mobileip-gen-key-00.txt Generalized Key Extensions for Mobile IP. This draft will be sent to the IESG requesting a proposed standard status to be associated with it at the end of the last call period. Please send your comments to the WG discussion list. WG Last call issued on : Jul 5, 2001 Expires on : Jun 20, 2001 Basavaraj Patil Phil Roberts From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 6 14:46:34 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15831 for ; Fri, 6 Jul 2001 14:46:33 -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 MAA01835; Fri, 6 Jul 2001 12: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 LAA01663; Fri, 6 Jul 2001 11:47:00 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f66Ik5dP001961 for ; Fri, 6 Jul 2001 11:46:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f66Ik505001960 for mobile-ip-dist; Fri, 6 Jul 2001 11:46: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f66Ik1dP001953 for ; Fri, 6 Jul 2001 11:46:01 -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 LAA10595 for ; Fri, 6 Jul 2001 11:46:10 -0700 (PDT) Received: from mail.verizonwireless.com ([199.74.158.61]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA21853 for ; Fri, 6 Jul 2001 12:47:14 -0600 (MDT) Received: from mail.verizonwireless.com by mail.verizonwireless.com (414/1100) with ESMTP id f66IaAk25456 for ; Fri, 6 Jul 2001 14:36:10 -0400 (EDT) Received: by hqbedigwy1.corp.bam.com with Internet Mail Service (5.5.2653.19) id ; Fri, 6 Jul 2001 14:41:32 -0400 Message-ID: <43E8CCEAF148D211854C00805FA72E580701988E@rhqnneex1.corp.bam.com> From: "Carroll, Christopher X" To: "'mobile-ip@sunroof.eng.sun.com'" Cc: "Flynn, Gerry J" Subject: RE: [mobile-ip] Mobile IPv4 Authentication Internt Draft revision 0.1 Date: Fri, 6 Jul 2001 14:46:33 -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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Junhyuk, Some initial comments on your revision: The current proposal is so different from your original proposal that it probably should not be considered a revision. The only common theme between your current and initial proposal appears to be the concept of using the FAC (randomness generated by a visited network) to derive the MN-HA key (and MN-FA key). I must reiterate my significant concern that your proposal allows any visited network to control the derivation of a home network security association (SA) - the MN-HA key. Why open the door for possible manipulation of the MN-HA key by a fraudulent/Rogue FA? It appears that your primary concern with the Perkin/Calhoun proposal is the possible inefficiency of using explicit messages to generate a unique MN-HA key for each dynamically assigned HA. Unfortunately, there is always a trade-off between security and efficiency. Apparently you believe that generation of the MN-HA key from the FAC is more efficient, however you must concede that it is less secure than allowing the home network to control the MN-HA key generation. Are you sure that MN-HA key derivation based on the FAC is more efficient? In your proposal, the MN-HA key is generated every time the MN initially registers in a new system at least. Thus, the MN-HA key must be requested/passed to the HA from the AAAh for each new "MIP session". In the Perkins/Calhoun proposal, the MN-HA key may be Update once/month, once/year, or even once while still providing adequate security (based on at least a 90-bit key). How often do you envision that dynamic HA assignment will occur? The Perkins/Calhoun proposal requires MN-HA key update only when an new HA is assigned to the MN. Although not described in the Perkins/Calhoun proposal, it appears that the MN could store multiple MN-HA keys (for multiple HAs) simultaneously. Thus, when the MN is dynamically re-assigned to an HA in which an MN-HA key was previously derived, the MN need not perform a new key update. The MN might use a FIFO queue to hold up to 10 MN-HA keys (for 10 different HAs). Each HA could retain the MN-HA key associated with a particular MN (based on the MN's NAI and an internal lifetimer). If the MN is assigned an HA for which it has no MN-HA key, it initiates a MN-HA key Update, puts the new key in the queue, and bumps out the oldest assigned MN-HA key (Note: the queue could likely be much larger! - holding dozens of MN-HA keys for dozens of HAs). The generic Perkins/Calhoun approach or my MN-HA key queuing approach appears equally scalable, but more efficient than automatically generating a new MN-HA key during each new MIP session. The entropy issue in your proposal is not significant where the secret key and randomness used to generate a subordinate key is large enough. The Perkins/Calhoun proposal defines the "Key Material" to be at least 64-bits which is large enough. A larger random variable may be more secure, but 64-bits is more than enough to ensure MN-HA key freshness. The purpose of using randomness for key agreement is to ensure that derived key is unique. The security of the key agreement algorithm is based on the properties of the algorithm (i.e. one-wayness) and the size (security strength) of the root secret key. Finally - I arrive at the security issues associated with using the FAC to generate the MN-HA key. There is always a danger in using a procedure/protocol that was originally intended for one purpose for another. If you use the FAC only to generate the MN-FA key or some other local key(s), I have no objection to such an approach because those keys provide security for the visited network only. Both 3GPP and 3GPP2 use locally generated keys for local session privacy and authentication (IK and CK for 3GPP is generated in the UIM). The home network doesn't care (to a certain degree) whether the roamer/visitor uses proper security procedures, because the home network always gets payed for the access (fraudulent or not based on the Roaming Agreement between the home and visited service provider). However, the home network provider is very concerned about giving away possible authentication information to visited network which could cost the home network. In your proposal, the MN-HA key == HMAC-MD5 (MN-AAA key, FAC, MN NAI, MN-AAA key). The only variable is the FAC which is control by the FA! You appear to rely heavily on the fact that the MN will use a timestamp in the RRQ to eventually protect the MN-HA key Update. Where does the MN get system time from? In cdma2000, the MN may us the broadcast network time (with or without NTP) which implies that a Rogue FA, impersonating the network, can also manipulate the MNs own timestamp and trick the MN into pre-computing RRQs for the future. If the Rogue FA can predict the FAC used by a legitimate FA (i.e. the legitimate FA updates FAC infrequently), then the rogue FA can act as a clone MN and obtain access to the target network in the future. This attack won't work against the Perkins/Calhoun proposal unless the Rogue FA can predict the randomness used in the "Key Material" which is impractical (however the MN-HA key would have to be updated to prevent it). The attack is relatively sophisticated, but perhaps government X wants to monitor packets sent to a citizen (or official) of government Y. Government X would only need to trick the MN into precomputing RRQs (it wouldn't care about cloning) in order to re-route packet traffic to the its own FA in the future. I admit that the above attack requires the MN to generate timestamps based on the 3GPP2(cdma2000) network system time and/or NTP(spoofed by a fraudulent FA). Also in the cloning scenario, the fraudulent FA would have to predict the legitimate FA's FAC. However, my concern is that these are only an initial potential attacks based on analyzing your proposal for less than one day. It is not good security practice to allow a third party to manipulate the SA between two entities unless that third party can be completely trusted. In Appendix B you define MN-FA key generation - the current proposal specifies that the MN-FA == HMAC-MD5 (MN-HA key, FA IP address, FAC, NAI). Because the MN-FA is now dependent on the MN-HA key, it appears that a new MN-HA key must be generated for each MIP session (as you call it) in order to update the MN-FA key. Doesn't this defeat the purpose of the MN-HA Optional Lifetime feature? Can the FAC used to generate the MN-FA and MN-HA key be different ? Let me know what you think. regards, chris ********************************************************************** Christopher Carroll Office: 508-330-3401 Senior Member Technical Staff fax: 508-330-3403 Verizon Wireless cellular: 781-424-4131 Chair TR-45 Adhoc Authentication Group email: christopher.carroll@verizonwireless.com ********************************************************************** From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 6 20:19:19 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA24452 for ; Fri, 6 Jul 2001 20:19:18 -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 RAA04021; Fri, 6 Jul 2001 17:19:44 -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 RAA02855; Fri, 6 Jul 2001 17:19:35 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f670HtdP002180 for ; Fri, 6 Jul 2001 17:17:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f670HtoK002179 for mobile-ip-dist; Fri, 6 Jul 2001 17:17: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.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f670HpdP002172 for ; Fri, 6 Jul 2001 17:17:51 -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 RAA29834 for ; Fri, 6 Jul 2001 17:18:01 -0700 (PDT) Received: from ms.samsung.com ([211.45.29.136]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA08801 for ; Fri, 6 Jul 2001 18:17:58 -0600 (MDT) Received: from CYCHONG ([203.241.48.20]) by ms.samsung.com (Netscape Messaging Server 4.15) with SMTP id GG2TZU03.T0M for ; Sat, 7 Jul 2001 09:14:18 +0900 Message-ID: <003201c1067a$666e83a0$10e0d5a5@cdma2000system.samsung.co.kr> From: "Chae-yong Chong" To: References: <8D9C6ADAD0DBD4119F8D00508BF7CBD1FB5D@apo.watercove.com> Subject: Re: [mobile-ip] Mobile IPv4 Authentication Internt Draft revision 0.1 Date: Sat, 7 Jul 2001 09:18:51 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002F_01C106C5.D62DBC10" 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: This is a multi-part message in MIME format. ------=_NextPart_000_002F_01C106C5.D62DBC10 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SSBzdW1tYXJpemUgdGhlIG5ldyBleHRlbnNpb25zIGZvciBNb2JpbGUgSVAgcmVnaXN0cmF0aW9u Lg0KWW91IGNhbiBzZWUgdGhlIE5BSSBpcyBhdXRoZW50aWNhdGVkIHdpdGggdGhlIE1OLUhBIGF1 dGhlbnRpY2F0aW9uIGV4dGVuc2lvbi4NClRoZXJlZm9yZSBOTyBNTi1BQUEgYXV0aGVudGljYXRp b24gZXh0ZW5zaW9uIGlzIHJlcXVpcmVkIHRvIGF1dGhlbnRpY2F0ZSBOQUkgZXh0ZW5zaW9uLg0K DQpJZiBNb2JpbGUgTm9kZSBkbyB0aGUgcmUtZ2VuZXJhdGlvbiBhIHNoYXJlZCBrZXksIGl0IGlu Y2x1ZGUgTU4tQUFBIGV4dGVuc2lvbiB0byBhdXRoZW50aWNhdGUNCmEgRkFDIHdoaWNoIGlzIHVz ZWQgaW4gbmV3IGtleSBnZW5lcmF0aW9uIGFuZCBIQSBzaG91bGQgYXV0aGVudGljYXRpZSB0aGUg RkFDIGJ5IGFza2luZyBBQUFoDQp0byB2YWxpZGF0ZSB0aGUgTU4tQUFBIGF1dGhlbnRpY2F0aW9u IGV4dGVuc2lvbiB0byBBQUFoLg0KDQoNCg0KZnJvbSByZmMzMDEyDQotLS0tLS0tLS0tLS0NCg0K SW4gZWl0aGVyIGNhc2UsIHRoZSBNTi1GQSBDaGFsbGVuZ2UgZXh0ZW5zaW9uIGFuZCBvbmUgb2Yg dGhlIGFib3ZlDQpzcGVjaWZpZWQgYXV0aGVudGljYXRpb24gZXh0ZW5zaW9ucyBNVVNUIGZvbGxv dyB0aGUgTW9iaWxlLUhvbWUNCkF1dGhlbnRpY2F0aW9uIGV4dGVuc2lvbiwgaWYgcHJlc2VudC4N Ci0+IE1OLUhBIHwgRkFDDQoNCkZ1cnRoZXJtb3JlLCB0aGUgRm9yZWlnbiBBZ2VudCBNVVNUIGNo ZWNrIHRoYXQgdGhlcmUgaXMgZWl0aGVyDQphIE1vYmlsZS1Gb3JlaWduLCBvciBhIE1OLUFBQSBB dXRoZW50aWNhdGlvbiBleHRlbnNpb24gYWZ0ZXINCnRoZSBDaGFsbGVuZ2UgZXh0ZW5zaW9uLiAN Ci0+IEZBQyB8IE1OLUZBIG9yIE1OLUFBQQ0KDQpJZiBwcmVzZW50LCB0aGUgTW9iaWxlLUhBIEF1 dGhlbnRpY2F0aW9uIEV4dGVuc2lvbiBNVVNUIGFwcGVhciBwcmlvciB0byB0aGUNCk1OLUFBQSBB dXRoZW50aWNhdGlvbiBleHRlbnNpb24uIA0KLT4gTU4tSEEgfCBNTi1BQUENCg0KZnJvbSBSRkMg Mjc5NA0KLS0tLS0tLS0tLS0tLS0NCg0KVGhlIE1vYmlsZSBOb2RlIE5BSSBleHRlbnNpb24gTVVT VCBhcHBlYXIgaW4gdGhlIFJlZ2lzdHJhdGlvbiBSZXF1ZXN0DQpiZWZvcmUgYm90aCB0aGUgTW9i aWxlLUhvbWUgQXV0aGVudGljYXRpb24gZXh0ZW5zaW9uIGFuZCBNb2JpbGUtDQpGb3JlaWduIEF1 dGhlbnRpY2F0aW9uIGV4dGVuc2lvbiwgaWYgcHJlc2VudC4NCi0+IE5BSSB8IE1OLUhBDQoNCiAN Cj0+IE5BSSB8IE1OLUhBIHwgRkFDIHwgTU4tRkEgfCBNTi1BQUENCg0KDQpJZiB0aGUgZm9yZWln biBhZ2VudCBpbmNsdWRlcw0KdGhpcyBleHRlbnNpb24gaW4gYSBzdWNjZXNzZnVsIFJlZ2lzdHJh dGlvbiBSZXBseSwgdGhlIGV4dGVuc2lvbg0KU0hPVUxEIHByZWNlZGUgYSBNTi1GQSBhdXRoZW50 aWNhdGlvbiBleHRlbnNpb24uDQotPiBuZXcgRkFDIHwgTU4tRkENCg0KVGhhbmtzLg0KY3ljaG9u Zw0KICAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KICBGcm9tOiBTaGFqaSBSYWRoYWty aXNobmFuIA0KICBUbzogJ21vYmlsZS1pcEBzdW5yb29mLmVuZy5zdW4uY29tJyANCiAgU2VudDog RnJpZGF5LCBKdWx5IDA2LCAyMDAxIDY6NDUgQU0NCiAgU3ViamVjdDogUmU6W21vYmlsZS1pcF0g TW9iaWxlIElQdjQgQXV0aGVudGljYXRpb24gSW50ZXJudCBEcmFmdCByZXZpc2lvbiAwLjENCg0K DQogIEhpIEpIIFNvbmcsDQogICANCiAgSSBoYXZlIGEgc21hbGwgZG91YnQgcmVnYXJkaW5nIHlv dXIgZHJhZnQuDQogICANCiAgQWNjb3JkaW5nIHRvIFJGQyAzMDEyLCBlYWNoIHJlLXJlZ2lzdHJh dGlvbiBieSB0aGUgbW9iaWxlIG5vZGUgU0hPVUxEIHVzZSBkaWZmZXJlbnQgDQogIGNoYWxsZW5n ZSBwcm92aWRlZCBieSB0aGUgRm9yZWlnbiBBZ2VudCAoZWl0aGVyIGluIEFnZW50IGFkdmVydGlz ZW1lbnRzIG9yIGxhc3QgcmVnaXN0cmF0aW9uIHJlcGx5KS4NCiAgRnJvbSB5b3VyIGRyYWZ0IGl0 IGlzIG5vdCBjbGVhciB0aGF0ICB0aGUgbW9iaWxlIG5vZGUgY29udGludWUgdXNpbmcgdGhlIG9s ZCBrZXkgZ2VuZXJhdGVkIGZyb20gdGhlIG9sZCBjaGFsbGVuZ2UNCiAgKGkuZSAsIHRoZSB2ZXJ5 IGZpcnN0IGNoYWxsZW5nZSBpbiB0aGUgYWR2ZXJ0aXNlbWVudCkgb3IgZWFjaCBnZW5lcmF0ZSBh IG5ldyBrZXkgYmFzZWQgb24gdGhlIG5ldyBjaGFsbGVuZ2UNCiAgcmVjZWl2ZWQgaW4gdGhlIHJl cGx5IG9yIGFkdmVydGlzZW1lbnRzLiBPbmUgc29sdXRpb25zIHRvIHRoaXMgaXMgdGhhdCBIQSBt dXN0IGFsc28gY2hlY2sgdGhlIHJlY2VpdmVkIGNoYWxsZW5nZQ0KICB2YWx1ZSBpbiB0aGUgcmVn aXN0cmF0aW9uIHJlcXVlc3QsIGFsb25nIHdpdGggTkFJIGFuZCBvciBIb21lIElQIGFkZHJlc3Mu DQogICANCiAgQWxzbyBpZiBtb2JpbGUgbm9kZSBpcyB1c2luZyBuZXcga2V5IChzaW5jZSBpdCB1 c2VkIHRoZSBuZXcgY2hhbGxlbmdlKSBpbiB0aGUgcmUtcmVnaXN0cmF0aW9uLCBpdCBNVVNUIGlu Y2x1ZGUNCiAgdGhlIE5BSSBpbiB0aGUgcmVnaXN0cmF0aW9uIHJlcXVlc3QgZXZlbnRob3VnaCBN Ti1BQUEgZXh0ZW5zaW9uIGlzIG5vdCBwcmVzZW50LCBhbmQgb25seSBNTi1IQSBhdXRoZW50aWNh dGlvbiBleHRlbnNpb24NCiAgaXMgcHJlc2VudC4gVGhlbiBvbmx5IEFBQWggY2FuIGNvbXB1dGUg dGhlIGtleSBpbiB0aGlzIHJlLXJlZ2lzdHJhdGlvbiBjYXNlLg0KICAgDQogIFRoYW5rcw0KICAt IHNoYWppDQogICANCiAgICAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KICAgIEZyb206IGp1 bmh5dWsgc29uZyBbbWFpbHRvOmp1bmh5dWtAbWV0cm8udGVsZWNvbS5zYW1zdW5nLmNvLmtyXQ0K ICAgIFNlbnQ6IFdlZG5lc2RheSwgSnVseSAwNCwgMjAwMSA4OjE0IFBNDQogICAgVG86IG1vYmls ZS1pcEBzdW5yb29mLmVuZy5zdW4uY29tDQogICAgU3ViamVjdDogW21vYmlsZS1pcF0gTW9iaWxl IElQdjQgQXV0aGVudGljYXRpb24gSW50ZXJudCBEcmFmdCByZXZpc2lvbiAwLjENCg0KDQogICAg SGkgQWxsLA0KDQogICAgV2UgcmVjZW50bHkgc3VibWl0dGVkIHRoZSByZXZpc2lvbiBvZiBJbnRl cm5ldCBkcmFmdCBkcmFmdCBvbiAiTUlQdjQgQXV0aGVudGljYXRpb24gU2hhcmVkIFNlY3JldCBH ZW5lcmF0aW9uLg0KICAgICANCiAgICBkcmFmdC1zb25nLW1vYmlsZWlwLW1pcHY0LWF1dGgtc2Vj Z2VuZXJhdGlvbi0wMS50eHQgIA0KDQoNCiAgICBSZWdhcmRzLA0KICAgIEpIIFNPTkcNCg0K ------=_NextPart_000_002F_01C106C5.D62DBC10 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWtz X2NfNTYwMS0xOTg3IiBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZT4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA1LjAwLjMzMTUuMjg3MCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPkkgc3VtbWFy aXplIHRoZSBuZXcgZXh0ZW5zaW9ucyBmb3IgTW9iaWxlIElQIA0KcmVnaXN0cmF0aW9uLjwvRk9O VD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPllvdSBjYW4gc2VlIHRoZSBOQUkgaXMgYXV0aGVu dGljYXRlZCB3aXRoIHRoZSBNTi1IQSANCmF1dGhlbnRpY2F0aW9uIGV4dGVuc2lvbi48L0ZPTlQ+ PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5UaGVyZWZvcmUgTk8gTU4tQUFBIGF1dGhlbnRpY2F0 aW9uIGV4dGVuc2lvbiBpcyByZXF1aXJlZCB0byANCmF1dGhlbnRpY2F0ZSBOQUkgZXh0ZW5zaW9u LjwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5JZiBN b2JpbGUgTm9kZSBkbyB0aGUgcmUtZ2VuZXJhdGlvbiBhIHNoYXJlZCBrZXksIGl0IGluY2x1ZGUg DQpNTi1BQUEgZXh0ZW5zaW9uIHRvIGF1dGhlbnRpY2F0ZTwvRk9OVD48L0RJVj4NCjxESVY+PEZP TlQgc2l6ZT0yPmEgRkFDIHdoaWNoIGlzIHVzZWQgaW4gbmV3IGtleSBnZW5lcmF0aW9uIGFuZCBI QSBzaG91bGQgDQphdXRoZW50aWNhdGllIHRoZSBGQUMgYnkgYXNraW5nIEFBQWg8L0ZPTlQ+PC9E SVY+DQo8RElWPjxGT05UIHNpemU9Mj50byB2YWxpZGF0ZSA8L0ZPTlQ+PEZPTlQgc2l6ZT0yPnRo ZSBNTi1BQUEgYXV0aGVudGljYXRpb24gDQpleHRlbnNpb24gdG8gQUFBaC48L0ZPTlQ+PC9ESVY+ DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+ DQo8RElWPjxGT05UIHNpemU9Mj5mcm9tIHJmYzMwMTI8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05U IHNpemU9Mj4tLS0tLS0tLS0tLS08L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJ Vj48Rk9OVCBzaXplPTI+SW4gZWl0aGVyIGNhc2UsIHRoZSBNTi1GQSBDaGFsbGVuZ2UgZXh0ZW5z aW9uIGFuZCBvbmUgb2YgdGhlIA0KYWJvdmU8QlI+c3BlY2lmaWVkIGF1dGhlbnRpY2F0aW9uIGV4 dGVuc2lvbnMgTVVTVCBmb2xsb3cgdGhlIA0KTW9iaWxlLUhvbWU8QlI+QXV0aGVudGljYXRpb24g ZXh0ZW5zaW9uLCBpZiBwcmVzZW50LjxCUj4tJmd0OyBNTi1IQSB8IA0KRkFDPC9GT05UPjwvRElW Pg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPkZ1cnRoZXJtb3JlLCB0aGUg Rm9yZWlnbiBBZ2VudCBNVVNUIGNoZWNrIHRoYXQgdGhlcmUgaXMgDQplaXRoZXI8QlI+YSBNb2Jp bGUtRm9yZWlnbiwgb3IgYSBNTi1BQUEgQXV0aGVudGljYXRpb24gZXh0ZW5zaW9uIGFmdGVyPEJS PnRoZSANCkNoYWxsZW5nZSBleHRlbnNpb24uIDxCUj4tJmd0OyBGQUMgfCBNTi1GQSBvciBNTi1B QUE8L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+SWYg cHJlc2VudCwgdGhlIE1vYmlsZS1IQSBBdXRoZW50aWNhdGlvbiBFeHRlbnNpb24gTVVTVCBhcHBl YXIgDQpwcmlvciB0byB0aGU8QlI+TU4tQUFBIEF1dGhlbnRpY2F0aW9uIGV4dGVuc2lvbi4gPEJS Pi0mZ3Q7IE1OLUhBIHwgDQpNTi1BQUE8L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0K PERJVj48Rk9OVCBzaXplPTI+ZnJvbSBSRkMgMjc5NDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQg c2l6ZT0yPi0tLS0tLS0tLS0tLS0tPC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxE SVY+PEZPTlQgc2l6ZT0yPlRoZSBNb2JpbGUgTm9kZSBOQUkgZXh0ZW5zaW9uIE1VU1QgYXBwZWFy IGluIHRoZSBSZWdpc3RyYXRpb24gDQpSZXF1ZXN0PEJSPmJlZm9yZSBib3RoIHRoZSBNb2JpbGUt SG9tZSBBdXRoZW50aWNhdGlvbiBleHRlbnNpb24gYW5kIA0KTW9iaWxlLTxCUj5Gb3JlaWduIEF1 dGhlbnRpY2F0aW9uIGV4dGVuc2lvbiwgaWYgcHJlc2VudC48QlI+LSZndDsgTkFJIHwgDQpNTi1I QTwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZP TlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj49Jmd0OyBOQUkgfCBNTi1IQSB8IEZB QyB8IE1OLUZBIHwgTU4tQUFBPC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+ PEZPTlQgc2l6ZT0yPjxCUj5JZiB0aGUgZm9yZWlnbiBhZ2VudCBpbmNsdWRlczxCUj50aGlzIGV4 dGVuc2lvbiBpbiBhIA0Kc3VjY2Vzc2Z1bCBSZWdpc3RyYXRpb24gUmVwbHksIHRoZSBleHRlbnNp b248QlI+U0hPVUxEIHByZWNlZGUgYSBNTi1GQSANCmF1dGhlbnRpY2F0aW9uIGV4dGVuc2lvbi48 QlI+LSZndDsgbmV3IEZBQyB8IE1OLUZBPC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4N CjxESVY+PEZPTlQgc2l6ZT0yPlRoYW5rcy48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9 Mj5jeWNob25nPC9GT05UPjwvRElWPg0KPEJMT0NLUVVPVEUgDQpzdHlsZT0iQk9SREVSLUxFRlQ6 ICMwMDAwMDAgMnB4IHNvbGlkOyBNQVJHSU4tTEVGVDogNXB4OyBNQVJHSU4tUklHSFQ6IDBweDsg UEFERElORy1MRUZUOiA1cHg7IFBBRERJTkctUklHSFQ6IDBweCI+DQogIDxESVYgc3R5bGU9IkZP TlQ6IDEwcHQgsby4siI+LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSA8L0RJVj4NCiAgPERJ ViANCiAgc3R5bGU9IkJBQ0tHUk9VTkQ6ICNlNGU0ZTQ7IEZPTlQ6IDEwcHQgsby4sjsgZm9udC1j b2xvcjogYmxhY2siPjxCPkZyb206PC9CPiA8QSANCiAgaHJlZj0ibWFpbHRvOnNyYWRoYWtyaXNo bmFuQHdhdGVyY292ZS5jb20iIA0KICB0aXRsZT1zcmFkaGFrcmlzaG5hbkB3YXRlcmNvdmUuY29t PlNoYWppIFJhZGhha3Jpc2huYW48L0E+IDwvRElWPg0KICA8RElWIHN0eWxlPSJGT05UOiAxMHB0 ILG8uLIiPjxCPlRvOjwvQj4gPEEgDQogIGhyZWY9Im1haWx0bzonbW9iaWxlLWlwQHN1bnJvb2Yu ZW5nLnN1bi5jb20nIiANCiAgdGl0bGU9bW9iaWxlLWlwQHN1bnJvb2YuZW5nLnN1bi5jb20+J21v YmlsZS1pcEBzdW5yb29mLmVuZy5zdW4uY29tJzwvQT4gPC9ESVY+DQogIDxESVYgc3R5bGU9IkZP TlQ6IDEwcHQgsby4siI+PEI+U2VudDo8L0I+IEZyaWRheSwgSnVseSAwNiwgMjAwMSA2OjQ1IEFN PC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDEwcHQgsby4siI+PEI+U3ViamVjdDo8L0I+IFJl Olttb2JpbGUtaXBdIE1vYmlsZSBJUHY0IA0KICBBdXRoZW50aWNhdGlvbiBJbnRlcm50IERyYWZ0 IHJldmlzaW9uIDAuMTwvRElWPg0KICA8RElWPjxCUj48L0RJVj4NCiAgPERJVj48Rk9OVCBjb2xv cj0jMDAwMGZmIGZhY2U9QXJpYWwgc2l6ZT0yPjxTUEFOIGNsYXNzPTI4NTE1MzEyMS0wNTA3MjAw MT5IaSANCiAgSkggU29uZyw8L1NQQU4+PC9GT05UPjwvRElWPg0KICA8RElWPjxGT05UIGNvbG9y PSMwMDAwZmYgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gDQogIGNsYXNzPTI4NTE1MzEyMS0wNTA3 MjAwMT48L1NQQU4+PC9GT05UPiZuYnNwOzwvRElWPg0KICA8RElWPjxGT05UIGNvbG9yPSMwMDAw ZmYgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gY2xhc3M9Mjg1MTUzMTIxLTA1MDcyMDAxPkkgDQog IGhhdmUgYSBzbWFsbCBkb3VidCByZWdhcmRpbmcgeW91ciBkcmFmdC48L1NQQU4+PC9GT05UPjwv RElWPg0KICA8RElWPjxGT05UIGNvbG9yPSMwMDAwZmYgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4g DQogIGNsYXNzPTI4NTE1MzEyMS0wNTA3MjAwMT48L1NQQU4+PC9GT05UPiZuYnNwOzwvRElWPg0K ICA8RElWPjxGT05UIGNvbG9yPSMwMDAwZmYgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gDQogIGNs YXNzPTI4NTE1MzEyMS0wNTA3MjAwMT5BY2NvcmRpbmcgdG8gUkZDIDMwMTIsIGVhY2ggcmUtcmVn aXN0cmF0aW9uIGJ5IHRoZSANCiAgbW9iaWxlIG5vZGUgU0hPVUxEIHVzZSBkaWZmZXJlbnQgPC9T UEFOPjwvRk9OVD48L0RJVj4NCiAgPERJVj48Rk9OVCBjb2xvcj0jMDAwMGZmIGZhY2U9QXJpYWwg c2l6ZT0yPjxTUEFOIA0KICBjbGFzcz0yODUxNTMxMjEtMDUwNzIwMDE+Y2hhbGxlbmdlIHByb3Zp ZGVkIGJ5IHRoZSBGb3JlaWduIEFnZW50IChlaXRoZXIgaW4gDQogIEFnZW50IGFkdmVydGlzZW1l bnRzIG9yIGxhc3QgcmVnaXN0cmF0aW9uIHJlcGx5KS48L1NQQU4+PC9GT05UPjwvRElWPg0KICA8 RElWPjxGT05UIGNvbG9yPSMwMDAwZmYgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gY2xhc3M9Mjg1 MTUzMTIxLTA1MDcyMDAxPkZyb20gDQogIHlvdXImbmJzcDtkcmFmdCBpdCBpcyBub3QgY2xlYXIg dGhhdCAmbmJzcDt0aGUgbW9iaWxlIG5vZGUgY29udGludWUgdXNpbmcgdGhlIA0KICBvbGQga2V5 IGdlbmVyYXRlZCBmcm9tIHRoZSBvbGQgY2hhbGxlbmdlPC9TUEFOPjwvRk9OVD48L0RJVj4NCiAg PERJVj48Rk9OVCBjb2xvcj0jMDAwMGZmIGZhY2U9QXJpYWwgc2l6ZT0yPjxTUEFOIGNsYXNzPTI4 NTE1MzEyMS0wNTA3MjAwMT4oaS5lIA0KICAsIHRoZSB2ZXJ5IGZpcnN0IGNoYWxsZW5nZSBpbiB0 aGUgYWR2ZXJ0aXNlbWVudCkgb3IgZWFjaCBnZW5lcmF0ZSBhIG5ldyBrZXkgDQogIGJhc2VkIG9u IHRoZSBuZXcgY2hhbGxlbmdlPC9TUEFOPjwvRk9OVD48L0RJVj4NCiAgPERJVj48Rk9OVCBjb2xv cj0jMDAwMGZmIGZhY2U9QXJpYWwgc2l6ZT0yPjxTUEFOIA0KICBjbGFzcz0yODUxNTMxMjEtMDUw NzIwMDE+cmVjZWl2ZWQgaW4gdGhlIHJlcGx5IG9yIGFkdmVydGlzZW1lbnRzLiBPbmUgDQogIHNv bHV0aW9ucyB0byB0aGlzIGlzIHRoYXQgSEEmbmJzcDttdXN0IGFsc28gY2hlY2sgdGhlIHJlY2Vp dmVkIA0KICBjaGFsbGVuZ2U8L1NQQU4+PC9GT05UPjxGT05UIGNvbG9yPSMwMDAwZmYgZmFjZT1B cmlhbCBzaXplPTI+PFNQQU4gDQogIGNsYXNzPTI4NTE1MzEyMS0wNTA3MjAwMT48L1NQQU4+PC9G T05UPjwvRElWPg0KICA8RElWPjxGT05UIGNvbG9yPSMwMDAwZmYgZmFjZT1BcmlhbCBzaXplPTI+ PFNQQU4gDQogIGNsYXNzPTI4NTE1MzEyMS0wNTA3MjAwMT52YWx1ZSZuYnNwO2luIHRoZSByZWdp c3RyYXRpb24gcmVxdWVzdCwgYWxvbmcgd2l0aCANCiAgTkFJIGFuZCBvciBIb21lIElQIGFkZHJl c3MuPC9TUEFOPjwvRk9OVD48L0RJVj4NCiAgPERJVj48Rk9OVCBjb2xvcj0jMDAwMGZmIGZhY2U9 QXJpYWwgc2l6ZT0yPjxTUEFOIA0KICBjbGFzcz0yODUxNTMxMjEtMDUwNzIwMDE+PC9TUEFOPjwv Rk9OVD4mbmJzcDs8L0RJVj4NCiAgPERJVj48Rk9OVCBjb2xvcj0jMDAwMGZmIGZhY2U9QXJpYWwg c2l6ZT0yPjxTUEFOIGNsYXNzPTI4NTE1MzEyMS0wNTA3MjAwMT5BbHNvIA0KICBpZiBtb2JpbGUg bm9kZSBpcyB1c2luZyBuZXcga2V5IChzaW5jZSBpdCB1c2VkIHRoZSBuZXcgY2hhbGxlbmdlKSBp biB0aGUgDQogIHJlLXJlZ2lzdHJhdGlvbiwgaXQgTVVTVCBpbmNsdWRlPC9TUEFOPjwvRk9OVD48 L0RJVj4NCiAgPERJVj48Rk9OVCBjb2xvcj0jMDAwMGZmIGZhY2U9QXJpYWwgc2l6ZT0yPjxTUEFO IGNsYXNzPTI4NTE1MzEyMS0wNTA3MjAwMT50aGUgDQogIE5BSSBpbiB0aGUgcmVnaXN0cmF0aW9u IHJlcXVlc3QgZXZlbnRob3VnaCBNTi1BQUEgZXh0ZW5zaW9uIGlzIG5vdCBwcmVzZW50LCANCiAg YW5kIG9ubHkgTU4tSEEgYXV0aGVudGljYXRpb24gZXh0ZW5zaW9uPC9TUEFOPjwvRk9OVD48L0RJ Vj4NCiAgPERJVj48Rk9OVCBjb2xvcj0jMDAwMGZmIGZhY2U9QXJpYWwgc2l6ZT0yPjxTUEFOIGNs YXNzPTI4NTE1MzEyMS0wNTA3MjAwMT5pcyANCiAgcHJlc2VudC48L1NQQU4+PC9GT05UPjxGT05U IGNvbG9yPSMwMDAwZmYgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gDQogIGNsYXNzPTI4NTE1MzEy MS0wNTA3MjAwMT4gVGhlbiBvbmx5IEFBQWggY2FuIGNvbXB1dGUgdGhlIGtleSZuYnNwO2luIHRo aXMgDQogIHJlLXJlZ2lzdHJhdGlvbiBjYXNlLjwvU1BBTj48L0ZPTlQ+PC9ESVY+DQogIDxESVY+ PEZPTlQgY29sb3I9IzAwMDBmZiBmYWNlPUFyaWFsIHNpemU9Mj48U1BBTiANCiAgY2xhc3M9Mjg1 MTUzMTIxLTA1MDcyMDAxPjwvU1BBTj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQogIDxESVY+PEZPTlQg Y29sb3I9IzAwMDBmZiBmYWNlPUFyaWFsIHNpemU9Mj48U1BBTiANCiAgY2xhc3M9Mjg1MTUzMTIx LTA1MDcyMDAxPlRoYW5rczwvU1BBTj48L0ZPTlQ+PC9ESVY+DQogIDxESVY+PEZPTlQgY29sb3I9 IzAwMDBmZiBmYWNlPUFyaWFsIHNpemU9Mj48U1BBTiBjbGFzcz0yODUxNTMxMjEtMDUwNzIwMDE+ LSANCiAgc2hhamk8L1NQQU4+PC9GT05UPjwvRElWPg0KICA8RElWPjxGT05UIGNvbG9yPSMwMDAw ZmYgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gDQogIGNsYXNzPTI4NTE1MzEyMS0wNTA3MjAwMT4m bmJzcDs8L1NQQU4+PC9GT05UPjwvRElWPg0KICA8QkxPQ0tRVU9URSBzdHlsZT0iTUFSR0lOLVJJ R0hUOiAwcHgiPg0KICAgIDxESVYgYWxpZ249bGVmdCBjbGFzcz1PdXRsb29rTWVzc2FnZUhlYWRl ciBkaXI9bHRyPjxGT05UIGZhY2U9VGFob21hIA0KICAgIHNpemU9Mj4tLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLTxCUj48Qj5Gcm9tOjwvQj4ganVuaHl1ayBzb25nIA0KICAgIFttYWlsdG86anVu aHl1a0BtZXRyby50ZWxlY29tLnNhbXN1bmcuY28ua3JdPEJSPjxCPlNlbnQ6PC9CPiBXZWRuZXNk YXksIEp1bHkgDQogICAgMDQsIDIwMDEgODoxNCBQTTxCUj48Qj5Ubzo8L0I+IA0KICAgIG1vYmls ZS1pcEBzdW5yb29mLmVuZy5zdW4uY29tPEJSPjxCPlN1YmplY3Q6PC9CPiBbbW9iaWxlLWlwXSBN b2JpbGUgSVB2NCANCiAgICBBdXRoZW50aWNhdGlvbiBJbnRlcm50IERyYWZ0IHJldmlzaW9uIDAu MTxCUj48QlI+PC9ESVY+PC9GT05UPg0KICAgIDxESVY+PEZPTlQgc2l6ZT0yPg0KICAgIDxESVY+ PEZPTlQgc2l6ZT0yPkhpIEFsbCw8QlI+PEJSPldlIHJlY2VudGx5IHN1Ym1pdHRlZCZuYnNwO3Ro ZSANCiAgICByZXZpc2lvbiZuYnNwO29mIEludGVybmV0IGRyYWZ0Jm5ic3A7ZHJhZnQgb24gIk1J UHY0IEF1dGhlbnRpY2F0aW9uIFNoYXJlZCANCiAgICBTZWNyZXQgR2VuZXJhdGlvbi48L0ZPTlQ+ PC9ESVY+DQogICAgPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KICAgIDxE SVY+PEZPTlQgc2l6ZT0yPmRyYWZ0LXNvbmctbW9iaWxlaXAtbWlwdjQtYXV0aC1zZWNnZW5lcmF0 aW9uLTAxLnR4dCZuYnNwOyANCiAgICA8QlI+PC9ESVY+PEZPTlQgc2l6ZT0zPjwvRk9OVD48L0ZP TlQ+DQogICAgPERJVj48Rk9OVCBzaXplPTI+PEZPTlQgc2l6ZT0zPjxGT05UIHNpemU9Mj48L0ZP TlQ+PEZPTlQgc2l6ZT0yPjwvRk9OVD48Rk9OVCANCiAgICBzaXplPTI+PC9GT05UPjxCUj48L0ZP TlQ+UmVnYXJkcyw8L0ZPTlQ+PC9ESVY+DQogICAgPERJVj48Rk9OVCBzaXplPTI+SkggDQpTT05H PEJSPjwvRElWPjwvRk9OVD48L0ZPTlQ+PC9ESVY+PC9CTE9DS1FVT1RFPjwvQkxPQ0tRVU9URT48 L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_002F_01C106C5.D62DBC10-- From owner-mobile-ip@sunroof.eng.sun.com Sun Jul 8 19:04:38 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA16495 for ; Sun, 8 Jul 2001 19:04:37 -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 RAA05333; Sun, 8 Jul 2001 17:03: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 QAA10754; Sun, 8 Jul 2001 16:03:50 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f68N2tdP003931 for ; Sun, 8 Jul 2001 16:02:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f68N2tU9003930 for mobile-ip-dist; Sun, 8 Jul 2001 16:02: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.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f68N2pdP003923 for ; Sun, 8 Jul 2001 16:02:51 -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 QAA17064 for ; Sun, 8 Jul 2001 16:03:00 -0700 (PDT) Received: from netmail2.alcatel.com (netmail2.alcatel.com [128.251.168.51]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA13164 for ; Sun, 8 Jul 2001 17:04:06 -0600 (MDT) Received: from auds952.usa.alcatel.com (auds952.usa.alcatel.com [143.209.238.7]) by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id SAA13262 for ; Sun, 8 Jul 2001 18:02:59 -0500 (CDT) Received: from usa.alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f68N2wF27494 for ; Sun, 8 Jul 2001 18:02:59 -0500 (CDT) Message-ID: <3B48D7D7.55FD3ACB@usa.alcatel.com> Date: Sun, 08 Jul 2001 17:59:51 -0400 From: Behcet Sarikaya X-Mailer: Mozilla 4.76 [en]C-CCK-MCD BDPjm-Sony3 (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Ext. for FMIPv6 - comments References: <8C92E23A3E87FB479988285F9E22BE46054621@ftmail> Content-Type: multipart/alternative; boundary="------------D2A09D95161243DC441A43A0" 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: --------------D2A09D95161243DC441A43A0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello George, Here is an excerpt from draft-manyfolks-ipv6-cellular-host-00.txt: Within the current 3GPP architecture, a cellular host will always keep the connection to the same GGSN (default router) for a context. Movement between default routers is not permitted. The only scenario where a MN would change default routers is in the case of a handover between two different access technologies. In this case the MN will be simultaneously connected to both routers which would eliminate the need for anticipation through the current router. Hence the Fast Handoffs draft will not be required within the current 3GPP architecture. What do you think? -- Behcet --------------D2A09D95161243DC441A43A0 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hello George,
  Here is an excerpt from
draft-manyfolks-ipv6-cellular-host-00.txt:
Within the current 3GPP architecture, a cellular host will always
   keep the connection to the same GGSN (default router) for a context.
   Movement between default routers is not permitted. The only scenario
   where a MN would change default routers is in the case of a handover
   between two different access technologies. In this case the MN will
   be simultaneously connected to both routers which would eliminate
   the need for anticipation through the current router. Hence the Fast
   Handoffs draft will not be required within the current 3GPP
   architecture.

What do you think?
 

--
Behcet --------------D2A09D95161243DC441A43A0-- From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 9 02:49:48 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA04899 for ; Mon, 9 Jul 2001 02:49:47 -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 XAA26346; Sun, 8 Jul 2001 23:50:08 -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 XAA03634; Sun, 8 Jul 2001 23:50:03 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f696n6dP004109 for ; Sun, 8 Jul 2001 23:49:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f696n6wf004108 for mobile-ip-dist; Sun, 8 Jul 2001 23:49: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.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f696n3dP004101 for ; Sun, 8 Jul 2001 23:49:03 -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 XAA17938 for ; Sun, 8 Jul 2001 23:49:12 -0700 (PDT) From: john.loughney@nokia.com Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA23070 for ; Mon, 9 Jul 2001 00:50:19 -0600 (MDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f696naI13043 for ; Mon, 9 Jul 2001 09:49:36 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Mon, 9 Jul 2001 09:49:08 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MS46LKX>; Mon, 9 Jul 2001 09:49:08 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF094009@esebe004.NOE.Nokia.com> To: james.kempf@sun.com, mobile-ip@sunroof.eng.sun.com, seamoby@cdma-2000.org Subject: [mobile-ip] Re: L2 API (WAS: Ext. for FMIPv6 - comments) Date: Mon, 9 Jul 2001 09:48:56 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) 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: Hi James, > There is a draft in preparation with people from both Seamoby > and MIP on the author list. These are people with whom > I have talked and who have expressed interest in working on such a > draft over the last year. The draft has a section on L2 triggers > that came out of the MIP fast handoff work, then a section > that describes connections with Seamoby context transfer. > I expect we will have it complete by next Fri.'s 00 deadline. > > We have already talked to the MIP WG chairs about getting > time on the agenda to discuss the draft, what I'd like > to suggest is that we do the same for Seamoby. That > will give both WGs the opportunity to review and comment > on the draft. I will talk with Pat about that when he gets > back from vacation. I think that is a good idea & I'm glad to see that authors from both MIP & SeaMoby are on it. That's enough for me. I look forward to the draft. br, John From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 9 02:59:18 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA05525 for ; Mon, 9 Jul 2001 02:59:18 -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 AAA14247; Mon, 9 Jul 2001 00:59: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 XAA04276; Sun, 8 Jul 2001 23:59:43 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f696wxdP004173 for ; Sun, 8 Jul 2001 23:58:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f696wx7u004172 for mobile-ip-dist; Sun, 8 Jul 2001 23:58: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.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f696wtdP004165 for ; Sun, 8 Jul 2001 23:58:55 -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 XAA04199 for ; Sun, 8 Jul 2001 23:59:05 -0700 (PDT) Received: from ms.samsung.com ([211.45.29.136]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA13999 for ; Mon, 9 Jul 2001 00:59:02 -0600 (MDT) Received: from CYCHONG ([203.241.48.20]) by ms.samsung.com (Netscape Messaging Server 4.15) with SMTP id GG71W302.K0E for ; Mon, 9 Jul 2001 15:55:16 +0900 Message-ID: <001001c10844$c16d03f0$10e0d5a5@cdma2000system.samsung.co.kr> From: "Chae-yong Chong" To: References: <43E8CCEAF148D211854C00805FA72E580701988E@rhqnneex1.corp.bam.com> Subject: Re: [mobile-ip] Mobile IPv4 Authentication Internt Draft revision 0.1 Date: Mon, 9 Jul 2001 15:59:53 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" 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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by sunroof.eng.sun.com id f696wtdP004166 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 Hi Carroll. Plaes read my comments bellow ----- Original Message ----- From: "Carroll, Christopher X" To: Cc: "Flynn, Gerry J" Sent: Saturday, July 07, 2001 3:46 AM Subject: RE: [mobile-ip] Mobile IPv4 Authentication Internt Draft revision 0.1 > Hi Junhyuk, > Some initial comments on your revision: > The current proposal is so different from your original proposal that it > probably should not be considered a revision. The only common theme between > your current and initial proposal appears to be the concept of using the FAC > (randomness generated by a visited network) to derive the MN-HA key (and > MN-FA key). > I must reiterate my significant concern that your proposal allows any > visited network to control the derivation of a home network security > association (SA) - the MN-HA key. Why open the door for possible > manipulation of the MN-HA key by a fraudulent/Rogue FA? > It appears that your primary concern with the Perkin/Calhoun proposal is the > possible inefficiency of using explicit messages to generate a unique MN-HA > key for each dynamically assigned HA. Unfortunately, there is always a > trade-off between security and efficiency. Apparently you believe that > generation of the MN-HA key from the FAC is more efficient, however you must > concede that it is less secure than allowing the home network to control the > MN-HA key generation. Okay, we consider using the other factor in calculating MN-HA share key not FAC itself. If we use MN-AAA authenticator instead of FAC that cause the same problem which you mentioned? FAC is definitely under the control of FA, but MN-AAA authenticator is not directly. How about this scheme? > Are you sure that MN-HA key derivation based on the FAC is more efficient? > In your proposal, the MN-HA key is generated every time the MN initially > registers in a new system at least. Thus, the MN-HA key must be > requested/passed to the HA from the AAAh for each new "MIP session". In the > Perkins/Calhoun proposal, the MN-HA key may be Update once/month, once/year, > or even once while still providing adequate security (based on at least a > 90-bit key). How often do you envision that dynamic HA assignment will > occur? The Perkins/Calhoun proposal requires MN-HA key update only when an > new HA is assigned to the MN. If the MN-HA key is updated just once every month or year, what is difference of static MN-HA key. Its long using the MN-HA key might cause entropy problem. > Although not described in the Perkins/Calhoun proposal, it appears that the > MN could store multiple MN-HA keys (for multiple HAs) simultaneously. Thus, > when the MN is dynamically re-assigned to an HA in which an MN-HA key was > previously derived, the MN need not perform a new key update. The MN might > use a FIFO queue to hold up to 10 MN-HA keys (for 10 different HAs). Each HA > could retain the MN-HA key associated with a particular MN (based on the > MN's NAI and an internal lifetimer). If the MN is assigned an HA for which > it has no MN-HA key, it initiates a MN-HA key Update, puts the new key in > the queue, and bumps out the oldest assigned MN-HA key (Note: the queue > could likely be much larger! - holding dozens of MN-HA keys for dozens of > HAs). If it is feasible, how about using just dozens of static MN-HA share key for every HA. Do you think one home network got the thousand of HA? I don't think so. Just use 10 static MN-HA shared secret and each shared secret is assigned to the last digit of HA's IP address. How about use this schem? Maybe this scheme is lack of key update. But if you consider the same MN-HA key for one month or even one year, what is difference between static and monthly or yearly update > The generic Perkins/Calhoun approach or my MN-HA key queuing approach > appears equally scalable, but more efficient than automatically generating a > new MN-HA key during each new MIP session. > The entropy issue in your proposal is not significant where the secret key > and randomness used to generate a subordinate key is large enough. The > Perkins/Calhoun proposal defines the "Key Material" to be at least 64-bits > which is large enough. A larger random variable may be more secure, but > 64-bits is more than enough to ensure MN-HA key freshness. The purpose of > using randomness for key agreement is to ensure that derived key is unique. > The security of the key agreement algorithm is based on the properties of > the algorithm (i.e. one-wayness) and the size (security strength) of the > root secret key. > Finally - I arrive at the security issues associated with using the FAC to > generate the MN-HA key. There is always a danger in using a > procedure/protocol that was originally intended for one purpose for another. > If you use the FAC only to generate the MN-FA key or some other local > key(s), I have no objection to such an approach because those keys provide > security for the visited network only. Both 3GPP and 3GPP2 use locally > generated keys for local session privacy and authentication (IK and CK for > 3GPP is generated in the UIM). The home network doesn't care (to a certain > degree) whether the roamer/visitor uses proper security procedures, because > the home network always gets payed for the access (fraudulent or not based > on the Roaming Agreement between the home and visited service provider). > However, the home network provider is very concerned about giving away > possible authentication information to visited network which could cost the > home network. I think that roaming agreement might consider some sort of security issues. If you consider, 3GPP or 3GPP2 it means commercial service. Its roaming agreement is critical to their business. I think FA's random FAC generationg capability is must stated in the roaming agreement. In this case we would not worry about the malicious FA. > In your proposal, the MN-HA key == HMAC-MD5 (MN-AAA key, FAC, MN NAI, MN-AAA > key). The only variable is the FAC which is control by the FA! You appear to > rely heavily on the fact that the MN will use a timestamp in the RRQ to > eventually protect the MN-HA key Update. Where does the MN get system time > from? In cdma2000, the MN may us the broadcast network time (with or without > NTP) which implies that a Rogue FA, impersonating the network, can also > manipulate the MNs own timestamp and trick the MN into pre-computing RRQs > for the future. If the Rogue FA can predict the FAC used by a legitimate FA > (i.e. the legitimate FA updates FAC infrequently), then the rogue FA can act > as a clone MN and obtain access to the target network in the future. This > attack won't work against the Perkins/Calhoun proposal unless the Rogue FA > can predict the randomness used in the "Key Material" which is impractical > (however the MN-HA key would have to be updated to prevent it). The attack > is relatively sophisticated, but perhaps government X wants to monitor > packets sent to a citizen (or official) of government Y. Government X would > only need to trick the MN into precomputing RRQs (it wouldn't care about > cloning) in order to re-route packet traffic to the its own FA in the > future. Again We will revise our draft to use some portion of MN-AAA authenticator not the FAC itself. > I admit that the above attack requires the MN to generate timestamps based > on the 3GPP2(cdma2000) network system time and/or NTP(spoofed by a > fraudulent FA). Also in the cloning scenario, the fraudulent FA would have > to predict the legitimate FA's FAC. However, my concern is that these are > only an initial potential attacks based on analyzing your proposal for less > than one day. I think you confuse the MN and TE time. Mobile Node concerns only about the MN's time. It's time will be based only MN's local timer such as PC bios. There is no requirement for MN to adjust its time on the base of time server. Morever in my understand, TE just adjust its time via the air signalling message. It can not spoof by the malicious FA. > It is not good security practice to allow a third party to manipulate the SA > between two entities unless that third party can be completely trusted. > In Appendix B you define MN-FA key generation - the current proposal > specifies that the MN-FA == HMAC-MD5 (MN-HA key, FA IP address, FAC, NAI). > Because the MN-FA is now dependent on the MN-HA key, it appears that a new > MN-HA key must be generated for each MIP session (as you call it) in order > to update the MN-FA key. Doesn't this defeat the purpose of the MN-HA > Optional Lifetime feature? Can the FAC used to generate the MN-FA and MN-HA > key be different ? Again, Pat/Calloun's method also based on the MN-AAA authentication that could be hacked by a mallicious FA. If some malicous FA could crack the MN-HA shared key with a specific FAC, it also do for MN-AAA shared secret. If MN-AAA authenticaiton is cracked, it's over. That means why you always comment about the MN-HA shared key generation not the hacking MN-AAA shared secret. > Let me know what you think. > regards, > chris > > Regards, chae-yong > ********************************************************************** > Christopher Carroll Office: 508-330-3401 > Senior Member Technical Staff fax: 508-330-3403 > Verizon Wireless cellular: 781-424-4131 > Chair TR-45 Adhoc Authentication Group > email: christopher.carroll@verizonwireless.com > ********************************************************************** > From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 9 03:05:09 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA05886 for ; Mon, 9 Jul 2001 03:05:08 -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 AAA01747; Mon, 9 Jul 2001 00:05: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 AAA04825; Mon, 9 Jul 2001 00:05:38 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f6974rdP004234 for ; Mon, 9 Jul 2001 00:04:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f6974q3M004233 for mobile-ip-dist; Mon, 9 Jul 2001 00:04: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.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f6974ndP004226 for ; Mon, 9 Jul 2001 00:04:49 -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 AAA04772 for ; Mon, 9 Jul 2001 00:04:59 -0700 (PDT) From: john.loughney@nokia.com Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA28123 for ; Mon, 9 Jul 2001 01:06:04 -0600 (MDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f6975NI21767 for ; Mon, 9 Jul 2001 10:05:23 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Mon, 9 Jul 2001 10:04:56 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MS46MCS>; Mon, 9 Jul 2001 10:04:56 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF09BAEB@esebe004.NOE.Nokia.com> To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Ext. for FMIPv6 - comments Date: Mon, 9 Jul 2001 10:04:43 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) 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: Hi Behcet, Here is an excerpt from draft-manyfolks-ipv6-cellular-host-00.txt: Within the current 3GPP architecture, a cellular host will always keep the connection to the same GGSN (default router) for a context. Movement between default routers is not permitted. The only scenario where a MN would change default routers is in the case of a handover between two different access technologies. In this case the MN will be simultaneously connected to both routers which would eliminate the need for anticipation through the current router. Hence the Fast Handoffs draft will not be required within the current 3GPP architecture. [ ] While I'm not George, and I'm not entirely sure what email you are responding to (clipping part of the previous email is always helpful to relate context to), but as an author of the "draft-manyfolks-ipv6-cellular-host-00.txt" draft let me say a word or two. Since 3GPP started from a non-Internet point (3GPP's archictecture is more-or-less an evolution of the circuit-switch GSM architecture), mobility for voice & data are handled by layer-2 mobility. This is the current architecture. As it evolves, I don't think we can completely discount the adoption of MIP or FMIP. Additionally, 3GPP does not specify interworking between different technologies such as WCDMA, WLAN, Bluetooth, etc. I'm sure some clever folks could find a way to make handovers between these technologies. Our document is not to discount MIP, but to be realistic for those folks looking at making devices. I think both FMIPv6 and the BETH extensions are very important documents, and I think they will enable folks to construct devices that work well with MIP. best regards, John From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 9 03:26:03 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA07114 for ; Mon, 9 Jul 2001 03:26: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 BAA26493; Mon, 9 Jul 2001 01:26:26 -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 AAA06116; Mon, 9 Jul 2001 00:26:24 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f697PSdP004295 for ; Mon, 9 Jul 2001 00:25:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f697PScj004294 for mobile-ip-dist; Mon, 9 Jul 2001 00:25: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f697POdP004287 for ; Mon, 9 Jul 2001 00:25:25 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA13439 for ; Mon, 9 Jul 2001 00:25:34 -0700 (PDT) Received: from stsl.siemens.com.tw (stsl.siemens.com.tw [192.72.45.189]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA24188 for ; Mon, 9 Jul 2001 00:25:29 -0700 (PDT) Received: from stslex.siemens.com.tw (stslex [192.72.45.13]) by stsl.siemens.com.tw (8.11.4/8.11.4) with ESMTP id f697cRX03794 for ; Mon, 9 Jul 2001 15:38:28 +0800 (CST) Received: by stslex.siemens.com.tw with Internet Mail Service (5.5.2650.21) id <3KMSSYZP>; Mon, 9 Jul 2001 15:23:44 +0800 Message-ID: <92C0C0AC8AE8D411864300105A835CBB50A64D@stslex.siemens.com.tw> From: Ra Chen To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] MIPv6 "granted lifetime" problem Date: Mon, 9 Jul 2001 15:23:40 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10848.13E951D0" 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_01C10848.13E951D0 Content-Type: text/plain; charset="iso-8859-1" Hi all: In our attempt to implement Mobile IPv6, we encounter the following problem. In draft-ietf-mobileip-ipv6-14.txt, Sec. 10.13, it's described that the reamining lifetime should be max((L_remain - (L_update - L_ack)), 0) Here is an implementation problem. To do the calculation, L_ack and L_update must be a pair. That is, the BU of L_update and the BA of L_ack must have identical sequence number. However, according to Sec. 4.6, for multiple Binding Updates sent to the same destination address, the Binding Update List contains only the most recent Binding Update (i.e., with the greatest Sequence Number value) sent to that destination. Now if the BA for the initial BU is received after a BU retransmission, the mobile node has no information about L_update, which has been overwritten by the BU retransmission, and doing the calculation correctly is impossible. To fully comply with the draft, the mobile node has to record L_update for ALL its un-Acked BU, in order to use the matching L_update once a BA is received. This seems against the spirit of Sec.4.6. Best Regards ================================== Ra Chen Siemens Telecommunication Systems Ltd. R&D Engineer E-mail: ra@stsl.siemens.com.tw Tel: 886-2-2518-6539 Fax: 886-2-2505-3866 ================================== ------_=_NextPart_001_01C10848.13E951D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIPv6 "granted lifetime" problem

Hi all:

In our attempt to implement Mobile = IPv6,
we encounter the following = problem.

In draft-ietf-mobileip-ipv6-14.txt, = Sec. 10.13,
it's described that the reamining = lifetime should be
         max((L_remain - = (L_update - L_ack)), 0)

Here is an implementation = problem.
To do the calculation, L_ack and = L_update must be a pair.
That is, the BU of L_update and the = BA of L_ack
must have identical sequence = number.

However, according to Sec. 4.6, =
         for multiple = Binding Updates sent to the same destination
         address, the = Binding Update List contains only the most recent
         Binding Update = (i.e., with the greatest Sequence Number value)
         sent to that = destination. 
Now if the BA for the initial BU is = received after a BU retransmission,
the mobile node has no information = about L_update,
which has been overwritten by the BU = retransmission,
and doing the calculation correctly = is impossible.

To fully comply with the = draft,
the mobile node has to record = L_update for ALL its un-Acked BU,
in order to use the matching = L_update once a BA is received.
This seems against the spirit of = Sec.4.6.

Best Regards

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Ra Chen
Siemens Telecommunication Systems = Ltd.
R&D Engineer
E-mail: = ra@stsl.siemens.com.tw
Tel: 886-2-2518-6539
Fax: 886-2-2505-3866
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

------_=_NextPart_001_01C10848.13E951D0-- From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 9 04:29:00 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA07626 for ; Mon, 9 Jul 2001 04:28:59 -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 CAA23174; Mon, 9 Jul 2001 02:29: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 BAA16924; Mon, 9 Jul 2001 01:29:29 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f698SYdP004432 for ; Mon, 9 Jul 2001 01:28:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f698SYYQ004431 for mobile-ip-dist; Mon, 9 Jul 2001 01:28: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.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f698SVdP004424 for ; Mon, 9 Jul 2001 01:28: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 BAA16880 for ; Mon, 9 Jul 2001 01:28:41 -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 CAA24190 for ; Mon, 9 Jul 2001 02:29:46 -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 RAA04352; Mon, 9 Jul 2001 17:28:01 +0900 (JST) Received: from keiichi00.osaka.iij.ad.jp (keiichi00.osaka.iij.ad.jp [192.168.65.65]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id RAA21939; Mon, 9 Jul 2001 17:28:00 +0900 (JST) Date: Mon, 09 Jul 2001 17:28:13 +0900 Message-ID: <877kxi4ici.wl@keiichi00.osaka.iij.ad.jp> From: Keiichi SHIMA To: mobile-ip@sunroof.eng.sun.com Cc: Ra Chen Subject: Re: [mobile-ip] MIPv6 "granted lifetime" problem In-Reply-To: <92C0C0AC8AE8D411864300105A835CBB50A64D@stslex.siemens.com.tw> References: <92C0C0AC8AE8D411864300105A835CBB50A64D@stslex.siemens.com.tw> User-Agent: Wanderlust/2.4.1 (Stand By Me) SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 MULE XEmacs/21.1 (patch 14) (Cuyahoga Valley) (i386--freebsd) Organization: Internet Initiative Japan Inc. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") 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, Ra Chen wrote: > > However, according to Sec. 4.6, > for multiple Binding Updates sent to the same destination > address, the Binding Update List contains only the most recent > Binding Update (i.e., with the greatest Sequence Number value) > sent to that destination. > Now if the BA for the initial BU is received after a BU retransmission, > the mobile node has no information about L_update, > which has been overwritten by the BU retransmission, > and doing the calculation correctly is impossible. I have met the same problem. The problem is more serious when de-registrating I think. 0. MN sends BU with seqno n. 1. MN resends BU with seq n+1 bacause BA with seq n did not come in a BINDACK_TIMEOUT time. 2. HA receives BU with seq n. de-register, send back an BA with seqno n to MN. 3. MN receives BA with seq n but MN silently discards it because the seqno is not the same to the BU's seqno MN sent last time. 4. HA receives BU with seqno n+1. but discards it and send BA to MN with errcode NOT_A_HOMEAGENT If we don't increment seqno when retransmitting BU, are there any vulnerabilities? If seqno remains same until matching BA received, those problem will not occur. and it is easier than holding all sending BUs in a BU list. --- Keiichi SHIMA Internet Initiative Japan Inc. From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 9 05:14:48 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA08011 for ; Mon, 9 Jul 2001 05:14:48 -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 CAA07077; Mon, 9 Jul 2001 02:15:19 -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 CAA26346; Mon, 9 Jul 2001 02:15:07 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f699DcdP004552 for ; Mon, 9 Jul 2001 02:13:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f699DbOX004551 for mobile-ip-dist; Mon, 9 Jul 2001 02:13: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.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f699DYdP004544 for ; Mon, 9 Jul 2001 02:13:34 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA15248 for ; Mon, 9 Jul 2001 02:13:45 -0700 (PDT) Received: from stsl.siemens.com.tw (stsl.siemens.com.tw [192.72.45.189]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA21852 for ; Mon, 9 Jul 2001 02:13:43 -0700 (PDT) Received: from stslex.siemens.com.tw (stslex [192.72.45.13]) by stsl.siemens.com.tw (8.11.4/8.11.4) with ESMTP id f699QfX05945 for ; Mon, 9 Jul 2001 17:26:41 +0800 (CST) Received: by stslex.siemens.com.tw with Internet Mail Service (5.5.2650.21) id <3KMSSZ31>; Mon, 9 Jul 2001 17:11:58 +0800 Message-ID: <92C0C0AC8AE8D411864300105A835CBB5015D5@stslex.siemens.com.tw> From: Moter Du To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] MIPv6 "granted lifetime" problem Date: Mon, 9 Jul 2001 17:11:52 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10857.31470740" 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_01C10857.31470740 Content-Type: text/plain; charset="BIG5" Sorry but I have to point out your problem is not the same as Ra's. With the latest draft v.14 I think your problem regarding Sequence Number has been solved. More comments are inserted below... Ra's question is basically an implementation issue of granted lifetime calculation at the receipt of BA responding to a **retransmiting** BU. To meet the requirement of Sec. 10.13 we have to store every BU lifetime (initial or retransmiting) sent to HA, in order to get accurately granted lifetime. Seems not efficient for a MN implementation... Regards, Moter > -----Original Message----- > From: Keiichi SHIMA [mailto:keiichi@iij.ad.jp] > Sent: Monday, July 09, 2001 4:28 PM > To: mobile-ip@sunroof.eng.sun.com > Cc: Ra Chen > Subject: Re: [mobile-ip] MIPv6 "granted lifetime" problem > > > Hi, > > Ra Chen wrote: > > > > However, according to Sec. 4.6, > > for multiple Binding Updates sent to the same destination > > address, the Binding Update List contains only the > most recent > > Binding Update (i.e., with the greatest Sequence > Number value) > > sent to that destination. > > Now if the BA for the initial BU is received after a BU > retransmission, > > the mobile node has no information about L_update, > > which has been overwritten by the BU retransmission, > > and doing the calculation correctly is impossible. > > I have met the same problem. The problem is more serious when > de-registrating I think. > > 0. MN sends BU with seqno n. > 1. MN resends BU with seq n+1 bacause BA with seq n did not come > in a BINDACK_TIMEOUT time. > 2. HA receives BU with seq n. de-register, send back an BA with > seqno n to MN. > 3. MN receives BA with seq n but MN silently discards it because > the seqno is not the same to the BU's seqno MN sent last time. No. MN should not silently discard it. It's correct to MN because the sequence number matches in ack window (size: modulo 2^16 in v.13, module 2^8 in v.14)... > 4. HA receives BU with seqno n+1. but discards it and send BA to MN > with errcode NOT_A_HOMEAGENT > > If we don't increment seqno when retransmitting BU, are there any > vulnerabilities? If seqno remains same until matching BA received, > those problem will not occur. and it is easier than holding all > sending BUs in a BU list. > > --- > Keiichi SHIMA > Internet Initiative Japan Inc. > ------_=_NextPart_001_01C10857.31470740 Content-Type: text/html; charset="BIG5" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] MIPv6 "granted lifetime" = problem

Sorry but I have to point out your problem is not the = same as Ra's.  With the latest draft v.14 I think your problem = regarding Sequence Number has been solved.  More comments are = inserted below...

Ra's question is basically an implementation issue of = granted lifetime calculation at the receipt of BA responding to a = **retransmiting** BU.  To meet the requirement of Sec. 10.13 we = have to store every BU lifetime (initial or retransmiting) sent to HA, = in order to get accurately granted lifetime.  Seems not efficient = for a MN implementation...

Regards,
Moter

> -----Original Message-----
> From: Keiichi SHIMA [mailto:keiichi@iij.ad.jp]
> Sent: Monday, July 09, 2001 4:28 PM
> To: mobile-ip@sunroof.eng.sun.com
> Cc: Ra Chen
> Subject: Re: [mobile-ip] MIPv6 "granted = lifetime" problem
>
>
> Hi,
>
> Ra Chen wrote:
> >
> > However, according to Sec. 4.6,
> = >          for multiple = Binding Updates sent to the same destination
> = >          address, the = Binding Update List contains only the
> most recent
> = >          Binding = Update (i.e., with the greatest Sequence
> Number value)
> = >          sent to that = destination.
> > Now if the BA for the initial BU is = received after a BU
> retransmission,
> > the mobile node has no information about = L_update,
> > which has been overwritten by the BU = retransmission,
> > and doing the calculation correctly is = impossible.
>
> I have met the same problem. The problem is = more serious when
> de-registrating I think.
>
> 0. MN sends BU with seqno n.
> 1. MN resends BU with seq n+1 bacause BA with = seq n did not come
>    in a BINDACK_TIMEOUT = time.
> 2. HA receives BU with seq n. de-register, send = back an BA with
>    seqno n to MN.
> 3. MN receives BA with seq n but MN silently = discards it because
>    the seqno is not the same to = the BU's seqno MN sent last time.

No.  MN should not silently discard it.  = It's correct to MN because the sequence number matches in ack window = (size: modulo 2^16 in v.13, module 2^8 in v.14)...

> 4. HA receives BU with seqno n+1. but discards = it and send BA to MN
>    with errcode = NOT_A_HOMEAGENT
>
> If we don't increment seqno when retransmitting = BU, are there any
> vulnerabilities? If seqno remains same until = matching BA received,
> those problem will not occur. and it is easier = than holding all
> sending BUs in a BU list.
>
> ---
> Keiichi SHIMA <keiichi@iij.ad.jp>
> Internet Initiative Japan Inc.
>

------_=_NextPart_001_01C10857.31470740-- From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 9 06:00:46 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA08380 for ; Mon, 9 Jul 2001 06:00: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 EAA03656; Mon, 9 Jul 2001 04:01:16 -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 DAA29348; Mon, 9 Jul 2001 03:01:05 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f699xjdP004654 for ; Mon, 9 Jul 2001 02:59:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f699xjlJ004653 for mobile-ip-dist; Mon, 9 Jul 2001 02:59: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f699xfdP004646 for ; Mon, 9 Jul 2001 02:59:41 -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 CAA29219 for ; Mon, 9 Jul 2001 02:59:50 -0700 (PDT) Received: from RRMAIL01.RADIOROUTER_NT ([63.103.94.23]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA26077 for ; Mon, 9 Jul 2001 04:00:57 -0600 (MDT) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id <317T3S8H>; Mon, 9 Jul 2001 05:59:47 -0400 Message-ID: <8C92E23A3E87FB479988285F9E22BE4605463A@ftmail> From: George Tsirtsis To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Ext. for FMIPv6 - comments Date: Mon, 9 Jul 2001 05:59: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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Bechet/John, I am not sure I can read Bechet's sentiment... I certainly agree that 3GPP (today in all visible releases) does not have much use for fast MIP handoffs... I am, however, aware that 3G bodies (not only 3GPP) are looking at MIP and would like to get more IP in their architecture, although I am not sure how far they can really go and what good will that do...but that is another story...My point with the manyfolks-ipv6-cellular-host draft was that it should state that these are guidelines to 3G host implementers...rather than general internet hosts (ot even mobile hosts) Now I am not sure if this has anything to do with the BETH extensions, which to my understanding attempt to be applicable to IP networks in general...not 3G in particular...thank god there is life beyond 3G! George -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: Monday, July 09, 2001 8:05 AM To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Ext. for FMIPv6 - comments Hi Behcet, Here is an excerpt from draft-manyfolks-ipv6-cellular-host-00.txt: Within the current 3GPP architecture, a cellular host will always keep the connection to the same GGSN (default router) for a context. Movement between default routers is not permitted. The only scenario where a MN would change default routers is in the case of a handover between two different access technologies. In this case the MN will be simultaneously connected to both routers which would eliminate the need for anticipation through the current router. Hence the Fast Handoffs draft will not be required within the current 3GPP architecture. [ ] While I'm not George, and I'm not entirely sure what email you are responding to (clipping part of the previous email is always helpful to relate context to), but as an author of the "draft-manyfolks-ipv6-cellular-host-00.txt" draft let me say a word or two. Since 3GPP started from a non-Internet point (3GPP's archictecture is more-or-less an evolution of the circuit-switch GSM architecture), mobility for voice & data are handled by layer-2 mobility. This is the current architecture. As it evolves, I don't think we can completely discount the adoption of MIP or FMIP. Additionally, 3GPP does not specify interworking between different technologies such as WCDMA, WLAN, Bluetooth, etc. I'm sure some clever folks could find a way to make handovers between these technologies. Our document is not to discount MIP, but to be realistic for those folks looking at making devices. I think both FMIPv6 and the BETH extensions are very important documents, and I think they will enable folks to construct devices that work well with MIP. best regards, John From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 9 12:45:30 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA21142 for ; Mon, 9 Jul 2001 12:45:30 -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 JAA25655; Mon, 9 Jul 2001 09:45: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 JAA26184; Mon, 9 Jul 2001 09:32:43 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f69GVidP005092 for ; Mon, 9 Jul 2001 09:31:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f69GVi8W005091 for mobile-ip-dist; Mon, 9 Jul 2001 09:31: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 heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f69GVedP005084 for ; Mon, 9 Jul 2001 09:31:40 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id JAA16404 for ; Mon, 9 Jul 2001 09:31:51 -0700 (PDT) Message-Id: <200107091631.JAA16404@heliopolis.eng.sun.com> Date: Mon, 9 Jul 2001 09:31:50 -0700 (PDT) From: James Kempf Subject: RE: [mobile-ip] Ext. for FMIPv6 - comments To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: tLiKws4PoLkjcNI/lRVFlQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 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: George/Bechet/John, With regard to BETH, actually, it would be possible for a MN to do exactly what the manyfolks-ipv6-cellular-host drafts says about keeping the same router as it moved until the MN shut off, but that is not the intent of the BETH draft. The intent is to provide a zero L3 latency alternative to the techniques outlined in the current FMIPv6 draft as a complementary solution for cases where wireless bandwidth is low. The BETH draft states that the MN should use FMIPv6 or the original Johnson and Perkins algorithm to obtain a new CoA as soon as its traffic profile allows it. This would work for either current 3G devices (which don't have particularly high bandwidth as compared with, say, WLAN) or for new, low bandwidth devices. With regard to GPRS in general, while there has been a considerable amount of controversy in the MIP group about GPRS and there is a certain amount of antagonism on both sides over the issue, I certainly welcome the manyfolks-ipv6-cellular-host draft *if* it provides guidance about how to get MIP available in UTRAN systems for inter-domain handover (I have not had an opportunity to read the draft yet). The details of this have not been well worked out, to my knowledge. I have been told that there is an alternative inter-domain handover technology called GPRX that involves tunnelling GPRS over the Internet. This is supposedly used by some GSM operators, and some are pushing to extend it to UTRAN. I sent out email on this awhile back. IMHO, having this technology spread to UTRAN is a really bad idea, because it will make handover between domains that choose to use MIP and those that use GPRS impossible, regardless of the radio technology. Over the longer term, I think it would make sense for IETF to look at ways to get MIP and GPRS to interoperate better, just as was done in the late 80's and early 90's with NETBIOS and IP. If 3G takes off (a big "if" at this point), there will be alot of GPRS nodes out there, so it would be in the interests of interoperability and the Internet to make this happen. jak >From: George Tsirtsis >To: "'mobile-ip@sunroof.eng.sun.com'" >Subject: RE: [mobile-ip] Ext. for FMIPv6 - comments >Date: Mon, 9 Jul 2001 05:59:43 -0400 > >Hi Bechet/John, > >I am not sure I can read Bechet's sentiment... > >I certainly agree that 3GPP (today in all visible releases) does not have >much use for fast MIP handoffs... I am, however, aware that 3G bodies (not >only 3GPP) are looking at MIP and would like to get more IP in their >architecture, although I am not sure how far they can really go and what >good will that do...but that is another story...My point with the >manyfolks-ipv6-cellular-host draft was that it should state that these are >guidelines to 3G host implementers...rather than general internet hosts (ot >even mobile hosts) > >Now I am not sure if this has anything to do with the BETH extensions, which >to my understanding attempt to be applicable to IP networks in general...not >3G in particular...thank god there is life beyond 3G! > >George > >-----Original Message----- >From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] >Sent: Monday, July 09, 2001 8:05 AM >To: mobile-ip@sunroof.eng.sun.com >Subject: RE: [mobile-ip] Ext. for FMIPv6 - comments > > >Hi Behcet, > > Here is an excerpt from >draft-manyfolks-ipv6-cellular-host-00.txt: >Within the current 3GPP architecture, a cellular host will always > keep the connection to the same GGSN (default router) for a context. > Movement between default routers is not permitted. The only scenario > where a MN would change default routers is in the case of a handover > between two different access technologies. In this case the MN will > be simultaneously connected to both routers which would eliminate > the need for anticipation through the current router. Hence the Fast > Handoffs draft will not be required within the current 3GPP > architecture. > >[ ] While I'm not George, and I'm not entirely sure what email you >are responding to (clipping part of the previous email is always helpful to >relate context to), but as an author of the >"draft-manyfolks-ipv6-cellular-host-00.txt" >draft let me say a word or two. > >Since 3GPP started from a non-Internet point (3GPP's archictecture >is more-or-less an evolution of the circuit-switch GSM architecture), >mobility for voice & data are handled by layer-2 mobility. This is the >current architecture. As it evolves, I don't think we can completely >discount the adoption of MIP or FMIP. Additionally, 3GPP does not >specify interworking between different technologies such as WCDMA, >WLAN, Bluetooth, etc. I'm sure some clever folks could find a way >to make handovers between these technologies. > >Our document is not to discount MIP, but to be realistic for those >folks looking at making devices. > >I think both FMIPv6 and the BETH extensions are very important documents, >and I think they will enable folks to construct devices that work well with >MIP. > >best regards, >John > > From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 9 18:41:14 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA00229 for ; Mon, 9 Jul 2001 18:41:13 -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 QAA24851; Mon, 9 Jul 2001 16:41: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 PAA04844; Mon, 9 Jul 2001 15:40:16 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f69McndP005701 for ; Mon, 9 Jul 2001 15:38:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f69McmTn005700 for mobile-ip-dist; Mon, 9 Jul 2001 15:38: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 eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f69MckdP005693 for ; Mon, 9 Jul 2001 15:38:47 -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 SAA21199 for ; Mon, 9 Jul 2001 18:38:56 -0400 (EDT) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id SAA00709 for mobile-ip@sunroof.eng.sun.com; Mon, 9 Jul 2001 18:39:19 -0400 (EDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f69MKadP005643 for ; Mon, 9 Jul 2001 15:20:36 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA22751 for ; Mon, 9 Jul 2001 15:20:45 -0700 (PDT) Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA28472 for ; Mon, 9 Jul 2001 15:20:44 -0700 (PDT) Received: from usa.com (nostromo [193.175.132.245]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id AAA15155 for ; Tue, 10 Jul 2001 00:20:41 +0200 (MET DST) Message-ID: <3B4A286E.C362039C@usa.com> Date: Mon, 09 Jul 2001 23:55:59 +0200 From: Liz Bennet X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] CFP: IEEE ICC Symposium on Global Service Portability..DEADLINE: August 15th 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 Apologies if you receive this CFP more than once --------------------------------------------------- CALL FOR PAPERS IEEE International Conference on Communications April 28 - May 2, New York City (http://www.icc2002.com) Global Service Portability and Infrastructure for Virtual Home/Office Environments Symposium ------------------------------------------------------------------------------ SYMPOSIUM THEME Present day mobile systems focus heavily on the radio access segment, with very little attention paid to mobility at the applications and services level. Similarly, in the Internet arena, the standardization efforts for mobility support have mostly focused on enabling the roaming of a terminal identified by its network address. With rapid growth in Internet services and mobile hosts, it has become essential to address new requirements in cases where a customer is roaming between heterogeneous networks and providers. The customer should be able to seamlessly roam between terrestrial and satellite networks, between wireline, wireless and ad-hoc networks, between pure Internet or IP/ATM connections, and between home and office. Different technologies at the service level network level and hardware/physical level are required to be supported to provide such scenario. The purpose is to bring together engineers, practitioners, scientists, as well as industry professionals whose technical interests are global service portability (VHE, MCPE/MCPN, Pervasive Computing, Mobile-Commerce, Open Architectures, APIs), personal area/home wireless networks (WPAN, Bluetooth, HomeRF,..), self-organizing networks and wireless LANs (IEEE 802.11, HiperLAN, Wi-Fi..). The workshop is intended to be a genuinely interactive event with constructive development and exchange of ideas. The list of topics of interest includes (but to limited to): Global Service Portability: -------------------------- - Architecture & design for Virtual Home Environment (VHE) - Architecture & design for Mobile Customer Premises Environments/Networks (MCPE/MCPN) - APIs -based solutions (Parlay, 3GPP Open Service Architecture (OSA) for service portability - Service portability based on Mobile Execution Environment (MExE, Java) - Inter-Service environment roaming architecture and solutions - Inter-Network roaming architecture and solutions to enable VHE - Interoperability in multi-provider access networks - Scalability and adaptation of user terminal to services and platforms - Agents, middleware support, and enablers for VHE - Address and naming portability related to VHE - QoS profiling, billing and Security issues in ensuring VHE - Related standards (3GPP, MWIF, 3G.IP, ETSI, IETF..) Nomadicity Management: --------------------- - Satellite/terrestrial integration for roaming users - Architectures and support for 3G/4G nomadic applications - Micro-mobility, Macro-mobility, Global-mobility for nomadic/roaming users - Distributed Resource Management for nomadic users - Multicast Management for nomadic users - Multimedia Management for nomadic users - Security Management for nomadic users - QoS support with IP mobility - Spontaneous (zero-configuration) network creation for nomadic business users - MANET & Sensors Networks for nomadic users - Self-organizing architectures for nomadic users: IP based, scalable ad-hoc, multihop networks - Discovery Services - Access & Session Support Home/Office Architectures and Infrastructure ------------------------- - Smart Spaces & related applications in home/office - Home-API - Open Service Gateways - Home Audio/Video interoperability - Home Navigator, TV Box, TV-Anytime - Bluetooth wireless technology & experiments for home networks and nomadic users - Wireless Personal Networks (IEEE 802.15) solution in home networks - Infrastructure issues: Lightweight WLAN ( 802.11, HomeRF, etc.), HIPERLAN , IEEE 802.17, Wi-Fi... - Coexistence between WPANs and WLANs in home/office networks - Hand-off protocols/solutions among tethered WPANs in home networks - IP support for home/office area networks - Optical backbone and wireless access support for nomadic users ------------------------------------------------------------------------------ SUBMISSIONS The paper submission schedule and process is the same as for the general ICC 2002 conference. Be sure to indicate the Global service Portability and Infrastructure for Virtual Home/Office Environments Symposium as the target for your paper on the cover page and also list the relevant hot topic(s). See the ICC 2002 Call for Papers for detailed submission instructions (i.e., schedule, paper-length, etc.). ------------------------------------------------------------------------------ IMPORTANT DATES Complete Manuscripts Due: August 15, 2001 Acceptance Notification: December 17, 2001 Camera-Ready Manuscript Due: January 15, 2002 ------------------------------------------------------------------------------ SYMPOSIUM ORGANIZATION Organizing Committee Chair: Prof. Jong-Tae. Park, KNU, Korea Vice-Chairs: Dr. Seshadri Mohan, Comverse Dr. Fawzi Daoud, GMD Fokus, Germany Prof. Dan Keun Sung, KAIST, Korea Advisory Board Member Salah Aidarous, NEC America Veli Sahin, MARCONI Communications Mehmet Ulema, Monmouth Internet Corporation Mashayoshi Ejir, Fujitsu Ltd. Technical Program Committee: Bernard Aboba, Microsoft, USA Claude Castelluccia, INRIA, France Do van Thanh, Telenor, Norway Guenter Karjoth, IBM Labs, Switzerland Hamid Alikhani, Sony International, Germany Hong-Yon Lach, Motorola Labs, France Jayapalan Jay, Motorola, USA John J. Barton, HP Labs, USA Kazi Farooqui, AT&T, USA Lieve Bos, Alcatel Bell, Belgium Moh. Torabi, Lucent Technologies, USA Odd-Wiking Rahlff, SINTEF, Norway Paolo Conforto, Alespazio, Italy Patricia Charlton, Motorola Labs, France Ravi Jain, Telcordia, USA Robert Mort, Alcatel Space, France Stefan Gessler, NEC Labs, Germany Terry Hodgkinson, BT, UK Wang-Chien Lee, GTE, USA Yamanaka Naoaki, NTT Labs, Japan Rami Neudorfer, Comverse Stanley Moyer, Telcordia Technologies Cengiz Akgun, Telcordia Technologies Raouf Boutaba, University of Waterloo, Canada Ioanis Nikolaidis, University of Alberta, Canada Kyungshik Lim, KNU, Korea Ikjun Yeom, KNU, Korea From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 10 03:06:42 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA24463 for ; Tue, 10 Jul 2001 03:06:40 -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 BAA16054; Tue, 10 Jul 2001 01:07:23 -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 AAA03557; Tue, 10 Jul 2001 00:06:03 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f6A74qdP006340 for ; Tue, 10 Jul 2001 00:04:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f6A74pgl006339 for mobile-ip-dist; Tue, 10 Jul 2001 00:04: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.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f6A74mdP006332 for ; Tue, 10 Jul 2001 00:04:48 -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 AAA28891 for ; Tue, 10 Jul 2001 00:04:58 -0700 (PDT) From: john.loughney@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA14933 for ; Tue, 10 Jul 2001 01:04:56 -0600 (MDT) Received: from esvir02nok.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f6A75E318540 for ; Tue, 10 Jul 2001 10:05:14 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 10 Jul 2001 10:04:55 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MS47GTV>; Tue, 10 Jul 2001 10:04:07 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF09BAEE@esebe004.NOE.Nokia.com> To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Ext. for FMIPv6 - comments Date: Tue, 10 Jul 2001 10:03:58 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) 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: Hi James, > With regard to GPRS in general, while there has been a considerable > amount of controversy in the MIP group about GPRS and there is > a certain amount of antagonism on both sides over the issue, > I certainly welcome the manyfolks-ipv6-cellular-host draft *if* it > provides guidance about how to get MIP available in UTRAN systems > for inter-domain handover (I have not had an opportunity to read > the draft yet). The details of this have not been well worked out, > to my knowledge. The draft doesn't seek to provide any network functions - it attempts to outline a list of requirements for a cellular host (i.e. - a terminal with IPv6 that connects to the internet through a cellular network). > I have been told that there is an > alternative inter-domain handover technology called GPRX that involves > tunnelling GPRS over the Internet. This is supposedly used by some GSM > operators, and some are pushing to extend it to UTRAN. I sent out email > on this awhile back. IMHO, having this technology spread to UTRAN is > a really bad idea, because it will make handover between domains that choose > to use MIP and those that use GPRS impossible, regardless of the radio > technology. Do you mean GRX? At least as I have read about GRX, it is currently used for roaming, not for handovers. I haven't heard of any plans within 3GPP to use it for anything else ... but I don't attend 3GPP meetings. Could you point to info on how GRX would be used in the UTRAN? If that is something real, it does sound like a hack. Anyhow, I'll try to dig up some more info on this. > Over the longer term, I think it would make sense for IETF to look > at ways to get MIP and GPRS to interoperate better, just as was > done in the late 80's and early 90's with NETBIOS and IP. If > 3G takes off (a big "if" at this point), there will be alot of GPRS > nodes out there, so it would be in the interests of interoperability > and the Internet to make this happen. I agree. In my mind, the current 3GPP architecture resembles an access network. This makes the GGSN look like the first hop router. The GGSN will be the network element that is involved in address selection, etc. What would be an area to first tackle would be: 1) Getting an RFC on MIP v6 2) Proposing how to allow handoffs from the GGSN to other routers (inter-system) 3) Proposing how to allow handoffs from the GGSN to other GGSNs (inter-domain). I think that some of these issues have been brought to the IETF's attention at the most recent IPNGWG's Interim Meeting in Seattle. PS - one goal of the manyfolks-ipv6-cellular-host is to enable cellular hosts to be good citizens of the Internet, so comments on the draft with regards to this point are very much appreciated. best regards, John From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 10 03:40:43 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA24820 for ; Tue, 10 Jul 2001 03:40: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 AAA03865; Tue, 10 Jul 2001 00:41:26 -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 AAA02294; Tue, 10 Jul 2001 00:39:58 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f6A7a0dP006421 for ; Tue, 10 Jul 2001 00:36:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f6A7a0Jd006420 for mobile-ip-dist; Tue, 10 Jul 2001 00:36: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.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f6A7ZudP006413 for ; Tue, 10 Jul 2001 00:35:57 -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 AAA06035 for ; Tue, 10 Jul 2001 00:36:07 -0700 (PDT) From: john.loughney@nokia.com Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA06252 for ; Tue, 10 Jul 2001 01:37:09 -0600 (MDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f6A7clG21072 for ; Tue, 10 Jul 2001 10:38:47 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 10 Jul 2001 10:35:59 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MS47H8J>; Tue, 10 Jul 2001 10:36:00 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF094017@esebe004.NOE.Nokia.com> To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Ext. for FMIPv6 - comments Date: Tue, 10 Jul 2001 10:35:47 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) 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: Hi George, > I certainly agree that 3GPP (today in all visible releases) > does not have much use for fast MIP handoffs... I am, however, > aware that 3G bodies (not only 3GPP) are looking at MIP and > would like to get more IP in their architecture, although I am > not sure how far they can really go and what > good will that do...but that is another story... I agree. One of the intentions of the manyfolks-ipv6-cellular-host is to work with the current architecture. By no means do I want to limit future evolution. Think of the draft as a starting point. > My point with the manyfolks-ipv6-cellular-host draft was that > it should state that these are guidelines to 3G host implementers > ...rather than general internet hosts (ot even mobile hosts) We intended it to. The introduction does state what a cellular host is to be considered: For the purposes of this draft, a cellular host is considered to be a terminal which uses an air interface to connect to a cellular access network (i.e. - GPRS, UMTS, CDMA2000) in order to provide IPv6 connectivity to an IP network. The functionality to provide IPv6 connectivity is outlined in this draft. This is getting off the topic of the original subject, but just to bring the conversation around to Mobile IP ... There will be some devices that will want to support MIP as well as 3G. The draft should not limit such devices, in fact, we would like to have some text that helps implementors know what functionality is needed in the host in order to support MIP. Now, we are not stating that 3GPP will use MIP, but rather if there was some hybrid device - let's say WLAN with MIP and WCDMA with UMTS, what would be needed to support MIP. > Now I am not sure if this has anything to do with the BETH > extensions, which to my understanding attempt to be applicable > to IP networks in general...not 3G in particular...thank god > there is life beyond 3G! Exactly. I don't want to be here for the purpose of promoting 3G architectures, but to make sure that everyone plays nice :) John From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 10 09:12:48 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA28489 for ; Tue, 10 Jul 2001 09:12:47 -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 HAA09025; Tue, 10 Jul 2001 07:13: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 GAA29672; Tue, 10 Jul 2001 06:12:09 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f6ADB8dP006722 for ; Tue, 10 Jul 2001 06:11:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f6ADB8S6006721 for mobile-ip-dist; Tue, 10 Jul 2001 06:11: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.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f6ADB4dP006714 for ; Tue, 10 Jul 2001 06:11:05 -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 GAA18979 for ; Tue, 10 Jul 2001 06:11:15 -0700 (PDT) From: Basavaraj.Patil@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 HAA18562 for ; Tue, 10 Jul 2001 07:12:22 -0600 (MDT) Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f6ADB1i27703 for ; Tue, 10 Jul 2001 08:11:14 -0500 (CDT) Received: from daebh01nok.americas.nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 10 Jul 2001 08:11:01 -0500 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id ; Tue, 10 Jul 2001 08:11:01 -0500 Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B03213DC0@daeis07nok> To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] WG Last Call - draft-ietf-mobileip-qos-requirements-00.txt Date: Tue, 10 Jul 2001 08:10:58 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) 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: Hello, This is a WG Last call for the I-D "Requirements of a QoS Solution for Mobile IP", draft-ietf-mobileip-qos-requirements-00.txt. Comments appreciated. Intended status for this draft : Informational WG last call issued on: July 10th, 2001 Expires on : July 25th, 2001 Basavaraj Patil Phil Roberts From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 10 10:18:47 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA00052 for ; Tue, 10 Jul 2001 10:18:47 -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 HAA24233; Tue, 10 Jul 2001 07:19:29 -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 HAA08076; Tue, 10 Jul 2001 07:18:09 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f6AEH7dP006814 for ; Tue, 10 Jul 2001 07:17:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f6AEH7vI006813 for mobile-ip-dist; Tue, 10 Jul 2001 07:17: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.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f6AEH4dP006806 for ; Tue, 10 Jul 2001 07:17:04 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA06318 for ; Tue, 10 Jul 2001 07:17:13 -0700 (PDT) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA06894 for ; Tue, 10 Jul 2001 07:17:13 -0700 (PDT) Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21) id ; Tue, 10 Jul 2001 10:16:19 -0400 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Ext. for FMIPv6 - comments Date: Tue, 10 Jul 2001 10:16:18 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) 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: > With regard to GPRS in general, while there has been a considerable > amount of controversy in the MIP group about GPRS and there is > a certain amount of antagonism on both sides over the issue, > I certainly welcome the manyfolks-ipv6-cellular-host draft *if* it > provides guidance about how to get MIP available in UTRAN systems > for inter-domain handover (I have not had an opportunity to read > the draft yet). The details of this have not been well worked out, > to my knowledge. I have been told that there is an > alternative inter-domain > handover technology called GPRX that involves tunnelling GPRS > over the Internet. > This is supposedly used by some GSM operators, and some are > pushing to extend it > to UTRAN. I sent out email on this awhile back. IMHO, having > this technology > spread to UTRAN is a really bad idea, because it will make > handover between > domains that choose to use MIP and those that use GPRS > impossible, regardless of > the radio technology. GPRX is from what I understand the GPRS routing exchange, a private IP network over which GTP is run and allows roaming between different GPRS operator networks. If by domains you mean different operator GPRS networks handover is already defined. If by domains you mean GPRS networks and other kinds of networks (WLAN clouds) I'm not aware of anything being done to extend GTP to cover those. I'm not sure who would do that, it seems a little out of scope for 3gpp, but MIP would be well suited for that. > > Over the longer term, I think it would make sense for IETF to look > at ways to get MIP and GPRS to interoperate better, just as was > done in the late 80's and early 90's with NETBIOS and IP. If > 3G takes off > (a big "if" at this point), there will be alot of GPRS nodes > out there, so it > would be in the interests of interoperability and the Internet to make > this happen. Agreed. > > jak > > >From: George Tsirtsis > >To: "'mobile-ip@sunroof.eng.sun.com'" > >Subject: RE: [mobile-ip] Ext. for FMIPv6 - comments > >Date: Mon, 9 Jul 2001 05:59:43 -0400 > > > >Hi Bechet/John, > > > >I am not sure I can read Bechet's sentiment... > > > >I certainly agree that 3GPP (today in all visible releases) > does not have > >much use for fast MIP handoffs... I am, however, aware that > 3G bodies (not > >only 3GPP) are looking at MIP and would like to get more IP in their > >architecture, although I am not sure how far they can really > go and what > >good will that do...but that is another story...My point with the > >manyfolks-ipv6-cellular-host draft was that it should state > that these are > >guidelines to 3G host implementers...rather than general > internet hosts (ot > >even mobile hosts) > > > >Now I am not sure if this has anything to do with the BETH > extensions, which > >to my understanding attempt to be applicable to IP networks > in general...not > >3G in particular...thank god there is life beyond 3G! > > > >George > > > >-----Original Message----- > >From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > >Sent: Monday, July 09, 2001 8:05 AM > >To: mobile-ip@sunroof.eng.sun.com > >Subject: RE: [mobile-ip] Ext. for FMIPv6 - comments > > > > > >Hi Behcet, > > > > Here is an excerpt from > >draft-manyfolks-ipv6-cellular-host-00.txt: > >Within the current 3GPP architecture, a cellular host will always > > keep the connection to the same GGSN (default router) for > a context. > > Movement between default routers is not permitted. The > only scenario > > where a MN would change default routers is in the case of > a handover > > between two different access technologies. In this case > the MN will > > be simultaneously connected to both routers which would eliminate > > the need for anticipation through the current router. > Hence the Fast > > Handoffs draft will not be required within the current 3GPP > > architecture. > > > >[ ] While I'm not George, and I'm not entirely sure > what email you > >are responding to (clipping part of the previous email is > always helpful to > >relate context to), but as an author of the > >"draft-manyfolks-ipv6-cellular-host-00.txt" > >draft let me say a word or two. > > > >Since 3GPP started from a non-Internet point (3GPP's archictecture > >is more-or-less an evolution of the circuit-switch GSM > architecture), > >mobility for voice & data are handled by layer-2 mobility. > This is the > >current architecture. As it evolves, I don't think we can completely > >discount the adoption of MIP or FMIP. Additionally, 3GPP does not > >specify interworking between different technologies such as WCDMA, > >WLAN, Bluetooth, etc. I'm sure some clever folks could find a way > >to make handovers between these technologies. > > > >Our document is not to discount MIP, but to be realistic for those > >folks looking at making devices. > > > >I think both FMIPv6 and the BETH extensions are very > important documents, > >and I think they will enable folks to construct devices that > work well with > >MIP. > > > >best regards, > >John > > > > > From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 10 11:18:04 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA03232 for ; Tue, 10 Jul 2001 11:18: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 JAA11717; Tue, 10 Jul 2001 09:18:29 -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 IAA16018; Tue, 10 Jul 2001 08:17:11 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f6AFGDdP006899 for ; Tue, 10 Jul 2001 08:16:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f6AFGCKR006898 for mobile-ip-dist; Tue, 10 Jul 2001 08:16: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.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f6AFG9dP006891 for ; Tue, 10 Jul 2001 08:16:09 -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 IAA14183 for ; Tue, 10 Jul 2001 08:16:19 -0700 (PDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id JAA02169 for ; Tue, 10 Jul 2001 09:17:28 -0600 (MDT) Received: (qmail 9222 invoked by uid 500); 10 Jul 2001 15:01:56 -0000 Date: Tue, 10 Jul 2001 08:01:56 -0700 From: Pat Calhoun To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile IPv4 Authentication Internt Draft revision 0.1 Message-ID: <20010710080156.M1062@charizard.diameter.org> References: <200107051821.f65ILNi01063@dharkins@lounge.orgatty.lounge.org> <200107051924.f65JOZi01239@dharkins@lounge.orgatty.lounge.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200107051924.f65JOZi01239@dharkins@lounge.orgatty.lounge.org>; from dharkins@lounge.org on Thu, Jul 05, 2001 at 12:24:35PM -0700 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 Thu, Jul 05, 2001 at 12:24:35PM -0700, Dan Harkins wrote: > It appears my last message got chopped by the list and didn't make > sense. What I was saying is that HMAC-MD5 takes two parameters but > the specification of how to derive a key in the referenced I-D has > only one. > > And it would be nice to know the rationale for using the MN-AAA-key > twice in the derivation. Basically, the authors are trying to mimic the prefix+suffix use of MD5 in RFC 2002. What they seem to have missed here is that HMAC-MD5 is sufficiently cryptographically strong that suffix+prefix is unnecessary. I believe that they meant to concatenate the data into a single string. PatC > > thanks, > > Dan. > > On Thu, 05 Jul 2001 11:21:23 PDT you wrote > > specification on how to derive a key has just one. > > > > Dan. > > > > On Thu, 05 Jul 2001 10:13:30 +0900 junhyuk@metro.telecom.samsung.co.kr wrote > > > > > > MN-HA shared key = HMAC-MD5(MN-AAA-key | FA Challenge | > > > MN NAI | MN-AAA-key) > > > From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 10 12:17:36 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA06693 for ; Tue, 10 Jul 2001 12:17:35 -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 JAA13085; Tue, 10 Jul 2001 09:18: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 JAA26735; Tue, 10 Jul 2001 09:16:30 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f6AGEqdP006982 for ; Tue, 10 Jul 2001 09:14:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f6AGEqlw006981 for mobile-ip-dist; Tue, 10 Jul 2001 09: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.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f6AGEmdP006974 for ; Tue, 10 Jul 2001 09:14:48 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA26493 for ; Tue, 10 Jul 2001 09:14:59 -0700 (PDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id JAA04895 for ; Tue, 10 Jul 2001 09:14:58 -0700 (PDT) Received: (qmail 11334 invoked by uid 500); 10 Jul 2001 16:04:15 -0000 Date: Tue, 10 Jul 2001 09:04:14 -0700 From: Pat Calhoun To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile IPv4 Authentication Internt Draft revision 0.1 Message-ID: <20010710090414.C10676@charizard.diameter.org> References: <43E8CCEAF148D211854C00805FA72E580701988E@rhqnneex1.corp.bam.com> <001001c10844$c16d03f0$10e0d5a5@cdma2000system.samsung.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <001001c10844$c16d03f0$10e0d5a5@cdma2000system.samsung.co.kr>; from cychong@samsung.com on Mon, Jul 09, 2001 at 03:59:53PM +0900 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: > > If the MN-HA key is updated just once every month or year, what is difference of > static MN-HA key. Its long using the MN-HA key might cause entropy problem. the cost of updating the master key on the mobile, and the ability for dynamic home agent assignment. > If it is feasible, how about using just dozens of static MN-HA share key for every > HA. Do you think one home network got the thousand of HA? I don't think so. > Just use 10 static MN-HA shared secret and each shared secret is assigned > to the last digit of HA's IP address. How about use this schem? Maybe this > scheme is lack of key update. But if you consider the same MN-HA key for one > month or even one year, what is difference between static and monthly or yearly > update right but static MN-HA keys do not allow for dynamic HA assignment. > > I think that roaming agreement might consider some sort of security issues. > If you consider, 3GPP or 3GPP2 it means commercial service. Its roaming > agreement is critical to their business. I think FA's random FAC generationg > capability is must stated in the roaming agreement. In this case we would not > worry about the malicious FA. right, but in the IETF we cannot assume the security assumptions that 3GPP(2) make. We have to assume an open network. > Again, Pat/Calloun's method also based on the MN-AAA authentication that could > be hacked by a mallicious FA. If some malicous FA could crack the MN-HA shared > key with a specific FAC, it also do for MN-AAA shared secret. If MN-AAA authenticaiton > is cracked, it's over. That means why you always comment about the MN-HA shared > key generation not the hacking MN-AAA shared secret. I personally think that anything can be hacked, given enough time and resources. The key here is to use an MN-AAA key that is sufficiently strong. Let's look at the flip side, where an unprotected agent advertisement is sent by a malicious mobile on a network, advertising itself as a Foreign Agent, and sending bogus FACs, and the sequence number set to zero (0). This would cause the mobile to update is key.... not the intended effect. PatC From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 10 13:49:24 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11177 for ; Tue, 10 Jul 2001 13:49:23 -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 KAA25353; Tue, 10 Jul 2001 10:49:47 -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 KAA25604; Tue, 10 Jul 2001 10:48:14 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f6AHkUdP007247 for ; Tue, 10 Jul 2001 10:46:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f6AHkUwx007246 for mobile-ip-dist; Tue, 10 Jul 2001 10:46: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.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f6AHkRdP007239 for ; Tue, 10 Jul 2001 10:46:27 -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 KAA14844 for ; Tue, 10 Jul 2001 10:46:38 -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 LAA00967 for ; Tue, 10 Jul 2001 11:46: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 KAA22997 for ; Tue, 10 Jul 2001 10:46:37 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6AHkaN31225 for ; Tue, 10 Jul 2001 10:46:36 -0700 X-mProtect: Tue, 10 Jul 2001 10:46:36 -0700 Nokia Silicon Valley Messaging Protection Received: from vijayd.iprg.nokia.com (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdlyXu0Q; Tue, 10 Jul 2001 10:46:34 PDT Message-ID: <3B4B3F7B.B0AEEA66@iprg.nokia.com> Date: Tue, 10 Jul 2001 10:46: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: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] MIPv6 "granted lifetime" problem References: <92C0C0AC8AE8D411864300105A835CBB50A64D@stslex.siemens.com.tw> 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, comments below > Ra Chen wrote: > > Hi all: > > In our attempt to implement Mobile IPv6, > we encounter the following problem. > > In draft-ietf-mobileip-ipv6-14.txt, Sec. 10.13, > it's described that the reamining lifetime should be > max((L_remain - (L_update - L_ack)), 0) > > Here is an implementation problem. > To do the calculation, L_ack and L_update must be a pair. > That is, the BU of L_update and the BA of L_ack > must have identical sequence number. > > However, according to Sec. 4.6, > for multiple Binding Updates sent to the same destination > address, the Binding Update List contains only the most > recent > Binding Update (i.e., with the greatest Sequence Number > value) > sent to that destination. > Now if the BA for the initial BU is received after a BU > retransmission, this BA is dropped. only the BA with the sequence number matching the most recent BU is accepted. so you need to store the state only for the most recent BU sent. Vijay > the mobile node has no information about L_update, > which has been overwritten by the BU retransmission, > and doing the calculation correctly is impossible. > > To fully comply with the draft, > the mobile node has to record L_update for ALL its un-Acked BU, > in order to use the matching L_update once a BA is received. > This seems against the spirit of Sec.4.6. > > Best Regards > > ================================== > Ra Chen > Siemens Telecommunication Systems Ltd. > R&D Engineer > E-mail: ra@stsl.siemens.com.tw > Tel: 886-2-2518-6539 > Fax: 886-2-2505-3866 > ================================== From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 10 14:30:10 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA13505 for ; Tue, 10 Jul 2001 14:30:10 -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 LAA13759; Tue, 10 Jul 2001 11:20:03 -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 LAA15695; Tue, 10 Jul 2001 11:18:37 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f6AIHadP007298 for ; Tue, 10 Jul 2001 11:17:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f6AIHaqV007297 for mobile-ip-dist; Tue, 10 Jul 2001 11:17: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.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f6AIHWdP007290 for ; Tue, 10 Jul 2001 11:17:32 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA03357 for ; Tue, 10 Jul 2001 11:17:41 -0700 (PDT) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA20434 for ; Tue, 10 Jul 2001 11:17:38 -0700 (PDT) Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21) id ; Tue, 10 Jul 2001 14:16:44 -0400 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] *very* rough agenda Date: Tue, 10 Jul 2001 14:16:39 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) 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: Hi folks, here is a *very* rough first draft agenda. I haven't had the time to slap in correct draft names and such, but we'd like feedback on what we already have in mind for an agenda. Below the line is essentially overtime. Phil Agenda Phil 5 minutes WG docs submitted to AD (hopefully) Phil 10 minutes mier gnai 3g wireless 2002bis (gen key ext) (AAA keys) (Reg Reg) (MIP QoS Reqts) Moving MIPv4 to draft standard Charlie 15 minutes Mobile IP v6 30 minutes security update other changes in -14 v4 Fast Handover who? 10 minutes v6 Fast Handover Gopal 10 minutes BETH James 10 minutes LMM Requirements Carl 15 minutes MobileIP Redundancy Madhavi 15 minutes L2 Interface Abstraction Kempf/Soliman 10 minutes Mobile IP QoS Requirements Hemant 10 Minutes draft-ietf-mobileip-qos-requirements-00.txt --------------------------- ?Bicasting draft-elmalki-mipv6-bicasting-00.txt Hesham 10 min ?Flow Move draft-soliman-mipv6-flow-move-00.txt Hesham 10 min Steve Glass Registration REvocation 5 minutes MIP and NAT draft-sharier-mobileip-nat-00 10 minutes Mobility Support using MPLS Technology draft-choi-mobileip-ipv6-mpls-01.txt & draft-choi-mobileip-ldpext-02.txt 10 minutes From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 10 20:06:01 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA00714 for ; Tue, 10 Jul 2001 20:05: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 SAA03474; Tue, 10 Jul 2001 18:06: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 RAA27106; Tue, 10 Jul 2001 17:05:14 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f6B03ndP007668 for ; Tue, 10 Jul 2001 17:03:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f6B03nDB007667 for mobile-ip-dist; Tue, 10 Jul 2001 17:03: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.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f6B03jdP007660 for ; Tue, 10 Jul 2001 17:03: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 RAA22961 for ; Tue, 10 Jul 2001 17:03: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 SAA07574; Tue, 10 Jul 2001 18:05:03 -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 RAA19855; Tue, 10 Jul 2001 17:03:19 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6B03I128528; Tue, 10 Jul 2001 17:03:18 -0700 X-mProtect: Tue, 10 Jul 2001 17:03:18 -0700 Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdbmaIwa; Tue, 10 Jul 2001 17:03:17 PDT Message-ID: <3B4B97C5.5446FEA8@iprg.nokia.com> Date: Tue, 10 Jul 2001 17:03:17 -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: mobile-ip@sunroof.eng.sun.com, seamoby@cdma-2000.org, charliep@iprg.nokia.com Subject: [mobile-ip] Re: Extensions to FMIPv6 References: <5.0.0.25.0.20010706220851.01f18030@localhost> 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 James, I wonder if you had a look at our CT draft: draft-koodli-seamoby-ctv6-00.txt.. We don't have discussion about L2 triggers in that draft, but, definitely context transfers and handovers. Indeed, we describe how to do context transfers with FMIPv6. Our approach clearly separates what a feature context is from the message in which it is carried so that one could use them in appropriate messages, including HI and HAck. We plan to submit a revised version for London IETF. Regards, -Rajeev James Kempf wrote: > John, > > (Folks, sorry for the cross posting, please try to respond on > one or the other list unless the topic affects both...) > > There is a draft in preparation with people from both Seamoby > and MIP on the author list. These are people with whom > I have talked and who have expressed interest in working on such a > draft over the last year. The draft has a section on L2 triggers > that came out of the MIP fast handoff work, then a section > that describes connections with Seamoby context transfer. > I expect we will have it complete by next Fri.'s 00 deadline. > > We have already talked to the MIP WG chairs about getting > time on the agenda to discuss the draft, what I'd like > to suggest is that we do the same for Seamoby. That > will give both WGs the opportunity to review and comment > on the draft. I will talk with Pat about that when he gets > back from vacation. > > jak > > At 10:13 AM 7/4/01 +0300, john.loughney@nokia.com wrote: > >Hi James, > > > > > In fact, I am preparing just such a draft as we speak. The > > > intent is to take the material from the BETH draft and from > > > the FMIPv4 draft and perhaps add something on the link with > > > Seamoby context transfer. > > > >I think this would be extremely worthwhile. It seems that > >SeaMoby is currently struggling over terminology about > >triggers, etc. with respect to handovers. I'd even suggest > >that interested parties from both MIP & SeaMoby get together > >in London to discuss how to move forward. Perhaps it would > >be a good thing if MIP & SeaMoby could work together on this > >issue - in order to assure that the resultant work suits both > >groups. > > > >best regards, > >John From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 10 22:47:40 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA06229 for ; Tue, 10 Jul 2001 22:47:39 -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 TAA27983; Tue, 10 Jul 2001 19:48:19 -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 TAA25430; Tue, 10 Jul 2001 19:46:53 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f6B2jAdP007765 for ; Tue, 10 Jul 2001 19:45:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f6B2jAOj007764 for mobile-ip-dist; Tue, 10 Jul 2001 19:45: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f6B2j6dP007757 for ; Tue, 10 Jul 2001 19:45:06 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA25310 for ; Tue, 10 Jul 2001 19:45:17 -0700 (PDT) Received: from stsl.siemens.com.tw (stsl.siemens.com.tw [192.72.45.189]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA13159 for ; Tue, 10 Jul 2001 19:45:10 -0700 (PDT) Received: from stslex.siemens.com.tw (stslex [192.72.45.13]) by stsl.siemens.com.tw (8.11.4/8.11.4) with ESMTP id f6B2w9X05339 for ; Wed, 11 Jul 2001 10:58:09 +0800 (CST) Received: by stslex.siemens.com.tw with Internet Mail Service (5.5.2650.21) id <3KMSTCH3>; Wed, 11 Jul 2001 10:43:22 +0800 Message-ID: <92C0C0AC8AE8D411864300105A835CBB50A64F@stslex.siemens.com.tw> From: Ra Chen To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] MIPv6 "granted lifetime" problem Date: Wed, 11 Jul 2001 10:42:04 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C109B3.11FE29B0" 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_01C109B3.11FE29B0 Content-Type: text/plain; charset="BIG5" > -----Original Message----- > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > > > Now if the BA for the initial BU is received after a BU > > retransmission, > > this BA is dropped. only the BA with the sequence number matching > the most recent BU is accepted. I don't think so. According to 10.13, Upon receiving a packet carrying a Binding Acknowledgement, a mobile node MUST validate the packet according to the following tests: - ... - ... - The Sequence Number field matches the Sequence Number sent by the mobile node to this destination address in an outstanding Binding Update. The indefinite article "an" is used here. My interpretation is that a BA matching any outstanding BU should be accepted. If actually the draft requires MN to accept only the BA matching the most recent BU, it should state it more clearly. Ra ------_=_NextPart_001_01C109B3.11FE29B0 Content-Type: text/html; charset="BIG5" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] MIPv6 "granted lifetime" = problem

> -----Original Message-----
> From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com]<= /FONT>
>
> > Now if the BA for the initial BU is = received after a BU
> > retransmission,
>
> this BA is dropped. only the BA with the = sequence number matching
> the most recent BU is accepted.
 
I don't think so.  According to 10.13,

        Upon = receiving a packet carrying a Binding Acknowledgement, a mobile
        node MUST = validate the packet according to the following tests:
         = -  ...
         = -  ...
         = -  The Sequence Number field matches the Sequence Number sent by = the
          &nb= sp; mobile node to this destination address in an outstanding = Binding
          &nb= sp; Update.

The indefinite article "an" is used = here.
My interpretation is that a BA matching any = outstanding BU should be accepted.
If actually the draft requires MN to accept only the = BA matching the most recent BU,
it should state it more clearly.

Ra

------_=_NextPart_001_01C109B3.11FE29B0-- From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 11 01:25:23 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA12659 for ; Wed, 11 Jul 2001 01:25:22 -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 WAA24916; Tue, 10 Jul 2001 22:26:02 -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 WAA27688; Tue, 10 Jul 2001 22:24:38 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f6B5NVdP007891 for ; Tue, 10 Jul 2001 22:23:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f6B5NUsh007890 for mobile-ip-dist; Tue, 10 Jul 2001 22:23: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.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f6B5NRdP007883 for ; Tue, 10 Jul 2001 22:23:27 -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 WAA27583 for ; Tue, 10 Jul 2001 22:23:38 -0700 (PDT) Received: from mail.n016.co.kr ([203.229.169.4]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA27104 for ; Tue, 10 Jul 2001 23:24:48 -0600 (MDT) Received: from freenet.ktf.co.kr (freenet.ktf.com [203.229.169.83]) by mail.n016.co.kr (v3smtp 8.11.4 Copyright (c) 1998-2001 Sendmail, Inc. All rights reserved.Copyright (c) 1988, 1993 The Regents of the University of California. All rights reserved./8.11.1) with ESMTP id f6B5JNk09334 for ; Wed, 11 Jul 2001 14:19:23 +0900 (KST) Received: from words ([10.6.10.174]) by freenet.ktf.co.kr (8.9.3/8.9.3) with SMTP id OAA29370 for ; Wed, 11 Jul 2001 14:21:04 +0900 (KST) Message-ID: <015101c109c9$481b9c10$ae0a060a@words> From: "Jiwoong Lee" To: Subject: [mobile-ip] Do we need Reverse Tunnel in MIPv6 ? Date: Wed, 11 Jul 2001 14:21:04 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 8bit 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: 8bit Do we need Reverse Tunnel in Mobile IPv6 for location privacy ? Then, can you imagine different requirement for Reverse tunnel in Mobile IPv6? Regards, Jiwoong From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 11 11:03:45 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06514 for ; Wed, 11 Jul 2001 11:03: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 JAA26070; Wed, 11 Jul 2001 09:04:13 -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 IAA14387; Wed, 11 Jul 2001 08:02:54 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f6BF1WdP008422 for ; Wed, 11 Jul 2001 08:01:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f6BF1WXU008421 for mobile-ip-dist; Wed, 11 Jul 2001 08:01: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.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f6BF1TdP008414 for ; Wed, 11 Jul 2001 08:01: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 IAA25362 for ; Wed, 11 Jul 2001 08:01:38 -0700 (PDT) Received: from EXCHANGE01.domain.ecutel.com ([65.201.154.134]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA14339 for ; Wed, 11 Jul 2001 09:02:46 -0600 (MDT) X-Mimeole: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message Subject: RE: [mobile-ip] Do we need Reverse Tunnel in MIPv6 ? MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Date: Wed, 11 Jul 2001 11:01:35 -0400 Message-ID: Thread-Topic: [mobile-ip] Do we need Reverse Tunnel in MIPv6 ? Thread-Index: AcEJydISfEWk+hPgQ8GkTAw6SUxuGAAWOjFg From: "Qiang Zhang" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f6BF1TdP008415 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 That would be interesting, then the HA will be required to shadow the binding update to CN, the MN has to go through an encapsulation reverse tunnel. I can imagine in a scenario that the MN has no Security Assoc with others but the HA and requires only the SA to/from HA, then the routing can be fixed in that way. Correct? -----Original Message----- From: Jiwoong Lee [mailto:porce@ktf.com] Sent: Wednesday, July 11, 2001 12:21 AM To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Do we need Reverse Tunnel in MIPv6 ? Do we need Reverse Tunnel in Mobile IPv6 for location privacy ? Then, can you imagine different requirement for Reverse tunnel in Mobile IPv6? Regards, Jiwoong From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 11 14:19:48 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14465 for ; Wed, 11 Jul 2001 14:19: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 MAA08092; Wed, 11 Jul 2001 12:20: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 LAA28677; Wed, 11 Jul 2001 11:19:01 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f6BIHedP008612 for ; Wed, 11 Jul 2001 11:17:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f6BIHeqF008611 for mobile-ip-dist; Wed, 11 Jul 2001 11:17: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 heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f6BIHbdP008604 for ; Wed, 11 Jul 2001 11:17:37 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id LAA00643 for ; Wed, 11 Jul 2001 11:17:47 -0700 (PDT) Message-Id: <200107111817.LAA00643@heliopolis.eng.sun.com> Date: Wed, 11 Jul 2001 11:17:46 -0700 (PDT) From: James Kempf Subject: [mobile-ip] BETH for FMIPv4? To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: tVBfcDZ88lFZK+3regz8jw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 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: Folks, The fast handover technique described in draft-kempf-beth-ipv6-00.txt is also applicable to IPv4. In fact, it is an extension to the POST-REG technique in draft-ietf-mobileip-lowlatency-handoffs-ipv4-01.txt and it handles the case where the MN moves quickly to a third FA before it has a chance to complete new CoA establishment. Is there any objection to modifying the POST-REG section of draft-ietf-mobileip-lowlatency-handoffs-ipv4-01.txt to incorporate a MIPv4 version of BETH? jak From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 11 17:31:44 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA21155 for ; Wed, 11 Jul 2001 17:31: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 PAA20730; Wed, 11 Jul 2001 15:24:09 -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 OAA15610; Wed, 11 Jul 2001 14:22:47 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f6BLLNdP008913 for ; Wed, 11 Jul 2001 14:21:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f6BLLMXq008912 for mobile-ip-dist; Wed, 11 Jul 2001 14:21: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f6BLLJdP008905 for ; Wed, 11 Jul 2001 14:21:19 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA18961 for ; Wed, 11 Jul 2001 14:21:30 -0700 (PDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA10142 for ; Wed, 11 Jul 2001 14:21:28 -0700 (PDT) Received: from mira-sjcm-3.cisco.com (mira-sjcm-3.cisco.com [171.69.24.15]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f6BLLX006089 for ; Wed, 11 Jul 2001 14:21:33 -0700 (PDT) Received: from GDOMMETY-W2K2.cisco.com (dhcp-171-70-57-19.cisco.com [171.70.57.19]) by mira-sjcm-3.cisco.com (Mirapoint) with ESMTP id AAF07747; Wed, 11 Jul 2001 14:20:07 -0700 (PDT) Message-Id: <4.3.2.7.2.20010711142135.016578b0@mira-sjcm-3.cisco.com> X-Sender: gdommety@mira-sjcm-3.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 11 Jul 2001 14:22:35 -0700 To: mobile-ip@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com From: Gopal Dommety Subject: Re: [mobile-ip] BETH for FMIPv4? In-Reply-To: <200107111817.LAA00643@heliopolis.eng.sun.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 11:17 AM 7/11/2001 -0700, James Kempf wrote: >Folks, > >The fast handover technique described in draft-kempf-beth-ipv6-00.txt >is also applicable to IPv4. In fact, it is an extension to the >POST-REG technique in draft-ietf-mobileip-lowlatency-handoffs-ipv4-01.txt >and it handles the case where the MN moves quickly to a third FA >before it has a chance to complete new CoA establishment. > >Is there any objection to modifying the POST-REG section of >draft-ietf-mobileip-lowlatency-handoffs-ipv4-01.txt to incorporate >a MIPv4 version of BETH? I think it is a good idea. -gopal > jak From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 11 18:03:25 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA22187 for ; Wed, 11 Jul 2001 18:03:24 -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 QAA18871; Wed, 11 Jul 2001 16:04: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 PAA28212; Wed, 11 Jul 2001 15:02:39 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f6BM10dP008955 for ; Wed, 11 Jul 2001 15:01:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f6BM10fB008954 for mobile-ip-dist; Wed, 11 Jul 2001 15:01: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f6BM0udP008947 for ; Wed, 11 Jul 2001 15:00:56 -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 PAA24613 for ; Wed, 11 Jul 2001 15:01:06 -0700 (PDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA05663 for ; Wed, 11 Jul 2001 16:02:15 -0600 (MDT) Received: from mira-sjcm-3.cisco.com (mira-sjcm-3.cisco.com [171.69.24.15]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f6BM1C026264 for ; Wed, 11 Jul 2001 15:01:13 -0700 (PDT) Received: from GDOMMETY-W2K2.cisco.com (dhcp-171-70-57-19.cisco.com [171.70.57.19]) by mira-sjcm-3.cisco.com (Mirapoint) with ESMTP id AAF08730; Wed, 11 Jul 2001 14:55:45 -0700 (PDT) Message-Id: <4.3.2.7.2.20010711145639.01674468@mira-sjcm-3.cisco.com> X-Sender: gdommety@mira-sjcm-3.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 11 Jul 2001 14:58:18 -0700 To: mobile-ip@sunroof.eng.sun.com From: Gopal Dommety Subject: Re: [mobile-ip] *very* rough agenda In-Reply-To: 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: Phil, I will be presenting the HA redundancy draft by Madhavi and Kent. -Gopal At 02:16 PM 7/10/2001 -0400, you wrote: >Hi folks, > > here is a *very* rough first draft agenda. I haven't had the time >to slap in correct draft names and such, but we'd like feedback on >what we already have in mind for an agenda. Below the line is essentially >overtime. > >Phil > > > > >Agenda Phil 5 minutes >WG docs submitted to AD (hopefully) Phil 10 minutes > mier > gnai > 3g wireless > 2002bis > (gen key ext) > (AAA keys) > (Reg Reg) > (MIP QoS Reqts) > >Moving MIPv4 to draft standard Charlie 15 minutes > >Mobile IP v6 30 minutes > security update > other changes in -14 > >v4 Fast Handover who? 10 minutes > >v6 Fast Handover Gopal 10 minutes >BETH James 10 minutes > >LMM Requirements Carl 15 minutes > >MobileIP Redundancy Madhavi 15 minutes > >L2 Interface Abstraction Kempf/Soliman 10 minutes > >Mobile IP QoS Requirements Hemant 10 Minutes >draft-ietf-mobileip-qos-requirements-00.txt > >--------------------------- > >?Bicasting draft-elmalki-mipv6-bicasting-00.txt Hesham 10 min >?Flow Move draft-soliman-mipv6-flow-move-00.txt Hesham 10 min > >Steve Glass Registration REvocation 5 minutes > >MIP and NAT draft-sharier-mobileip-nat-00 10 minutes > >Mobility Support using MPLS Technology draft-choi-mobileip-ipv6-mpls-01.txt >& > draft-choi-mobileip-ldpext-02.txt 10 >minutes From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 11 18:23:34 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA22689 for ; Wed, 11 Jul 2001 18:23:34 -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 PAA28902; Wed, 11 Jul 2001 15:22:59 -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 PAA02436; Wed, 11 Jul 2001 15:21:34 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f6BMK2dP009042 for ; Wed, 11 Jul 2001 15:20:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f6BMK2VQ009041 for mobile-ip-dist; Wed, 11 Jul 2001 15:20: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 heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f6BMJxdP009032 for ; Wed, 11 Jul 2001 15:19:59 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id PAA14645; Wed, 11 Jul 2001 15:20:07 -0700 (PDT) Message-Id: <200107112220.PAA14645@heliopolis.eng.sun.com> Date: Wed, 11 Jul 2001 15:20:07 -0700 (PDT) From: James Kempf Subject: [mobile-ip] Re: Extensions to FMIPv6 To: james.kempf@Sun.COM, rajeev@iprg.nokia.com Cc: mobile-ip@sunroof.eng.sun.com, seamoby@cdma-2000.org, charliep@iprg.nokia.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 07fVpQjy+luxwXZ4m7WgXw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 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: Rajeev, I have not looked at it in a while, but I will again. Thanx. jak >X-mProtect: Tue, 10 Jul 2001 17:03:18 -0700 Nokia Silicon Valley Messaging Protection >Date: Tue, 10 Jul 2001 17:03:17 -0700 >From: Rajeev Koodli >To: James Kempf >CC: mobile-ip@sunroof.eng.sun.com, seamoby@cdma-2000.org, charliep@iprg.nokia.com >Subject: Re: Extensions to FMIPv6 > > >Hello James, > >I wonder if you had a look at our CT draft: >draft-koodli-seamoby-ctv6-00.txt.. > >We don't have discussion about L2 triggers in that draft, but, >definitely context transfers and handovers. Indeed, we describe how to >do context transfers with FMIPv6. Our approach clearly separates what a >feature context is from the message in which it is carried so that one >could use them in appropriate messages, including HI and HAck. We plan >to submit a revised version for London IETF. > >Regards, > >-Rajeev > > >James Kempf wrote: > >> John, >> >> (Folks, sorry for the cross posting, please try to respond on >> one or the other list unless the topic affects both...) >> >> There is a draft in preparation with people from both Seamoby >> and MIP on the author list. These are people with whom >> I have talked and who have expressed interest in working on such a >> draft over the last year. The draft has a section on L2 triggers >> that came out of the MIP fast handoff work, then a section >> that describes connections with Seamoby context transfer. >> I expect we will have it complete by next Fri.'s 00 deadline. >> >> We have already talked to the MIP WG chairs about getting >> time on the agenda to discuss the draft, what I'd like >> to suggest is that we do the same for Seamoby. That >> will give both WGs the opportunity to review and comment >> on the draft. I will talk with Pat about that when he gets >> back from vacation. >> >> jak >> >> At 10:13 AM 7/4/01 +0300, john.loughney@nokia.com wrote: >> >Hi James, >> > >> > > In fact, I am preparing just such a draft as we speak. The >> > > intent is to take the material from the BETH draft and from >> > > the FMIPv4 draft and perhaps add something on the link with >> > > Seamoby context transfer. >> > >> >I think this would be extremely worthwhile. It seems that >> >SeaMoby is currently struggling over terminology about >> >triggers, etc. with respect to handovers. I'd even suggest >> >that interested parties from both MIP & SeaMoby get together >> >in London to discuss how to move forward. Perhaps it would >> >be a good thing if MIP & SeaMoby could work together on this >> >issue - in order to assure that the resultant work suits both >> >groups. >> > >> >best regards, >> >John > From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 11 19:22:55 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA24515 for ; Wed, 11 Jul 2001 19:22:55 -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 QAA22576; Wed, 11 Jul 2001 16:23: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 QAA11667; Wed, 11 Jul 2001 16:22:09 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f6BNL7dP009118 for ; Wed, 11 Jul 2001 16:21:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f6BNL74I009117 for mobile-ip-dist; Wed, 11 Jul 2001 16:21: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 jurassic.eng.sun.com (jurassic [129.146.85.31] (may be forged)) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f6BNL2dP009110 for ; Wed, 11 Jul 2001 16:21:03 -0700 (PDT) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by jurassic.eng.sun.com (8.11.4+Sun/8.11.4) with SMTP id f6BNKxN530930 for ; Wed, 11 Jul 2001 16:20:59 -0700 (PDT) Message-Id: <200107112320.f6BNKxN530930@jurassic.eng.sun.com> Date: Wed, 11 Jul 2001 19:21:29 -0400 (EDT) From: Steven Glass - Solaris Software Subject: [mobile-ip] Registration revocation issues To: mobile-ip@sunroof.eng.sun.com X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5_11 SunOS 5.8.1 sun4u sparc Content-Type: text X-Sun-Text-Type: 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'm just about done updating the revocation draft, and I have a few questions to ask the group: 1) How do people feel about an "I understand revocations" registration extension? It would be a skippable type (if not understood), and would be added to either a registration request by the FA, or to a registration reply by the HA, to tell the mipagent-peer it understands revocation messages (for future reference). The idea here is to know when a mipagent can send a revocation message to its mipagent-peer. The good thing is with this knowledge it potentially cuts down processing time/bandwidth utilization, etc. The problem I see with it is (e.g.) if I'm an HA, even if I don't receive this extension, if I'm revoking the MN's binding I may as well send a revocation message to the FA anyway, and ditto if I'm an FA. Since these messages are likely to get sent regardless, why do we need it? If the working group wants this, there's an extention to the argument (which I'm not saying I agree with) that we may as well use the [last] bit in the becon to advertise revocation support (thereby allowing the MN to chose the FA which supports revocation from others which do not), then include another bit in the registration request itself (to indicate the FA I'm registering with supports revocations) without adding the overhead of the extension. My thoughts are if enough people want it, it'll be supported as 'core' mobile-ip, and along with the fact that revocation is basically just "FYI: I've revoked my side of the tunnel", adding an extension may be more overhead than we get functionality. 2) I'm removing the lifetime field. It can cause confusion - e.g. if a MN has 1 hour left on it's binding, and is then revoked for 20 minutes, does it's binding get 'resurected' after 20 minutes (for 40 more minutes). If no, why bother with it, and if yes, how do you keep the MN "happy" in the mean time, and notify it when it's binding is back? Seems better just to remove it, but -> since people like the idea of conditional and unconditional revocation, in it's place I'm putting a 'P' bit for "permanent" meaning "this binding is permanently revoked." When not set, the binding can be renegotiated, and when it is set, the implication is the mipagent peer will not allow the binding to be renegotiated. Any discenting oppinions from those who like a revocation lifetime better? Cheers, Steve From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 11 19:38:28 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA24868 for ; Wed, 11 Jul 2001 19:38:27 -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 QAA27254; Wed, 11 Jul 2001 16:39: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 QAA06362; Wed, 11 Jul 2001 16:37:46 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f6BNaidP009165 for ; Wed, 11 Jul 2001 16:36:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f6BNaiBE009164 for mobile-ip-dist; Wed, 11 Jul 2001 16:36: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.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f6BNaedP009157 for ; Wed, 11 Jul 2001 16:36: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 QAA04635 for ; Wed, 11 Jul 2001 16:36:51 -0700 (PDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id RAA15575 for ; Wed, 11 Jul 2001 17:36:49 -0600 (MDT) Received: (qmail 13464 invoked by uid 500); 11 Jul 2001 23:26:01 -0000 Date: Wed, 11 Jul 2001 16:26:01 -0700 From: Pat Calhoun To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Registration revocation issues Message-ID: <20010711162601.N5588@charizard.diameter.org> References: <200107112320.f6BNKxN530930@jurassic.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200107112320.f6BNKxN530930@jurassic.eng.sun.com>; from glass@jurassic.eng.sun.com on Wed, Jul 11, 2001 at 07:21:29PM -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: On Wed, Jul 11, 2001 at 07:21:29PM -0400, Steven Glass - Solaris Software wrote: > I'm just about done updating the revocation draft, and I have a few > questions to ask the group: > > 1) How do people feel about an "I understand revocations" registration > extension? I prefer this than simply assuming it does. > > It would be a skippable type (if not understood), and would be added to > either a registration request by the FA, or to a registration reply by the HA, > to tell the mipagent-peer it understands revocation messages (for future > reference). > > The idea here is to know when a mipagent can send a revocation message to > its mipagent-peer. The good thing is with this knowledge it potentially cuts > down processing time/bandwidth utilization, etc. The problem I see with it is > (e.g.) if I'm an HA, even if I don't receive this extension, if I'm revoking the > MN's binding I may as well send a revocation message to the FA anyway, and ditto > if I'm an FA. Since these messages are likely to get sent regardless, why do we > need it? If the working group wants this, there's an extention to the argument > (which I'm not saying I agree with) that we may as well use the [last] bit in > the becon to advertise revocation support (thereby allowing the MN to chose the > FA which supports revocation from others which do not), then include another bit > in the registration request itself (to indicate the FA I'm registering with > supports revocations) without adding the overhead of the extension. My thoughts > are if enough people want it, it'll be supported as 'core' mobile-ip, and along > with the fact that revocation is basically just "FYI: I've revoked my side of > the tunnel", adding an extension may be more overhead than we get functionality. The way I see it, I see no reason to send a new message type to an FA that may not recognize it. Chances are that an implementation will simply drop the message, causing the HA to retransmit, and eventually give up. If an FA advertises itself as supporting this extension, then you know that lack of response means that FA is really not reachable. Further, revocations MUST NOT be sent upon a binding expiration, right? It's only sent if a binding is revoked prior to lifetime expiration. > > 2) I'm removing the lifetime field. > > It can cause confusion - e.g. if a MN has 1 hour left on it's binding, and > is then revoked for 20 minutes, does it's binding get 'resurected' after 20 > minutes (for 40 more minutes). If no, why bother with it, and if yes, how do > you keep the MN "happy" in the mean time, and notify it when it's binding is > back? Seems better just to remove it, but -> since people like the idea of > conditional and unconditional revocation, in it's place I'm putting a 'P' bit > for "permanent" meaning "this binding is permanently revoked." When not set, > the binding can be renegotiated, and when it is set, the implication is the > mipagent peer will not allow the binding to be renegotiated. Any discenting > oppinions from those who like a revocation lifetime better? lifetimes are out, IMHO. A revocation means the session is terminated. If the MN wants to renew service, it can send a new registration request. PatC From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 11 19:56:34 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA25295 for ; Wed, 11 Jul 2001 19:56:34 -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 RAA25985; Wed, 11 Jul 2001 17:56: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 QAA09563; Wed, 11 Jul 2001 16:56:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6BNtB909308 for mobile-ip-dist; Wed, 11 Jul 2001 16:55:11 -0700 (PDT) Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6BNt9N09301 for ; Wed, 11 Jul 2001 16:55:09 -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 TAA23966 for ; Wed, 11 Jul 2001 19:55:18 -0400 (EDT) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id TAA21208 for mobile-ip@sunroof.eng.sun.com; Wed, 11 Jul 2001 19:55:42 -0400 (EDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f6BJZEdP008725 for ; Wed, 11 Jul 2001 12:35:14 -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 MAA15922 for ; Wed, 11 Jul 2001 12:35:24 -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 NAA24080 for ; Wed, 11 Jul 2001 13:36: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 MAA23478; Wed, 11 Jul 2001 12:34:24 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6BJYOt03189; Wed, 11 Jul 2001 12:34:24 -0700 X-mProtect: Wed, 11 Jul 2001 12:34:24 -0700 Nokia Silicon Valley Messaging Protection Received: from tpagtzis.iprg.nokia.com (205.226.2.115, claiming to be "cs.ucl.ac.uk") by darkstar.iprg.nokia.com(P1.5 smtpdusbZE0; Wed, 11 Jul 2001 12:34:22 PDT Message-ID: <3B4CAA3E.53767C96@cs.ucl.ac.uk> Date: Wed, 11 Jul 2001 12:34:22 -0700 From: Theo Pagtzis Organization: UCL/NOKIA X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.1-STABLE i386) X-Accept-Language: el, en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com CC: seamoby@diameter.org, seamoby_context@standards.nortelnetworks.com Subject: [mobile-ip] New Internet Draft on proactive mobility over Mobile IPv6 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 all, here is the link for our draft specification submitted yesterday to the Internet drafts management group of IETF. The draft specification is mainly targeting the MobileIP group, but it bears great relevance to the Seamoby group and in particular the context transfer design team. Hence the cross-posting. The draft comprizes of two documents due to the complexity of schematics and a formulae that accompany the design specified. For this reason the reader is invited to read the ascii version but consult the postscript version for schematics and formulae. The postscript version is self contained while we are striving towards making the ASCII version a stand alone document with its own text art schematics and formulae. Both ASCII and Postscript version of the draft can be found at http://www.cs.ucl.ac.uk/staff/t.pagtzis/docs/docs.html with details as follows: Title : A Framework for Proactive Mobility in Mobile IPv6. Author(s) : Theo Pagtzis and Peter Kirstein Filename : draft-pagtzis-mobileip-proactivev6-00.txt/.ps Pages : 78 (ASCII), 81 (postscript) Date : 10-Jul-01 Any comments would be highly appreciated. Many Thanks Theo UCL/Mobile Systems From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 11 19:57:28 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA25339 for ; Wed, 11 Jul 2001 19:57:28 -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 QAA03120; Wed, 11 Jul 2001 16:57:39 -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 QAA09739; Wed, 11 Jul 2001 16:57:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6BNuN509355 for mobile-ip-dist; Wed, 11 Jul 2001 16:56:23 -0700 (PDT) Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6BNuJN09343 for ; Wed, 11 Jul 2001 16:56:19 -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 TAA24067 for ; Wed, 11 Jul 2001 19:56:25 -0400 (EDT) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id TAA21232 for mobile-ip@sunroof.eng.sun.com; Wed, 11 Jul 2001 19:56:49 -0400 (EDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f6BKn5dP008879 for ; Wed, 11 Jul 2001 13:49:05 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA12278 for ; Wed, 11 Jul 2001 13:49:16 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA24032 for ; Wed, 11 Jul 2001 13:49:16 -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 NAA28671; Wed, 11 Jul 2001 13:48:30 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6BKmTM17665; Wed, 11 Jul 2001 13:48:29 -0700 X-mProtect: Wed, 11 Jul 2001 13:48:29 -0700 Nokia Silicon Valley Messaging Protection Received: from tpagtzis.iprg.nokia.com (205.226.2.115, claiming to be "cs.ucl.ac.uk") by darkstar.iprg.nokia.com(P1.5 smtpdbx0AgH; Wed, 11 Jul 2001 13:48:27 PDT Message-ID: <3B4CBB9C.5676AB95@cs.ucl.ac.uk> Date: Wed, 11 Jul 2001 13:48:28 -0700 From: Theo Pagtzis Organization: UCL/NOKIA X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.1-STABLE i386) X-Accept-Language: el, en MIME-Version: 1.0 To: Nakhjiri Madjid-MNAKHJI1 CC: seamoby-context@cdma-2000.org, mobile-ip@sunroof.eng.sun.com, seamoby@diameter.org Subject: [mobile-ip] Re: [seamoby-context] New Internet Draft on proactive mobility over Mobile IPv6 References: <35DBB8B7AC89D4118E98009027B1009B017A9E86@IL27EXM10.cig.mot.com> Content-Type: multipart/alternative; boundary="------------AE337E9F71088DBE75784F69" 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: --------------AE337E9F71088DBE75784F69 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Madjid, Strange since it worked for me in my unix box in the US. Anyway, it should also be reachable by accessing: http://www.cs.ucl.ac.uk/staff/t.pagtzis/ then select the Docs section and from that select the draft either ASCII or Postscript version. Cheers Theo UCL/Mobile Systems Nakhjiri Madjid-MNAKHJI1 wrote: > Theo, > > your link doesn't work. > > Madjid > > -----Original Message----- > From: Theo Pagtzis [mailto:tpagtzis@cs.ucl.ac.uk] > Sent: Wednesday, July 11, 2001 2:56 PM > To: seamoby-context@cdma-2000.org > Subject: [seamoby-context] New Internet Draft on proactive mobility over > Mobile IPv6 > > Hi all, > > here is the link for our draft specification submitted yesterday to > the Internet drafts management group of IETF. > > The draft specification is mainly targeting the MobileIP group, but it > bears great relevance to the Seamoby group and in particular the context > transfer design team. > > The draft comprizes of two documents due to the complexity of schematics > and a formulae that accompany the design specified. For this reason the > reader is invited to read the ascii version but consult the postscript > version for schematics and formulae. > > The postscript version is self contained while we are striving towards > making the ASCII version a stand alone document with its own text art > schematics and formulae. > > Both ASCII and Postscript version of the draft can be found at > > http://www.cs.ucl.ac.uk/staff/t.pagtzis/docs/docs.html > > with details as follows: > > Title : A Framework for Proactive Mobility in Mobile IPv6. > Author(s) : Theo Pagtzis and Peter Kirstein > Filename : draft-pagtzis-mobileip-proactivev6-00.txt/.ps > Pages : 78 (ASCII), 81 (postscript) > Date : 10-Jul-01 > > Any comments would be highly appreciated. > > Many Thanks > > Theo > > UCL/Mobile Systems --------------AE337E9F71088DBE75784F69 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Madjid,

    Strange since it worked for me in my unix box in the US.

Anyway, it should also be reachable by accessing:

http://www.cs.ucl.ac.uk/staff/t.pagtzis/
 

then select the Docs section

and from that select the draft either ASCII or Postscript version.
 

Cheers
 

Theo

UCL/Mobile Systems
 

Nakhjiri Madjid-MNAKHJI1 wrote:

Theo,

your link doesn't work.

Madjid

-----Original Message-----
From: Theo Pagtzis [mailto:tpagtzis@cs.ucl.ac.uk]
Sent: Wednesday, July 11, 2001 2:56 PM
To: seamoby-context@cdma-2000.org
Subject: [seamoby-context] New Internet Draft on proactive mobility over
Mobile IPv6

Hi all,

   here is the link for our draft specification submitted yesterday to
the Internet drafts management group of IETF.

The draft specification is mainly targeting the MobileIP group, but it
bears great relevance to the Seamoby group and in particular the context
transfer design team.

The draft comprizes of two documents due to the complexity of schematics
and a formulae that accompany the design specified. For this reason the
reader is invited to read the ascii version but consult the postscript
version for schematics and formulae.

The postscript version is self contained while we are striving towards
making the ASCII version a stand alone document with its own text art
schematics and formulae.

Both ASCII and Postscript version of the draft can be found at

http://www.cs.ucl.ac.uk/staff/t.pagtzis/docs/docs.html

with details as follows:

        Title     :  A Framework for Proactive Mobility in Mobile IPv6.
        Author(s) :  Theo Pagtzis and Peter Kirstein
        Filename  :  draft-pagtzis-mobileip-proactivev6-00.txt/.ps
        Pages     :  78 (ASCII), 81 (postscript)
        Date      :  10-Jul-01

Any comments would be highly appreciated.

Many Thanks

Theo

UCL/Mobile Systems

--------------AE337E9F71088DBE75784F69-- From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 11 20:04:16 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA25503 for ; Wed, 11 Jul 2001 20:04:15 -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 SAA00174; Wed, 11 Jul 2001 18:04: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 RAA10892; Wed, 11 Jul 2001 17:03:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6C02pk09444 for mobile-ip-dist; Wed, 11 Jul 2001 17:02:51 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.83.130] (may be forged)) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6C02kN09437 for ; Wed, 11 Jul 2001 17:02:47 -0700 (PDT) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by jurassic.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with SMTP id f6C02mr541640; Wed, 11 Jul 2001 17:02:48 -0700 (PDT) Message-Id: <200107120002.f6C02mr541640@jurassic.eng.sun.com> Date: Wed, 11 Jul 2001 20:03:21 -0400 (EDT) From: Steven Glass - Solaris Software Subject: Re: [mobile-ip] Registration revocation issues To: mobile-ip@sunroof.eng.sun.com Cc: Pat Calhoun X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5_11 SunOS 5.8.1 sun4u sparc Content-Type: text X-Sun-Text-Type: 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, Jul 11, 2001 at 07:21:29PM -0400, Steven Glass - Solaris Software wrote: >> I'm just about done updating the revocation draft, and I have a few >> questions to ask the group: >> >> 1) How do people feel about an "I understand revocations" registration >> extension? >To which pcalhoun@diameter.org sez: > >I prefer this than simply assuming it does. ... >The way I see it, I see no reason to send a new message type to an FA that >may not recognize it. Chances are that an implementation will simply drop the >message, causing the HA to retransmit, and eventually give up. > >If an FA advertises itself as supporting this extension, then you know that >lack of response means that FA is really not reachable. The idea is a revocation is sent only once (or twice for the fixated), and a response is sent (with a swapped ID and new authenticator) back to the revoker. I see your point, though, how do you tell between someone who doesn't understand, and someone who's already not listening (for whatever reason)? A good argument to have it in. >Further, revocations MUST NOT be sent upon a binding expiration, right? It's >only sent if a binding is revoked prior to lifetime expiration. True. >> 2) I'm removing the lifetime field. ... >lifetimes are out, IMHO. A revocation means the session is terminated. If the >MN wants to renew service, it can send a new registration request. Agreed. Cheers, Steve From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 12 07:08:25 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA02110 for ; Thu, 12 Jul 2001 07:08:24 -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 EAA28159; Thu, 12 Jul 2001 04:08: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 EAA07266; Thu, 12 Jul 2001 04:07:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6CB5js10505 for mobile-ip-dist; Thu, 12 Jul 2001 04:05:45 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6CB5fN10498 for ; Thu, 12 Jul 2001 04:05:41 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA21966 for ; Thu, 12 Jul 2001 04:05:50 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA29038 for ; Thu, 12 Jul 2001 04:05:50 -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 HAA01268; Thu, 12 Jul 2001 07:04:59 -0400 (EDT) Message-Id: <200107121104.HAA01268@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: mobile-ip@sunroof.eng.sun.com, seamoby@cdma-2000.org From: Internet-Drafts@ietf.org Subject: [mobile-ip] I-D ACTION:draft-pagtzis-mobileip-proactivev6-00.txt,.ps Date: Thu, 12 Jul 2001 07:04:59 -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. Title : A Framework for Proactive Mobility in Mobile IPv6 Author(s) : T. Pagtzis, P. Kirstein Filename : draft-pagtzis-mobileip-proactivev6-00.txt,.ps Pages : 78 Date : 11-Jul-01 This document specifies a scheme to provide support for proactive mobility for IPv6. It encompasses a novel approach for seamless handoff and proactive roaming context transfer. The latter establishes a generic method for proactive context transfer and manipulation of different classes of context relating to the state of IP connectivity for a mobile node. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-pagtzis-mobileip-proactivev6-00.txt 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-pagtzis-mobileip-proactivev6-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-pagtzis-mobileip-proactivev6-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: <20010711155549.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-pagtzis-mobileip-proactivev6-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-pagtzis-mobileip-proactivev6-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010711155549.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 12 07:08:29 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA02132 for ; Thu, 12 Jul 2001 07:08:28 -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 EAA28257; Thu, 12 Jul 2001 04:08:29 -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 EAA07282; Thu, 12 Jul 2001 04:08:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6CB6Kw10514 for mobile-ip-dist; Thu, 12 Jul 2001 04:06:20 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6CB69N10507 for ; Thu, 12 Jul 2001 04:06:11 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA21990 for ; Thu, 12 Jul 2001 04:06:17 -0700 (PDT) Received: from mail.lge.com ([156.147.1.150]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA08141 for ; Thu, 12 Jul 2001 04:06:15 -0700 (PDT) Received: from lgekrhqmh01.lge.com ([156.147.51.51]) by mail.lge.com (8.8.4_hhk9703/8.6.9) with ESMTP id UAA03972 for ; Thu, 12 Jul 2001 20:03:09 +0900 (KST) Received: from aeb099w ([150.150.60.99]) by lgekrhqmh01.lge.com (Lotus Domino Release 5.07a) with SMTP id 2001071220060627:216788 ; Thu, 12 Jul 2001 20:06:06 +0900 Message-ID: <00a101c10ac1$f45fced0$633c9696@aeb099w> From: =?ks_c_5601-1987?B?sejFwr/r?= To: Subject: [mobile-ip] How to learn the path that Mobile-IP packet take through the Internet Date: Thu, 12 Jul 2001 20:01:08 +0900 MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-MIMETrack: Itemize by SMTP Server on LGEKRHQMH01/LGE/LG Group(Release 5.07a |May 14, 2001) at 07/12/2001 08:06:06 PM, Serialize by Router on LGEKRHQMH01/LGE/LG Group(Release 5.07a |May 14, 2001) at 07/12/2001 08:06:07 PM, Serialize complete at 07/12/2001 08:06:07 PM Content-Type: multipart/alternative; boundary="----=_NextPart_000_009E_01C10B0D.6433A0B0" 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_009E_01C10B0D.6433A0B0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SGVsbG8uDQoNCkFzc3VtZSBmb2xsb3dpbmcgc2l0dWF0aW9uLg0KDQpleCkNCm5vZGUgQSAtLS0t IEZBIC0tLS0tIEhBIC0tLS0tLSBub2RlIEINCg0Kbm9kZSBCIHNlbmQgdGhlIHBhY2tldCB0byBu b2RlIEEuIFRoZW4gSEEgaW50ZXJjZXB0IHRoZSBwYWNrZXQgYW5kIGVuY2Fwc3VsYXRlIGl0Lg0K U2VuZCBlbmNhcHN1bGF0ZWQgcGFja2V0IHRvIEZBIHRocm91Z2ggRkEtSEEgdHVubmVsLg0KZmlu YWxseSBGQSBzZW5kIGRlY2Fwc3VsYXRlZCBwYWNrZXQgdG8gbm9kZSBBLg0KDQpNeSBxdWVzdGlv biBpcyAiSXMgaXQgcG9zc2libGUgdGhhdCBub2RlIEIga25vdyB3aG9sZSBwYXRoIGJldHdlZW4g bm9kZSBBIGFuZCBub2RlIEI/Ii4NCg0KDQpJIHRoaW5rIHRoZXJlIGlzIGFkZGl0aW9uYWwgZmVh dHVyZSB0byBhZGQgdGhlIHRyYWNlcm91dGUgaW5mb3JtYXRpb24gdG8gb3JpZ2luYWwgcGFja2V0 IGJ5IEZBIGFuZCBIQS4NCg0KDQoNCg0K ------=_NextPart_000_009E_01C10B0D.6433A0B0 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWtz X2NfNTYwMS0xOTg3IiBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZT4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA1LjAwLjI5MjAuMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVB RD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPg0KPERJVj48Rk9O VCBzaXplPTI+SGVsbG8uPC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZP TlQgc2l6ZT0yPkFzc3VtZSBmb2xsb3dpbmcgc2l0dWF0aW9uLjwvRk9OVD48L0RJVj4NCjxESVY+ Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5leCk8L0ZPTlQ+PC9ESVY+DQo8RElWPjxG T05UIHNpemU9Mj5ub2RlIEEgLS0tLSBGQSAtLS0tLSBIQSAtLS0tLS0gbm9kZSBCPC9GT05UPjwv RElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPm5vZGUgQiBzZW5kIHRo ZSBwYWNrZXQgdG8gbm9kZSBBLiBUaGVuIEhBIGludGVyY2VwdCB0aGUgcGFja2V0IA0KYW5kIGVu Y2Fwc3VsYXRlIGl0LjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPlNlbmQmbmJzcDtl bmNhcHN1bGF0ZWQgcGFja2V0IHRvIEZBIHRocm91Z2ggRkEtSEEgDQp0dW5uZWwuPC9GT05UPjwv RElWPg0KPERJVj48Rk9OVCBzaXplPTI+ZmluYWxseSBGQSBzZW5kIGRlY2Fwc3VsYXRlZCBwYWNr ZXQgdG8gbm9kZSBBLjwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05U IHNpemU9Mj5NeSBxdWVzdGlvbiBpcyAiSXMgaXQgcG9zc2libGUgdGhhdCBub2RlIEIga25vdyB3 aG9sZSBwYXRoIA0KYmV0d2VlbiBub2RlIEEgYW5kIG5vZGUgQj8iLjwvRk9OVD48L0RJVj4NCjxE SVY+Jm5ic3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+SSB0 aGluayB0aGVyZSBpcyBhZGRpdGlvbmFsIGZlYXR1cmUgdG8mbmJzcDthZGQgdGhlIHRyYWNlcm91 dGUgDQppbmZvcm1hdGlvbiB0byBvcmlnaW5hbCBwYWNrZXQgYnkgRkEgYW5kIEhBLjwvRk9OVD48 L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDs8 L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+PC9GT05UPjwvRElWPjwvQk9EWT48L0hUTUw+DQo= ------=_NextPart_000_009E_01C10B0D.6433A0B0-- From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 12 07:19:56 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA03555 for ; Thu, 12 Jul 2001 07:19:55 -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 EAA00863; Thu, 12 Jul 2001 04:19: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 EAA19937; Thu, 12 Jul 2001 04:19:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6CBITZ10602 for mobile-ip-dist; Thu, 12 Jul 2001 04:18:29 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6CBIPN10595 for ; Thu, 12 Jul 2001 04:18:26 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA07799 for ; Thu, 12 Jul 2001 04:18:35 -0700 (PDT) Received: from mail.lge.com ([156.147.1.150]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA02784 for ; Thu, 12 Jul 2001 04:18:34 -0700 (PDT) Received: from lgekrhqmh01.lge.com ([156.147.51.51]) by mail.lge.com (8.8.4_hhk9703/8.6.9) with ESMTP id UAA05621 for ; Thu, 12 Jul 2001 20:15:28 +0900 (KST) Received: from aeb099w ([150.150.60.99]) by lgekrhqmh01.lge.com (Lotus Domino Release 5.07a) with SMTP id 2001071220182655:219143 ; Thu, 12 Jul 2001 20:18:26 +0900 Message-ID: <00c701c10ac3$ad62ac30$633c9696@aeb099w> From: =?ks_c_5601-1987?B?sejFwr/r?= To: References: <00a101c10ac1$f45fced0$633c9696@aeb099w> Subject: Re: [mobile-ip] How to learn the path that Mobile-IP packet take through theInternet Date: Thu, 12 Jul 2001 20:13:28 +0900 MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-MIMETrack: Itemize by SMTP Server on LGEKRHQMH01/LGE/LG Group(Release 5.07a |May 14, 2001) at 07/12/2001 08:18:26 PM, Serialize by Router on LGEKRHQMH01/LGE/LG Group(Release 5.07a |May 14, 2001) at 07/12/2001 08:18:27 PM, Serialize complete at 07/12/2001 08:18:27 PM Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C4_01C10B0F.1D396440" 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_00C4_01C10B0F.1D396440 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 vsiz58fPvLy/5C4NCr/svLEgvsa3oSCx28C7IMDQvu66uL3Dsbi/5C4uyKS9wyCx4sG4wMcguea5 /cDMIMDWtNm46SCwobijw8Qgwda8vL/kLg0KDQq89rDtx8+8vL/kLg0KICAtLS0tLSBPcmlnaW5h bCBNZXNzYWdlIC0tLS0tIA0KICBGcm9tOiCx6MXCv+sgOyBvd25lci1tb2JpbGUtaXBAc3Vucm9v Zi5lbmcuc3VuLmNvbSANCiAgVG86IG1vYmlsZS1pcEBzdW5yb29mLmVuZy5zdW4uY29tIA0KICBT ZW50OiBUaHVyc2RheSwgSnVseSAxMiwgMjAwMSA4OjAxIFBNDQogIFN1YmplY3Q6IFttb2JpbGUt aXBdIEhvdyB0byBsZWFybiB0aGUgcGF0aCB0aGF0IE1vYmlsZS1JUCBwYWNrZXQgdGFrZSB0aHJv dWdoIHRoZUludGVybmV0DQoNCg0KICBIZWxsby4NCg0KICBBc3N1bWUgZm9sbG93aW5nIHNpdHVh dGlvbi4NCg0KICBleCkNCiAgbm9kZSBBIC0tLS0gRkEgLS0tLS0gSEEgLS0tLS0tIG5vZGUgQg0K DQogIG5vZGUgQiBzZW5kIHRoZSBwYWNrZXQgdG8gbm9kZSBBLiBUaGVuIEhBIGludGVyY2VwdCB0 aGUgcGFja2V0IGFuZCBlbmNhcHN1bGF0ZSBpdC4NCiAgU2VuZCBlbmNhcHN1bGF0ZWQgcGFja2V0 IHRvIEZBIHRocm91Z2ggRkEtSEEgdHVubmVsLg0KICBmaW5hbGx5IEZBIHNlbmQgZGVjYXBzdWxh dGVkIHBhY2tldCB0byBub2RlIEEuDQoNCiAgTXkgcXVlc3Rpb24gaXMgIklzIGl0IHBvc3NpYmxl IHRoYXQgbm9kZSBCIGtub3cgd2hvbGUgcGF0aCBiZXR3ZWVuIG5vZGUgQSBhbmQgbm9kZSBCPyIu DQoNCg0KICBJIHRoaW5rIHRoZXJlIGlzIGFkZGl0aW9uYWwgZmVhdHVyZSB0byBhZGQgdGhlIHRy YWNlcm91dGUgaW5mb3JtYXRpb24gdG8gb3JpZ2luYWwgcGFja2V0IGJ5IEZBIGFuZCBIQS4NCg0K DQoNCg0K ------=_NextPart_000_00C4_01C10B0F.1D396440 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWtz X2NfNTYwMS0xOTg3IiBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZT4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA1LjAwLjI5MjAuMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVB RD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPr7Is+fHz7y8v+Qu PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+v+y8sSC+xrehILHbwLsgwNC+7rq4vcOx uL/kLi7IpL3DILHiwbjAxyC55rn9wMwgwNa02bjpILChuKPDxCDB1ry8v+QuPC9GT05UPjwvRElW Pg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPrz2sO3Hz7y8v+QuPC9GT05U PjwvRElWPg0KPEJMT0NLUVVPVEUgDQpzdHlsZT0iQk9SREVSLUxFRlQ6ICMwMDAwMDAgMnB4IHNv bGlkOyBNQVJHSU4tTEVGVDogNXB4OyBNQVJHSU4tUklHSFQ6IDBweDsgUEFERElORy1MRUZUOiA1 cHg7IFBBRERJTkctUklHSFQ6IDBweCI+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDEwcHQgsby4siI+ LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSA8L0RJVj4NCiAgPERJViANCiAgc3R5bGU9IkJB Q0tHUk9VTkQ6ICNlNGU0ZTQ7IEZPTlQ6IDEwcHQgsby4sjsgZm9udC1jb2xvcjogYmxhY2siPjxC PkZyb206PC9CPiA8QSANCiAgaHJlZj0ibWFpbHRvOmplYWltZXR1QGxnZS5jb20iIHRpdGxlPWpl YWltZXR1QGxnZS5jb20+sejFwr/rPC9BPiA7IDxBIA0KICBocmVmPSJtYWlsdG86b3duZXItbW9i aWxlLWlwQHN1bnJvb2YuZW5nLnN1bi5jb20iIA0KICB0aXRsZT1vd25lci1tb2JpbGUtaXBAc3Vu cm9vZi5lbmcuc3VuLmNvbT5vd25lci1tb2JpbGUtaXBAc3Vucm9vZi5lbmcuc3VuLmNvbTwvQT4g DQogIDwvRElWPg0KICA8RElWIHN0eWxlPSJGT05UOiAxMHB0ILG8uLIiPjxCPlRvOjwvQj4gPEEg DQogIGhyZWY9Im1haWx0bzptb2JpbGUtaXBAc3Vucm9vZi5lbmcuc3VuLmNvbSIgDQogIHRpdGxl PW1vYmlsZS1pcEBzdW5yb29mLmVuZy5zdW4uY29tPm1vYmlsZS1pcEBzdW5yb29mLmVuZy5zdW4u Y29tPC9BPiA8L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDogMTBwdCCxvLiyIj48Qj5TZW50Ojwv Qj4gVGh1cnNkYXksIEp1bHkgMTIsIDIwMDEgODowMSBQTTwvRElWPg0KICA8RElWIHN0eWxlPSJG T05UOiAxMHB0ILG8uLIiPjxCPlN1YmplY3Q6PC9CPiBbbW9iaWxlLWlwXSBIb3cgdG8gbGVhcm4g dGhlIHBhdGggDQogIHRoYXQgTW9iaWxlLUlQIHBhY2tldCB0YWtlIHRocm91Z2ggdGhlSW50ZXJu ZXQ8L0RJVj4NCiAgPERJVj48QlI+PC9ESVY+DQogIDxESVY+PEZPTlQgc2l6ZT0yPg0KICA8RElW PjxGT05UIHNpemU9Mj5IZWxsby48L0ZPTlQ+PC9ESVY+DQogIDxESVY+Jm5ic3A7PC9ESVY+DQog IDxESVY+PEZPTlQgc2l6ZT0yPkFzc3VtZSBmb2xsb3dpbmcgc2l0dWF0aW9uLjwvRk9OVD48L0RJ Vj4NCiAgPERJVj4mbmJzcDs8L0RJVj4NCiAgPERJVj48Rk9OVCBzaXplPTI+ZXgpPC9GT05UPjwv RElWPg0KICA8RElWPjxGT05UIHNpemU9Mj5ub2RlIEEgLS0tLSBGQSAtLS0tLSBIQSAtLS0tLS0g bm9kZSBCPC9GT05UPjwvRElWPg0KICA8RElWPiZuYnNwOzwvRElWPg0KICA8RElWPjxGT05UIHNp emU9Mj5ub2RlIEIgc2VuZCB0aGUgcGFja2V0IHRvIG5vZGUgQS4gVGhlbiBIQSBpbnRlcmNlcHQg dGhlIA0KICBwYWNrZXQgYW5kIGVuY2Fwc3VsYXRlIGl0LjwvRk9OVD48L0RJVj4NCiAgPERJVj48 Rk9OVCBzaXplPTI+U2VuZCZuYnNwO2VuY2Fwc3VsYXRlZCBwYWNrZXQgdG8gRkEgdGhyb3VnaCBG QS1IQSANCiAgdHVubmVsLjwvRk9OVD48L0RJVj4NCiAgPERJVj48Rk9OVCBzaXplPTI+ZmluYWxs eSBGQSBzZW5kIGRlY2Fwc3VsYXRlZCBwYWNrZXQgdG8gbm9kZSBBLjwvRk9OVD48L0RJVj4NCiAg PERJVj4mbmJzcDs8L0RJVj4NCiAgPERJVj48Rk9OVCBzaXplPTI+TXkgcXVlc3Rpb24gaXMgIklz IGl0IHBvc3NpYmxlIHRoYXQgbm9kZSBCIGtub3cgd2hvbGUgcGF0aCANCiAgYmV0d2VlbiBub2Rl IEEgYW5kIG5vZGUgQj8iLjwvRk9OVD48L0RJVj4NCiAgPERJVj4mbmJzcDs8L0RJVj4NCiAgPERJ Vj4mbmJzcDs8L0RJVj4NCiAgPERJVj48Rk9OVCBzaXplPTI+SSB0aGluayB0aGVyZSBpcyBhZGRp dGlvbmFsIGZlYXR1cmUgdG8mbmJzcDthZGQgdGhlIA0KICB0cmFjZXJvdXRlIGluZm9ybWF0aW9u IHRvIG9yaWdpbmFsIHBhY2tldCBieSBGQSBhbmQgSEEuPC9GT05UPjwvRElWPg0KICA8RElWPiZu YnNwOzwvRElWPg0KICA8RElWPiZuYnNwOzwvRElWPg0KICA8RElWPiZuYnNwOzwvRElWPg0KICA8 RElWPiZuYnNwOzwvRElWPjwvRk9OVD48L0RJVj48L0JMT0NLUVVPVEU+PC9CT0RZPjwvSFRNTD4N Cg== ------=_NextPart_000_00C4_01C10B0F.1D396440-- From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 12 08:24:23 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA11503 for ; Thu, 12 Jul 2001 08:24:22 -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 GAA00182; Thu, 12 Jul 2001 06:24:03 -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 FAA27079; Thu, 12 Jul 2001 05:23:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6CCMLL10718 for mobile-ip-dist; Thu, 12 Jul 2001 05:22:21 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6CCMIN10711 for ; Thu, 12 Jul 2001 05:22:18 -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 FAA26994 for ; Thu, 12 Jul 2001 05:22:28 -0700 (PDT) Received: from tiger.korea.ac.kr (tiger.korea.ac.kr [163.152.209.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA10919 for ; Thu, 12 Jul 2001 06:23:36 -0600 (MDT) Received: from nnt ([163.152.155.225]) by tiger.korea.ac.kr (8.11.0/8.11.0) with SMTP id f6CCJHZ22316 for ; Thu, 12 Jul 2001 21:19:17 +0900 Message-ID: <002c01c10acd$d212b7a0$e19b98a3@nnt> From: =?ks_c_5601-1987?B?waTB+L/s?= To: References: <00a101c10ac1$f45fced0$633c9696@aeb099w> <00c701c10ac3$ad62ac30$633c9696@aeb099w> Subject: Re: [mobile-ip] How to learn the path that Mobile-IP packet take through theInternet Date: Thu, 12 Jul 2001 21:26:04 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0029_01C10B19.41CFA620" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.3018.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 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_0029_01C10B19.41CFA620 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 vsiz58fPvLy/5C4NCg0KwaawoSC+y7DtIMDWseK3zrTCILHiwbjAxyB0cmFjZXJvdXRlILimIMXr x9i8rSC+yyC89iDA1sC7sM3AzLbzILv9sKK1y7TPtNkuDQoNCnRyYWNlcm91dGUgx8G3zrHXt6XA uiC48cD7wfax7sH2ILW1tN7H0ranILHuwfYgVFRMILCqwLsgwfWwoSC9w8WwuOm8rQ0KDQpJQ01Q ICC/wLf5ILjevcPB9rimIMXrx9i8rSDB37CjILPrteW16cDHIMGkuri4piC+8r7uIL/AtMIgsM3A uLfOIL7LsO0gwNbAvrTPtNkuDQoNCrX7tvO8rSwgDQoNCk1vYmlsZSBJUCCz18auv/bFqSC787+h vK0gs+u15SBCILChIHRyYWNlcm91dGUgx8G3zrHXt6XAuyC757/rx8+09bbztbUgDQoNCiAgICDF zbPOuLUgsbiwo7+hvK3AxyBJQ01QILjevcPB9rTCIG9yaWdpbmF0b3Igv6Gw1CDA/LTetcew1CC1 x77uIMDWwL60z7TZLiAoUkZDIDIwMDMsICJJUC13aXRoaW4tSVAiKQ0KDQqw4bG5LCCx4sG4wMcg uea5/bD6ILW/wM/Hz7DUILjxwPvB9iCx7sH2wMcgsOa3zrimIL7LvPYgwNbAuLiutvMgu/2worXL tM+02S4NCg0KwaawoSDB+rmuwLsgwaa067fOIMDMx9jHz7DtLCC05LqvwLsgteW4sLDHwfYuLi4N Cg0Kvu7Ct7XnILW1v/LAzCC1x776wLi46SDBwbDasbq/5C4NCg0KDQpQLlMgKSDIpL3DIMH6ua7H z73DtMIgus660MDMIElQdjTAxyBPcHRpb24gwLsgu+e/68fRILDmt84gsMvD4iC55rn9wLsNCg0K ICAgICAgICAguLu+uCDHz73DtMIgsMewob/kPyAgKFJGQyAxMzkzIG9yIExTUlIpDQogDQoNCg0K DQoNCiAgLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCiAgRnJvbTogsejFwr/rIA0KICBU bzogbW9iaWxlLWlwQHN1bnJvb2YuZW5nLnN1bi5jb20gDQogIFNlbnQ6IFRodXJzZGF5LCBKdWx5 IDEyLCAyMDAxIDg6MTMgUE0NCiAgU3ViamVjdDogUmU6IFttb2JpbGUtaXBdIEhvdyB0byBsZWFy biB0aGUgcGF0aCB0aGF0IE1vYmlsZS1JUCBwYWNrZXQgdGFrZSB0aHJvdWdoIHRoZUludGVybmV0 DQoNCg0KICC+yLPnx8+8vL/kLg0KICC/7LyxIL7Gt6EgsdvAuyDA0L7uuri9w7G4v+QuLsikvcMg seLBuMDHILnmuf3AzCDA1rTZuOkgsKG4o8PEIMHWvLy/5C4NCg0KICC89rDtx8+8vL/kLg0KICAg IC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQogICAgRnJvbTogsejFwr/rIDsgb3duZXIt bW9iaWxlLWlwQHN1bnJvb2YuZW5nLnN1bi5jb20gDQogICAgVG86IG1vYmlsZS1pcEBzdW5yb29m LmVuZy5zdW4uY29tIA0KICAgIFNlbnQ6IFRodXJzZGF5LCBKdWx5IDEyLCAyMDAxIDg6MDEgUE0N CiAgICBTdWJqZWN0OiBbbW9iaWxlLWlwXSBIb3cgdG8gbGVhcm4gdGhlIHBhdGggdGhhdCBNb2Jp bGUtSVAgcGFja2V0IHRha2UgdGhyb3VnaCB0aGVJbnRlcm5ldA0KDQoNCiAgICBIZWxsby4NCg0K ICAgIEFzc3VtZSBmb2xsb3dpbmcgc2l0dWF0aW9uLg0KDQogICAgZXgpDQogICAgbm9kZSBBIC0t LS0gRkEgLS0tLS0gSEEgLS0tLS0tIG5vZGUgQg0KDQogICAgbm9kZSBCIHNlbmQgdGhlIHBhY2tl dCB0byBub2RlIEEuIFRoZW4gSEEgaW50ZXJjZXB0IHRoZSBwYWNrZXQgYW5kIGVuY2Fwc3VsYXRl IGl0Lg0KICAgIFNlbmQgZW5jYXBzdWxhdGVkIHBhY2tldCB0byBGQSB0aHJvdWdoIEZBLUhBIHR1 bm5lbC4NCiAgICBmaW5hbGx5IEZBIHNlbmQgZGVjYXBzdWxhdGVkIHBhY2tldCB0byBub2RlIEEu DQoNCiAgICBNeSBxdWVzdGlvbiBpcyAiSXMgaXQgcG9zc2libGUgdGhhdCBub2RlIEIga25vdyB3 aG9sZSBwYXRoIGJldHdlZW4gbm9kZSBBIGFuZCBub2RlIEI/Ii4NCg0KDQogICAgSSB0aGluayB0 aGVyZSBpcyBhZGRpdGlvbmFsIGZlYXR1cmUgdG8gYWRkIHRoZSB0cmFjZXJvdXRlIGluZm9ybWF0 aW9uIHRvIG9yaWdpbmFsIHBhY2tldCBieSBGQSBhbmQgSEEuDQoNCg0KDQoNCg== ------=_NextPart_000_0029_01C10B19.41CFA620 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWtz X2NfNTYwMS0xOTg3IiBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZT4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA1LjAwLjMwMTguOTAwIiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT48L1NUWUxFPg0KPC9I RUFEPg0KPEJPRFkgYmdDb2xvcj0jZmZmZmZmPg0KPERJVj48Rk9OVCBzaXplPTI+vsiz58fPvLy/ 5C48L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+waaw oSC+y7DtIMDWseK3zrTCILHiwbjAxyB0cmFjZXJvdXRlILimIMXrx9i8rSC+yyC89iDA1sC7sM3A zLbzILv9sKK1y7TPtNkuPC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZP TlQgc2l6ZT0yPnRyYWNlcm91dGUgx8G3zrHXt6XAuiC48cD7wfax7sH2ILW1tN7H0ranILHuwfYg VFRMILCqwLsgwfWwoSC9w8WwuOm8rTwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8 RElWPjxGT05UIHNpemU9Mj5JQ01QJm5ic3A7IL/At/kguN69w8H2uKYgxevH2LytIMHfsKMgs+u1 5bXpwMcgwaS6uLimIL7yvu4gv8C0wiCwzcC4t84gvsuw7SANCsDWwL60z7TZLjwvRk9OVD48L0RJ Vj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj61+7bzvK0sIDwvRk9OVD48 L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQg c2l6ZT0yPk1vYmlsZSBJUCCz18auv/bFqSC787+hvK0gs+u15SBCILChIHRyYWNlcm91dGUgx8G3 zrHXt6XAuyC757/rx8+09bbztbUgDQo8L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0K PERJVj48Rk9OVCBzaXplPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IMXNs864tSCxuLCjv6G8rcDHIElD TVAguN69w8H2tMIgb3JpZ2luYXRvciC/obDUIMD8tN61x7DUILXHvu4gDQrA1sC+tM+02S4mbmJz cDs8L0ZPTlQ+PEZPTlQgc2l6ZT0yPihSRkMgMjAwMywgIklQLXdpdGhpbi1JUCIpPC9GT05UPjwv RElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPrDhsbksILHiwbjAxyC5 5rn9sPogtb/Az8fPsNQguPHA+8H2ILHuwfbAxyCw5rfOuKYgvsu89iDA1sC4uK628yC7/bCitcu0 z7TZLjwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj7B prChIMH6ua7AuyDBprTrt84gwMzH2MfPsO0sILTkuq/AuyC15biwsMfB9i4uLjwvRk9OVD48L0RJ Vj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj6+7sK3tecgtbW/8sDMILXH vvrAuLjpIMHBsNqxur/kLjwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPiZu YnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+UC5TICkgyKS9wyDB+rmux8+9w7TCILrOutDA zCBJUHY0wMcgT3B0aW9uIMC7ILvnv+vH0SCw5rfOILDLw+Iguea5/cC7PC9GT05UPjwvRElWPg0K PERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO7i7vrggx8+9w7TCIA0KsMewob/kPyZu YnNwOyAoUkZDIDEzOTMgb3IgTFNSUik8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj4m bmJzcDs8L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4N CjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPEJMT0NLUVVPVEUgDQpzdHls ZT0iQk9SREVSLUxFRlQ6ICMwMDAwMDAgMnB4IHNvbGlkOyBNQVJHSU4tTEVGVDogNXB4OyBNQVJH SU4tUklHSFQ6IDBweDsgUEFERElORy1MRUZUOiA1cHg7IFBBRERJTkctUklHSFQ6IDBweCI+DQog IDxESVYgc3R5bGU9IkZPTlQ6IDEwcHQgsby4siI+LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0t LSA8L0RJVj4NCiAgPERJViANCiAgc3R5bGU9IkJBQ0tHUk9VTkQ6ICNlNGU0ZTQ7IEZPTlQ6IDEw cHQgsby4sjsgZm9udC1jb2xvcjogYmxhY2siPjxCPkZyb206PC9CPiA8QSANCiAgaHJlZj0ibWFp bHRvOmplYWltZXR1QGxnZS5jb20iIHRpdGxlPWplYWltZXR1QGxnZS5jb20+sejFwr/rPC9BPiA8 L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDogMTBwdCCxvLiyIj48Qj5Ubzo8L0I+IDxBIA0KICBo cmVmPSJtYWlsdG86bW9iaWxlLWlwQHN1bnJvb2YuZW5nLnN1bi5jb20iIA0KICB0aXRsZT1tb2Jp bGUtaXBAc3Vucm9vZi5lbmcuc3VuLmNvbT5tb2JpbGUtaXBAc3Vucm9vZi5lbmcuc3VuLmNvbTwv QT4gPC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDEwcHQgsby4siI+PEI+U2VudDo8L0I+IFRo dXJzZGF5LCBKdWx5IDEyLCAyMDAxIDg6MTMgUE08L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDog MTBwdCCxvLiyIj48Qj5TdWJqZWN0OjwvQj4gUmU6IFttb2JpbGUtaXBdIEhvdyB0byBsZWFybiB0 aGUgDQogIHBhdGggdGhhdCBNb2JpbGUtSVAgcGFja2V0IHRha2UgdGhyb3VnaCB0aGVJbnRlcm5l dDwvRElWPg0KICA8RElWPjxCUj48L0RJVj4NCiAgPERJVj48Rk9OVCBzaXplPTI+vsiz58fPvLy/ 5C48L0ZPTlQ+PC9ESVY+DQogIDxESVY+PEZPTlQgc2l6ZT0yPr/svLEgvsa3oSCx28C7IMDQvu66 uL3Dsbi/5C4uyKS9wyCx4sG4wMcguea5/cDMIMDWtNm46SCwobijw8Qgwda8vL/kLjwvRk9OVD48 L0RJVj4NCiAgPERJVj4mbmJzcDs8L0RJVj4NCiAgPERJVj48Rk9OVCBzaXplPTI+vPaw7cfPvLy/ 5C48L0ZPTlQ+PC9ESVY+DQogIDxCTE9DS1FVT1RFIA0KICBzdHlsZT0iQk9SREVSLUxFRlQ6ICMw MDAwMDAgMnB4IHNvbGlkOyBNQVJHSU4tTEVGVDogNXB4OyBNQVJHSU4tUklHSFQ6IDBweDsgUEFE RElORy1MRUZUOiA1cHg7IFBBRERJTkctUklHSFQ6IDBweCI+DQogICAgPERJViBzdHlsZT0iRk9O VDogMTBwdCCxvLiyIj4tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIDwvRElWPg0KICAgIDxE SVYgDQogICAgc3R5bGU9IkJBQ0tHUk9VTkQ6ICNlNGU0ZTQ7IEZPTlQ6IDEwcHQgsby4sjsgZm9u dC1jb2xvcjogYmxhY2siPjxCPkZyb206PC9CPiANCiAgICA8QSBocmVmPSJtYWlsdG86amVhaW1l dHVAbGdlLmNvbSIgdGl0bGU9amVhaW1ldHVAbGdlLmNvbT6x6MXCv+s8L0E+IDsgPEEgDQogICAg aHJlZj0ibWFpbHRvOm93bmVyLW1vYmlsZS1pcEBzdW5yb29mLmVuZy5zdW4uY29tIiANCiAgICB0 aXRsZT1vd25lci1tb2JpbGUtaXBAc3Vucm9vZi5lbmcuc3VuLmNvbT5vd25lci1tb2JpbGUtaXBA c3Vucm9vZi5lbmcuc3VuLmNvbTwvQT4gDQogICAgPC9ESVY+DQogICAgPERJViBzdHlsZT0iRk9O VDogMTBwdCCxvLiyIj48Qj5Ubzo8L0I+IDxBIA0KICAgIGhyZWY9Im1haWx0bzptb2JpbGUtaXBA c3Vucm9vZi5lbmcuc3VuLmNvbSIgDQogICAgdGl0bGU9bW9iaWxlLWlwQHN1bnJvb2YuZW5nLnN1 bi5jb20+bW9iaWxlLWlwQHN1bnJvb2YuZW5nLnN1bi5jb208L0E+IDwvRElWPg0KICAgIDxESVYg c3R5bGU9IkZPTlQ6IDEwcHQgsby4siI+PEI+U2VudDo8L0I+IFRodXJzZGF5LCBKdWx5IDEyLCAy MDAxIDg6MDEgDQpQTTwvRElWPg0KICAgIDxESVYgc3R5bGU9IkZPTlQ6IDEwcHQgsby4siI+PEI+ U3ViamVjdDo8L0I+IFttb2JpbGUtaXBdIEhvdyB0byBsZWFybiB0aGUgcGF0aCANCiAgICB0aGF0 IE1vYmlsZS1JUCBwYWNrZXQgdGFrZSB0aHJvdWdoIHRoZUludGVybmV0PC9ESVY+DQogICAgPERJ Vj48QlI+PC9ESVY+DQogICAgPERJVj48Rk9OVCBzaXplPTI+DQogICAgPERJVj48Rk9OVCBzaXpl PTI+SGVsbG8uPC9GT05UPjwvRElWPg0KICAgIDxESVY+Jm5ic3A7PC9ESVY+DQogICAgPERJVj48 Rk9OVCBzaXplPTI+QXNzdW1lIGZvbGxvd2luZyBzaXR1YXRpb24uPC9GT05UPjwvRElWPg0KICAg IDxESVY+Jm5ic3A7PC9ESVY+DQogICAgPERJVj48Rk9OVCBzaXplPTI+ZXgpPC9GT05UPjwvRElW Pg0KICAgIDxESVY+PEZPTlQgc2l6ZT0yPm5vZGUgQSAtLS0tIEZBIC0tLS0tIEhBIC0tLS0tLSBu b2RlIEI8L0ZPTlQ+PC9ESVY+DQogICAgPERJVj4mbmJzcDs8L0RJVj4NCiAgICA8RElWPjxGT05U IHNpemU9Mj5ub2RlIEIgc2VuZCB0aGUgcGFja2V0IHRvIG5vZGUgQS4gVGhlbiBIQSBpbnRlcmNl cHQgdGhlIA0KICAgIHBhY2tldCBhbmQgZW5jYXBzdWxhdGUgaXQuPC9GT05UPjwvRElWPg0KICAg IDxESVY+PEZPTlQgc2l6ZT0yPlNlbmQmbmJzcDtlbmNhcHN1bGF0ZWQgcGFja2V0IHRvIEZBIHRo cm91Z2ggRkEtSEEgDQogICAgdHVubmVsLjwvRk9OVD48L0RJVj4NCiAgICA8RElWPjxGT05UIHNp emU9Mj5maW5hbGx5IEZBIHNlbmQgZGVjYXBzdWxhdGVkIHBhY2tldCB0byBub2RlIA0KQS48L0ZP TlQ+PC9ESVY+DQogICAgPERJVj4mbmJzcDs8L0RJVj4NCiAgICA8RElWPjxGT05UIHNpemU9Mj5N eSBxdWVzdGlvbiBpcyAiSXMgaXQgcG9zc2libGUgdGhhdCBub2RlIEIga25vdyB3aG9sZSBwYXRo IA0KICAgIGJldHdlZW4gbm9kZSBBIGFuZCBub2RlIEI/Ii48L0ZPTlQ+PC9ESVY+DQogICAgPERJ Vj4mbmJzcDs8L0RJVj4NCiAgICA8RElWPiZuYnNwOzwvRElWPg0KICAgIDxESVY+PEZPTlQgc2l6 ZT0yPkkgdGhpbmsgdGhlcmUgaXMgYWRkaXRpb25hbCBmZWF0dXJlIHRvJm5ic3A7YWRkIHRoZSAN CiAgICB0cmFjZXJvdXRlIGluZm9ybWF0aW9uIHRvIG9yaWdpbmFsIHBhY2tldCBieSBGQSBhbmQg SEEuPC9GT05UPjwvRElWPg0KICAgIDxESVY+Jm5ic3A7PC9ESVY+DQogICAgPERJVj4mbmJzcDs8 L0RJVj4NCiAgICA8RElWPiZuYnNwOzwvRElWPg0KICAgIDxESVY+Jm5ic3A7PC9ESVY+PC9GT05U PjwvRElWPjwvQkxPQ0tRVU9URT48L0JMT0NLUVVPVEU+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_000_0029_01C10B19.41CFA620-- From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 12 08:41:55 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA13807 for ; Thu, 12 Jul 2001 08:41:54 -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 FAA21920; Thu, 12 Jul 2001 05:41:40 -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 FAA28470; Thu, 12 Jul 2001 05:41:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6CCe3E10777 for mobile-ip-dist; Thu, 12 Jul 2001 05:40:03 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6CCdxN10770 for ; Thu, 12 Jul 2001 05:39:59 -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 FAA13804 for ; Thu, 12 Jul 2001 05:40:09 -0700 (PDT) Received: from mail.lge.com ([156.147.1.150]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA19362 for ; Thu, 12 Jul 2001 06:41:19 -0600 (MDT) Received: from lgekrhqmh01.lge.com ([156.147.51.51]) by mail.lge.com (8.8.4_hhk9703/8.6.9) with ESMTP id VAA15958 for ; Thu, 12 Jul 2001 21:36:48 +0900 (KST) Received: from aeb099w ([150.150.60.99]) by lgekrhqmh01.lge.com (Lotus Domino Release 5.07a) with SMTP id 2001071221393867:226345 ; Thu, 12 Jul 2001 21:39:38 +0900 Message-ID: <009101c10acf$05819150$633c9696@aeb099w> From: "Kim Taeyong" To: References: <001b01c10ac4$631e6a50$633c9696@aeb099w> Subject: Re: [mobile-ip] How to learn the path that Mobile-IP packet take throughtheInternet Date: Thu, 12 Jul 2001 21:34:40 +0900 MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-MIMETrack: Itemize by SMTP Server on LGEKRHQMH01/LGE/LG Group(Release 5.07a |May 14, 2001) at 07/12/2001 09:39:38 PM, Serialize by Router on LGEKRHQMH01/LGE/LG Group(Release 5.07a |May 14, 2001) at 07/12/2001 09:39:58 PM, Serialize complete at 07/12/2001 09:39:58 PM Content-Type: multipart/alternative; boundary="----=_NextPart_000_008E_01C10B1A.754D9B00" 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_008E_01C10B1A.754D9B00 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 dGVzdA0K ------=_NextPart_000_008E_01C10B1A.754D9B00 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWtz X2NfNTYwMS0xOTg3IiBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZT4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA1LjAwLjI5MjAuMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVB RD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj48Rk9OVCBzaXplPTI+dGVzdDwvRk9OVD48L0JPRFk+ PC9IVE1MPg0K ------=_NextPart_000_008E_01C10B1A.754D9B00-- From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 12 08:52:13 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA15089 for ; Thu, 12 Jul 2001 08:52:13 -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 FAA25279; Thu, 12 Jul 2001 05:52:17 -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 FAA29451; Thu, 12 Jul 2001 05:51:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6CCobt10814 for mobile-ip-dist; Thu, 12 Jul 2001 05:50:37 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6CCoXN10807 for ; Thu, 12 Jul 2001 05:50: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 FAA14869 for ; Thu, 12 Jul 2001 05:50:44 -0700 (PDT) Received: from mail.lge.com ([156.147.1.150]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA24660 for ; Thu, 12 Jul 2001 06:51:54 -0600 (MDT) Received: from lgekrhqmh01.lge.com ([156.147.51.51]) by mail.lge.com (8.8.4_hhk9703/8.6.9) with ESMTP id VAA17303 for ; Thu, 12 Jul 2001 21:47:37 +0900 (KST) Received: from aeb099w ([150.150.60.99]) by lgekrhqmh01.lge.com (Lotus Domino Release 5.07a) with SMTP id 2001071221503438:226924 ; Thu, 12 Jul 2001 21:50:34 +0900 Message-ID: <00b301c10ad0$8c18b7b0$633c9696@aeb099w> From: "Kim Taeyong" To: References: <00a101c10ac1$f45fced0$633c9696@aeb099w> <00c701c10ac3$ad62ac30$633c9696@aeb099w> <002c01c10acd$d212b7a0$e19b98a3@nnt> Subject: Re: [mobile-ip] How to learn the path that Mobile-IP packet take throughtheInternet Date: Thu, 12 Jul 2001 21:45:36 +0900 MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-MIMETrack: Itemize by SMTP Server on LGEKRHQMH01/LGE/LG Group(Release 5.07a |May 14, 2001) at 07/12/2001 09:50:34 PM, Serialize by Router on LGEKRHQMH01/LGE/LG Group(Release 5.07a |May 14, 2001) at 07/12/2001 09:50:34 PM, Serialize complete at 07/12/2001 09:50:34 PM Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B0_01C10B1B.FBEB02F0" 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_00B0_01C10B1B.FBEB02F0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SGVsbG8uIEkgdGhhbmtzIHRvICB5b3VyIGFuc3dlcg0KQXQgZmlyc3QgSSBjYXJlZnVsbHkgcmVh ZCBSRkMyMDAzIG9uZSBtb3JlIHRpbWUuDQoNCkJ1dCBzdGlsbCBJIGhhdmUgb25lIG1vcmUgcXVl c3Rpb24uDQoNCk5vZGUgQiBzZXQgdHJhY2Vyb3V0ZSBmbGFnIGluIElQIGhlYWRlciBmaWxlZCBh bmQgc2VuZCB0aGlzIHBhY2tldC4NClRoZW4gSEEgdHVubmVyIHRoaXMgcGFja2V0IHdpdGggb3V0 ZXIgSVAgaGVhZGVyLg0KQWNjb3JkaW5nIHRvIFJGQzIwMDMsIE91dGVyIElQIGhlYWRlciBkbyBu b3QgY29weSBpbm5lciBJUCBoZWFkZXIgc2V0dGluZyB0byBvdXRlciBJUCBoZWFkZXIgb3B0aW9u IGZpZWxkLg0KU28gSWYgSEEgZG8gbm90IHNldCB0cmFjZXJvdXRlIGZpZWxkIHRvIG91dGVyIElQ IGhlYWRlciwgdGhlbiBpdCBtYXkgbm90IGdlbmVyYXRlIElDTVAgcGFja2V0IGluIHR1bm5lbGlu ZyBwYXRoLg0KDQpBbSBJIHJpZ2h0Pw0KDQpIYXZlIGEgbmljZSBkYXkuDQo= ------=_NextPart_000_00B0_01C10B1B.FBEB02F0 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWtz X2NfNTYwMS0xOTg3IiBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZT4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA1LjAwLjI5MjAuMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVB RD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+DQo8RElWPjxGT05UIHNpemU9Mj5IZWxs by4gSSZuYnNwO3RoYW5rcyB0byAgeW91ciBhbnN3ZXI8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05U IHNpemU9Mj5BdCBmaXJzdCBJIGNhcmVmdWxseSByZWFkIFJGQzIwMDMgb25lIG1vcmUgdGltZS48 L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+QnV0IHN0 aWxsIEkgaGF2ZSBvbmUgbW9yZSBxdWVzdGlvbi48L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwv RElWPg0KPERJVj48Rk9OVCBzaXplPTI+Tm9kZSBCIHNldCB0cmFjZXJvdXRlIGZsYWcgaW4gSVAg aGVhZGVyIGZpbGVkIGFuZCBzZW5kIHRoaXMgDQpwYWNrZXQuPC9GT05UPjwvRElWPg0KPERJVj48 Rk9OVCBzaXplPTI+VGhlbiBIQSB0dW5uZXIgdGhpcyBwYWNrZXQgd2l0aCBvdXRlciBJUCBoZWFk ZXIuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+QWNjb3JkaW5nIHRvIFJGQzIwMDMs IE91dGVyIElQIGhlYWRlciBkbyBub3QgY29weSBpbm5lciBJUCANCmhlYWRlciBzZXR0aW5nIHRv IG91dGVyIElQIGhlYWRlciBvcHRpb24gZmllbGQuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBz aXplPTI+U28gSWYgSEEgZG8gbm90IHNldCB0cmFjZXJvdXRlIGZpZWxkIHRvIG91dGVyIElQIGhl YWRlciwgdGhlbiANCml0IG1heSBub3QgZ2VuZXJhdGUgSUNNUCBwYWNrZXQgaW4gdHVubmVsaW5n IHBhdGguPC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0y PkFtIEkgcmlnaHQ/PC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQg c2l6ZT0yPkhhdmUgYSBuaWNlIGRheS48L0ZPTlQ+PC9ESVY+PC9ESVY+PC9CT0RZPjwvSFRNTD4N Cg== ------=_NextPart_000_00B0_01C10B1B.FBEB02F0-- From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 12 09:11:11 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA17385 for ; Thu, 12 Jul 2001 09:11:10 -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 GAA01729; Thu, 12 Jul 2001 06:11:13 -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 GAA16480; Thu, 12 Jul 2001 06:10:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6CD9sD10867 for mobile-ip-dist; Thu, 12 Jul 2001 06:09:54 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6CD9pN10860 for ; Thu, 12 Jul 2001 06:09:51 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA16560 for ; Thu, 12 Jul 2001 06:10:02 -0700 (PDT) Received: from jm.epitest.fi (d248-126.arenanet.fi [194.241.248.126]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id GAA25807 for ; Thu, 12 Jul 2001 06:09:59 -0700 (PDT) Received: (qmail 5063 invoked by uid 500); 12 Jul 2001 13:09:49 -0000 Date: Thu, 12 Jul 2001 16:09:49 +0300 From: Jouni Malinen To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] WG last call: draft-ietf-mobileip-gen-key-00.txt Message-ID: <20010712160948.A4970@jm.epitest.fi> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from PRoberts@MEGISTO.com on Fri, Jul 06, 2001 at 01:55:02PM -0400 X-AntiVirus: scanned for viruses by AMaViS 0.2.1 (http://amavis.org/) 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 Fri, Jul 06, 2001 at 01:55:02PM -0400, Phil Roberts wrote: > This is a Mobile IP WG last call for the I-D > draft-ietf-mobileip-gen-key-00.txt > Generalized Key Extensions for Mobile IP. This draft will be sent to the > IESG > requesting a proposed standard status to be associated with it at the end of > the last call period. Please send your comments to the WG discussion list. I noticed couple of minor typos/copy-paste errors (below) that could be fixed: 3. Generalized MN-FA Key Reply Extension Length The 16-bit Length field indicates the length of the extension. It is equal to 4 plus the number of bytes in the Encoded MN-FA Key Data. ==> It is equal to the number of bytes .. (i.e., no SPI or lifetime field of 4 bytes in MN-FA key reply ext.) 7. Generalized FA-FA Key Reply Extension Length The 16-bit Length field indicates the length of the extension. It is equal to 4 plus the number of bytes in the Encoded FA-HA Key Data. ==> Encoded FA-FA Key Data For each subtype, the format of the FA-HA Key Reply Subtype Data has ==> format of the FA-FA Key Reply .. -- Jouni Malinen PGP id EFC895FA From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 12 09:14:09 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA17740 for ; Thu, 12 Jul 2001 09:14:08 -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 GAA02789; Thu, 12 Jul 2001 06:14:05 -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 GAA16767; Thu, 12 Jul 2001 06:13:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6CDD7K10893 for mobile-ip-dist; Thu, 12 Jul 2001 06:13:07 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6CDD4N10886 for ; Thu, 12 Jul 2001 06:13: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 GAA16730 for ; Thu, 12 Jul 2001 06:13:14 -0700 (PDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id HAA27562 for ; Thu, 12 Jul 2001 07:13:12 -0600 (MDT) Received: (qmail 22347 invoked by uid 500); 12 Jul 2001 13:02:24 -0000 Date: Thu, 12 Jul 2001 06:02:24 -0700 From: Pat Calhoun To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] WG last call: draft-ietf-mobileip-gen-key-00.txt Message-ID: <20010712060224.F5588@charizard.diameter.org> References: <20010712160948.A4970@jm.epitest.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010712160948.A4970@jm.epitest.fi>; from jkmaline@cc.hut.fi on Thu, Jul 12, 2001 at 04:09:49PM +0300 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 for the commens. I will address these in the next revision. PatC On Thu, Jul 12, 2001 at 04:09:49PM +0300, Jouni Malinen wrote: > On Fri, Jul 06, 2001 at 01:55:02PM -0400, Phil Roberts wrote: > > > This is a Mobile IP WG last call for the I-D > > draft-ietf-mobileip-gen-key-00.txt > > Generalized Key Extensions for Mobile IP. This draft will be sent to the > > IESG > > requesting a proposed standard status to be associated with it at the end of > > the last call period. Please send your comments to the WG discussion list. > > I noticed couple of minor typos/copy-paste errors (below) that could be > fixed: > > 3. Generalized MN-FA Key Reply Extension > > Length The 16-bit Length field indicates the length of > the extension. It is equal to 4 plus the number > of bytes in the Encoded MN-FA Key Data. > > ==> It is equal to the number of bytes .. > (i.e., no SPI or lifetime field of 4 bytes in MN-FA key reply ext.) > > > 7. Generalized FA-FA Key Reply Extension > > Length The 16-bit Length field indicates the length of > the extension. It is equal to 4 plus the number > of bytes in the Encoded FA-HA Key Data. > > ==> Encoded FA-FA Key Data > > For each subtype, the format of the FA-HA Key Reply Subtype Data has > > ==> format of the FA-FA Key Reply .. > > > -- > Jouni Malinen PGP id EFC895FA > From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 12 10:17:43 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA26264 for ; Thu, 12 Jul 2001 10:17:43 -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 HAA26412; Thu, 12 Jul 2001 07:16:49 -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 HAA07813; Thu, 12 Jul 2001 07:15:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6CEEOk10976 for mobile-ip-dist; Thu, 12 Jul 2001 07:14:24 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6CEELN10969 for ; Thu, 12 Jul 2001 07:14:21 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA23476 for ; Thu, 12 Jul 2001 07:14:30 -0700 (PDT) Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA28543 for ; Thu, 12 Jul 2001 07:14:29 -0700 (PDT) Received: from ihemail1.firewall.lucent.com (localhost [127.0.0.1]) by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f6CEETS28411 for ; Thu, 12 Jul 2001 10:14:29 -0400 (EDT) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f6CEESO28382 for ; Thu, 12 Jul 2001 10:14:28 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id <3YPH5C67>; Thu, 12 Jul 2001 15:14:27 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB00211A9F8@en0033exch001u.uk.lucent.com> From: "Tanis, Michael (Michael)" To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Agent Discovery during handover Date: Thu, 12 Jul 2001 15:14:26 +0100 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: Hello all, I am currently doing my MSc project in simulating the Agent Discovery process in OPNET. There is a critical point where the MN is receiving advertisements from two or more Agents. What should be the reaction of the MN? Should it start registration according to the signal power received, according to the Lifetime field or to the services offered ? I would really appreciate it if someone could answer the question or point me to the suitable document Thanks in advance, -------------------------------- Michael Tanis O Lucent Technologies UMTS-SAE Optimus Building Windmill Hill Business Park Swindon Wilts SN5 6PP United Kingdom Work Tel: +44 1793 897856 Mobile : +44 7779 032004 e-mail : mtanis@lucent.com From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 12 10:20:08 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA26564 for ; Thu, 12 Jul 2001 10:20:07 -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 HAA27595; Thu, 12 Jul 2001 07:19: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 HAA08276; Thu, 12 Jul 2001 07:19:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6CEH1F11022 for mobile-ip-dist; Thu, 12 Jul 2001 07:17:01 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6CEGuN11010 for ; Thu, 12 Jul 2001 07:16:56 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA08012 for ; Thu, 12 Jul 2001 07:17:05 -0700 (PDT) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA02746 for ; Thu, 12 Jul 2001 07:17:04 -0700 (PDT) X-Envelope-Sender-Is: Hannes.Tschofenig@mchp.siemens.de (at relayer david.siemens.de) Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by david.siemens.de (8.11.0/8.11.0) with ESMTP id f6CEH2c18775 for ; Thu, 12 Jul 2001 16:17:03 +0200 (MET DST) Received: from sn52sun1 (sn52sun1.mchp.siemens.de [139.23.202.144]) by mail3.siemens.de (8.11.4/8.11.4) with SMTP id f6CEH2I24722548 for ; Thu, 12 Jul 2001 16:17:02 +0200 (MEST) From: "Hannes Tschofenig" To: "MobileIP" Subject: [mobile-ip] questions about your realtime mobile ipv6 draft Date: Thu, 12 Jul 2001 16:17:28 +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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit hi! i would like to ask you some questions related to your realtime mobile ipv6 draft: i was curious about the presence of the entities AKDC and aPDP. 1) The entity AKDC was described as an entity that provides credentials and authorizes use of the home KDC. why is this necessary? which credentials does this AKDC provide? where is this AKDC located? It is not located in the visited network and according to the initial sample network diagram not located in the home network. 2) The APDP - Authorizing PDP Is the APDP something like a broker or a clearinghouse? communication between the vPDP and the hPDP would therefore use the aPDP as a broker (vPDP->aPDP->hPDP and vPDP<-aPDP<-hPDP). from my understanding you only need a PDP and a KDC in the home network and in the visited network. (except if no direct trust relationship is available -> brokers) thank you for your help. greetings hannes From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 12 10:20:09 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA26575 for ; Thu, 12 Jul 2001 10:20:09 -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 HAA27599; Thu, 12 Jul 2001 07:19: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 HAA08275; Thu, 12 Jul 2001 07:19:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6CEGwU11020 for mobile-ip-dist; Thu, 12 Jul 2001 07:16:58 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6CEGrN11002 for ; Thu, 12 Jul 2001 07:16:53 -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 HAA08000 for ; Thu, 12 Jul 2001 07:17:03 -0700 (PDT) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA09882 for ; Thu, 12 Jul 2001 08:18:14 -0600 (MDT) X-Envelope-Sender-Is: Hannes.Tschofenig@mchp.siemens.de (at relayer david.siemens.de) Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by david.siemens.de (8.11.0/8.11.0) with ESMTP id f6CEH0c18748 for ; Thu, 12 Jul 2001 16:17:01 +0200 (MET DST) Received: from sn52sun1 (sn52sun1.mchp.siemens.de [139.23.202.144]) by mail3.siemens.de (8.11.4/8.11.4) with SMTP id f6CEH0I24807304 for ; Thu, 12 Jul 2001 16:17:00 +0200 (MEST) From: "Hannes Tschofenig" To: "MobileIP" Subject: [mobile-ip] Comments/Questions to the Home Agent Cookie Draft Date: Thu, 12 Jul 2001 16:17:25 +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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit hi reading the draft i have some comments/questions: - i think that the protocol is vulnerable to a denial of service attack to some extend since the cn has to keep state for a certain time before being able to verify the response from the home agent? what prevents an adversary from sending many bogus requests to the cn and therefore to force him to allocate kernel memory etc. ? - if the cn includes his public key then the mn and the cn share a shared secret after the protocol exchange is finished. subsequent binding updates however still have the same structure as the first (both cookie values). such a bu could be simply protected by a keyed message digest attached to the bu message . - if the public key is not included then the cookie(mn,cn) cannot be verified and the mn and cn do not share a key afterwards. maybe it is a good idea to include the pk mandatory in the message from the cn to the ha. it is obvious that the cn does not need to create a new pk/sk pair for every session and hence there is not too much overhead associated with the additional message part. - if i understood the protocol correctly then two sequence numbers are used: the binding update includes a sequence number field and the cookie(mn,cn) value too. is this really necessary? what happens if the sequence numbers are out-of-sync (there is no protocol for re-synchronization) - the term checksum inside the cookie should be changed to e.g. key message digest - the cookie checksum (keyed message digest computation) should be done with a standard technique e.g. HMAC-MD5 .... - is the hop-by-hop option really necessary? why not to address the home agent directly with a message? - the argumentation for the home less scenario seems to be a little bit difficult: the main property of the home agent cookie draft is the usage of the home agent and the shared secret between the mn and the ha. hence i have some doubts that the homeless scenario is really useful. - if the ha is supposed to verify the cookie(mn,ha) then the binding update should be included since the home agent may not have the full information to reconstruct the binding update e.g. because he does not know the sequence number included in the BU from the mn to the cn. (however if the cookie(mn,cn) is exactly set to the same sequence number then it may be possible - but i think that this is not described anywhere.) what do you think? ciao hannes From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 12 10:26:56 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA27553 for ; Thu, 12 Jul 2001 10:26:55 -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 FAA04905; Thu, 12 Jul 2001 05:24:42 -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 EAA20156; Thu, 12 Jul 2001 04:24:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6CBNZd10636 for mobile-ip-dist; Thu, 12 Jul 2001 04:23:35 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6CBNWN10629 for ; Thu, 12 Jul 2001 04:23:32 -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 EAA20090 for ; Thu, 12 Jul 2001 04:23:42 -0700 (PDT) Received: from mail.lge.com ([156.147.1.150]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA04414 for ; Thu, 12 Jul 2001 05:23:39 -0600 (MDT) Received: from lgekrhqmh01.lge.com ([156.147.51.51]) by mail.lge.com (8.8.4_hhk9703/8.6.9) with ESMTP id UAA06328 for ; Thu, 12 Jul 2001 20:20:33 +0900 (KST) Received: from aeb099w ([150.150.60.99]) by lgekrhqmh01.lge.com (Lotus Domino Release 5.07a) with SMTP id 2001071220233119:219845 ; Thu, 12 Jul 2001 20:23:31 +0900 Message-ID: <001b01c10ac4$631e6a50$633c9696@aeb099w> From: "Kim Taeyong" To: Subject: [mobile-ip] How to learn the path that Mobile-IP packet take through theInternet Date: Thu, 12 Jul 2001 20:18:33 +0900 MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-MIMETrack: Itemize by SMTP Server on LGEKRHQMH01/LGE/LG Group(Release 5.07a |May 14, 2001) at 07/12/2001 08:23:31 PM, Serialize by Router on LGEKRHQMH01/LGE/LG Group(Release 5.07a |May 14, 2001) at 07/12/2001 08:23:32 PM, Serialize complete at 07/12/2001 08:23:32 PM Content-Type: multipart/alternative; boundary="----=_NextPart_000_0018_01C10B0F.D2E17350" 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_0018_01C10B0F.D2E17350 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 IA0KSGVsbG8uDQoNCkFzc3VtZSBmb2xsb3dpbmcgc2l0dWF0aW9uLg0KDQpleCkNCm5vZGUgQSAt LS0tIEZBIC0tLS0tIEhBIC0tLS0tLSBub2RlIEINCg0Kbm9kZSBCIHNlbmQgdGhlIHBhY2tldCB0 byBub2RlIEEuIFRoZW4gSEEgaW50ZXJjZXB0IHRoZSBwYWNrZXQgYW5kIGVuY2Fwc3VsYXRlIGl0 Lg0KU2VuZCBlbmNhcHN1bGF0ZWQgcGFja2V0IHRvIEZBIHRocm91Z2ggRkEtSEEgdHVubmVsLg0K ZmluYWxseSBGQSBzZW5kIGRlY2Fwc3VsYXRlZCBwYWNrZXQgdG8gbm9kZSBBLg0KDQpNeSBxdWVz dGlvbiBpcyAiSXMgaXQgcG9zc2libGUgdGhhdCBub2RlIEIga25vdyB3aG9sZSBwYXRoIGJldHdl ZW4gbm9kZSBBIGFuZCBub2RlIEI/Ii4NCg0KDQpJIHRoaW5rIHRoZXJlIGlzIGFkZGl0aW9uYWwg ZmVhdHVyZSB0byBhZGQgdGhlIHRyYWNlcm91dGUgaW5mb3JtYXRpb24gdG8gb3JpZ2luYWwgcGFj a2V0IGJ5IEZBIGFuZCBIQS4NCg0KDQo= ------=_NextPart_000_0018_01C10B0F.D2E17350 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWtz X2NfNTYwMS0xOTg3IiBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZT4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA1LjAwLjI5MjAuMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVB RD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPjxGT05UIHNpemU9 Mj4mbmJzcDsNCjxESVY+PEZPTlQgc2l6ZT0yPkhlbGxvLjwvRk9OVD48L0RJVj4NCjxESVY+Jm5i c3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5Bc3N1bWUgZm9sbG93aW5nIHNpdHVhdGlvbi48 L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+ZXgpPC9G T05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+bm9kZSBBIC0tLS0gRkEgLS0tLS0gSEEgLS0t LS0tIG5vZGUgQjwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNp emU9Mj5ub2RlIEIgc2VuZCB0aGUgcGFja2V0IHRvIG5vZGUgQS4gVGhlbiBIQSBpbnRlcmNlcHQg dGhlIHBhY2tldCANCmFuZCBlbmNhcHN1bGF0ZSBpdC48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05U IHNpemU9Mj5TZW5kJm5ic3A7ZW5jYXBzdWxhdGVkIHBhY2tldCB0byBGQSB0aHJvdWdoIEZBLUhB IA0KdHVubmVsLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPmZpbmFsbHkgRkEgc2Vu ZCBkZWNhcHN1bGF0ZWQgcGFja2V0IHRvIG5vZGUgQS48L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNw OzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+TXkgcXVlc3Rpb24gaXMgIklzIGl0IHBvc3NpYmxl IHRoYXQgbm9kZSBCIGtub3cgd2hvbGUgcGF0aCANCmJldHdlZW4gbm9kZSBBIGFuZCBub2RlIEI/ Ii48L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxE SVY+PEZPTlQgc2l6ZT0yPkkgdGhpbmsgdGhlcmUgaXMgYWRkaXRpb25hbCBmZWF0dXJlIHRvJm5i c3A7YWRkIHRoZSB0cmFjZXJvdXRlIA0KaW5mb3JtYXRpb24gdG8gb3JpZ2luYWwgcGFja2V0IGJ5 IEZBIGFuZCBIQS48L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDs8 L0RJVj48L0ZPTlQ+PC9GT05UPjwvRElWPjwvQk9EWT48L0hUTUw+DQo= ------=_NextPart_000_0018_01C10B0F.D2E17350-- From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 12 10:34:54 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA28646 for ; Thu, 12 Jul 2001 10:34:53 -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 IAA25826; Thu, 12 Jul 2001 08:34:38 -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 HAA10330; Thu, 12 Jul 2001 07:34:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6CEWvb11126 for mobile-ip-dist; Thu, 12 Jul 2001 07:32:57 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6CEWrN11119 for ; Thu, 12 Jul 2001 07:32:53 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA10177 for ; Thu, 12 Jul 2001 07:33:03 -0700 (PDT) Received: from dumburken.it.kth.se (dumburken.it.kth.se [130.237.214.122]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA09288 for ; Thu, 12 Jul 2001 07:33:02 -0700 (PDT) Received: (from maguire@localhost) by dumburken.it.kth.se (8.9.3/8.9.3) id QAA08393; Thu, 12 Jul 2001 16:32:45 +0200 (MET DST) Date: Thu, 12 Jul 2001 16:32:45 +0200 (MET DST) Message-Id: <200107121432.QAA08393@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: <475FF955A05DD411980D00508B6D5FB00211A9F8@en0033exch001u.uk.lucent.com> (mtanis@lucent.com) Subject: Re: [mobile-ip] Agent Discovery during handover References: <475FF955A05DD411980D00508B6D5FB00211A9F8@en0033exch001u.uk.lucent.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: It is a complex policy decision which depends on the objectives of the local node, the state of its communications, who the potential new access point will server, the traffic which this access point is currently service, the expected traffic that this mobile will add to the access point, the time since the mobile last changed access point, etc. For example, if the mobile node was just recently using this access point and has now switched to another access point - then you might not want to switch back - so that you introduce some hysteresis. For example, if the new access point is not likely to provide it with the services that it wants, then there is no reason to register. (This knowledge might come from an earlier visit or from another model node who has passed htis information on to you.) Another example, you currently have a streaming media connection via a multicast tree, but you have not used Jiang Wu's pre-registration approach to join the multicast tree of the new access point, then you might want to delay registering until either you have pre-registered or there is a lull in the streaming traffic or you are finished with this application; then you might register with the new access point. You might also be very cost sensitive, thus you might consider the economic cost of staying with your current access point vs. switching. ... As you can see, the decision to register or not can be a very complex decision based on your policies, current state, expected future state, ... . Chip From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 12 10:48:48 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA00622 for ; Thu, 12 Jul 2001 10:48:47 -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 IAA05633; Thu, 12 Jul 2001 08:47:59 -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 HAA11968; Thu, 12 Jul 2001 07:47:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6CEk9e11175 for mobile-ip-dist; Thu, 12 Jul 2001 07:46:09 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6CEk6N11168 for ; Thu, 12 Jul 2001 07:46:06 -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 HAA11820 for ; Thu, 12 Jul 2001 07:46:16 -0700 (PDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id IAA04405 for ; Thu, 12 Jul 2001 08:46:14 -0600 (MDT) Received: (qmail 24162 invoked by uid 500); 12 Jul 2001 14:35:25 -0000 Date: Thu, 12 Jul 2001 07:35:25 -0700 From: Pat Calhoun To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Agent Discovery during handover Message-ID: <20010712073525.K5588@charizard.diameter.org> References: <475FF955A05DD411980D00508B6D5FB00211A9F8@en0033exch001u.uk.lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <475FF955A05DD411980D00508B6D5FB00211A9F8@en0033exch001u.uk.lucent.com>; from mtanis@lucent.com on Thu, Jul 12, 2001 at 03:14:26PM +0100 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 Seamoby WG is working on defining handoff candidates discovery based on certain characteristics or required features. In MIP, the fact that you've received an agent advertisement is sufficient. So I suggest you send e-mail to the seamoby list. Thanks, PatC On Thu, Jul 12, 2001 at 03:14:26PM +0100, Tanis, Michael (Michael) wrote: > Hello all, > > I am currently doing my MSc project in simulating the Agent Discovery > process in OPNET. There is a critical point where the MN is receiving > advertisements from two or more Agents. What should be the reaction of the > MN? Should it start registration according to the signal power received, > according to the Lifetime field or to the services offered ? > > I would really appreciate it if someone could answer the question or point > me to the suitable document > > Thanks in advance, > > > -------------------------------- > Michael Tanis > > O Lucent Technologies UMTS-SAE > Optimus Building > Windmill Hill Business Park > Swindon > Wilts SN5 6PP > United Kingdom > > Work Tel: +44 1793 897856 > Mobile : +44 7779 032004 > e-mail : mtanis@lucent.com > From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 12 11:20:20 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA05136 for ; Thu, 12 Jul 2001 11:20:19 -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 JAA01780; Thu, 12 Jul 2001 09:20: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 IAA01915; Thu, 12 Jul 2001 08:18:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6CFHmb11258 for mobile-ip-dist; Thu, 12 Jul 2001 08:17:48 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6CFHiN11251 for ; Thu, 12 Jul 2001 08:17:44 -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 IAA05929 for ; Thu, 12 Jul 2001 08:17:54 -0700 (PDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA29614 for ; Thu, 12 Jul 2001 09:17:51 -0600 (MDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f6CFHpN10533 for ; Thu, 12 Jul 2001 17:17:51 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Thu Jul 12 17:17:49 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Thu, 12 Jul 2001 17:17:50 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008AD1@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" , seamoby@cdma-2000.org Subject: RE: [mobile-ip] Agent Discovery during handover Date: Thu, 12 Jul 2001 17:17:46 +0200 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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Pat, Is it strictly AP discovery or is it a mix of AP/AR discovery that Seamoby is looking into ? I think the distinction is important because the solution will vary considerably. Hesham > -----Original Message----- > From: Pat Calhoun [SMTP:pcalhoun@diameter.org] > Sent: Thursday, 12 July 2001 4:35 > To: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Agent Discovery during handover > > The Seamoby WG is working on defining handoff candidates discovery based > on certain characteristics or required features. In MIP, the fact that > you've received an agent advertisement is sufficient. > > So I suggest you send e-mail to the seamoby list. > > Thanks, > > PatC > On Thu, Jul 12, 2001 at 03:14:26PM +0100, Tanis, Michael (Michael) wrote: > > Hello all, > > > > I am currently doing my MSc project in simulating the Agent Discovery > > process in OPNET. There is a critical point where the MN is receiving > > advertisements from two or more Agents. What should be the reaction of the > > MN? Should it start registration according to the signal power received, > > according to the Lifetime field or to the services offered ? > > > > I would really appreciate it if someone could answer the question or point > > me to the suitable document > > > > Thanks in advance, > > > > > > -------------------------------- > > Michael Tanis > > > > O Lucent Technologies UMTS-SAE > > Optimus Building > > Windmill Hill Business Park > > Swindon > > Wilts SN5 6PP > > United Kingdom > > > > Work Tel: +44 1793 897856 > > Mobile : +44 7779 032004 > > e-mail : mtanis@lucent.com > > From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 12 11:32:16 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06788 for ; Thu, 12 Jul 2001 11:32:15 -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 IAA00412; Thu, 12 Jul 2001 08:32:02 -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 IAA03802; Thu, 12 Jul 2001 08:31:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6CFUFG11303 for mobile-ip-dist; Thu, 12 Jul 2001 08:30:15 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6CFUCN11296 for ; Thu, 12 Jul 2001 08:30:12 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA26409 for ; Thu, 12 Jul 2001 08:30:22 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA09688 for ; Thu, 12 Jul 2001 08:30:21 -0700 (PDT) Received: from mchandra-u10.cisco.com (mchandra-u10.cisco.com [64.102.66.20]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f6CFUIk06696 for ; Thu, 12 Jul 2001 08:30:18 -0700 (PDT) Received: (mchandra@localhost) by mchandra-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA22615 for mobile-ip@sunroof.eng.sun.com; Thu, 12 Jul 2001 11:30:01 -0400 (EDT) Date: Thu, 12 Jul 2001 11:30:01 -0400 From: "Madhavi W. Chandra" To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Re: mobile-ip] Registration revocation issues Message-ID: <20010712113001.A22611@cisco.com> References: <200107120002.f6C02mr541640@jurassic.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200107120002.f6C02mr541640@jurassic.eng.sun.com>; from glass@jurassic.eng.sun.com on Wed, Jul 11, 2001 at 08:03:21PM -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: Steve, On Wed, Jul 11, 2001 at 08:03:21PM -0400, Steven Glass - Solaris Software wrote: > > >On Wed, Jul 11, 2001 at 07:21:29PM -0400, Steven Glass - Solaris Software > wrote: > >> I'm just about done updating the revocation draft, and I have a few > >> questions to ask the group: > >> > >> 1) How do people feel about an "I understand revocations" registration > >> extension? We obviously are in favor of such an extension. > >To which pcalhoun@diameter.org sez: > > > >I prefer this than simply assuming it does. > ... > >The way I see it, I see no reason to send a new message type to an FA that > >may not recognize it. Chances are that an implementation will simply drop the > >message, causing the HA to retransmit, and eventually give up. > > > >If an FA advertises itself as supporting this extension, then you know that > >lack of response means that FA is really not reachable. > > The idea is a revocation is sent only once (or twice for the fixated), and a > response is sent (with a swapped ID and new authenticator) back to the revoker. > I see your point, though, how do you tell between someone who doesn't > understand, and someone who's already not listening (for whatever reason)? A > good argument to have it in. > Sounds like a good argument for an Acknowledgment mechanism also. I guess that's what your above paragraph is suggesting anyway. > > >Further, revocations MUST NOT be sent upon a binding expiration, right? It's > >only sent if a binding is revoked prior to lifetime expiration. > > True. > > >> 2) I'm removing the lifetime field. > ... > > >lifetimes are out, IMHO. A revocation means the session is terminated. If the > >MN wants to renew service, it can send a new registration request. > > Agreed. > Yes, as we've discussed before we also support the removal of the lifetime field. Regards, Madhavi > Cheers, > Steve From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 12 11:34:55 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07160 for ; Thu, 12 Jul 2001 11:34:55 -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 IAA01838; Thu, 12 Jul 2001 08:34: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 IAA04419; Thu, 12 Jul 2001 08:33:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6CFWip11325 for mobile-ip-dist; Thu, 12 Jul 2001 08:32:44 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6CFWeN11318 for ; Thu, 12 Jul 2001 08:32: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 IAA04141 for ; Thu, 12 Jul 2001 08:32:50 -0700 (PDT) Received: from netmail2.alcatel.com (netmail2.alcatel.com [128.251.168.51]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA21411 for ; Thu, 12 Jul 2001 09:34:01 -0600 (MDT) Received: from auds952.usa.alcatel.com (auds952.usa.alcatel.com [143.209.238.7]) by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id KAA05570 for ; Thu, 12 Jul 2001 10:32:49 -0500 (CDT) Received: from usa.alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f6CFWm513011 for ; Thu, 12 Jul 2001 10:32:48 -0500 (CDT) Message-ID: <3B4DC31F.2FDED7B4@usa.alcatel.com> Date: Thu, 12 Jul 2001 10:32:47 -0500 From: Sridhar Gurivireddy Organization: Alcatel USA X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] "Traceroute" in MIPv4 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 "Traceroute" program works by incrementing TTL value from 1 to 255 and by sending ICMP echo_request packet in the payload....The source lists all the routers which send "ICMP_TTL_exceeded" to trace the route to IP host....I guess "Traceroute" does not work in MIPv4 Let CN run "traceroute" program to find the route to MN... Case 1: Alternate CoA used After the FA decapsulates the packet and finds that TTL=0 , it sends "TTL exceeded" message back to HA. HA manupulates this packet and changes the packet to ICMP_HOST_UNREACHABLE..{As per Mobile Ipv4 specification) When the CN gets this packet, it is going to stop the "traceroute" program..So, I guess "traceroute" does not work... Case 2: Co-located CoA used: Even in this case it does not work for the same reason.... -- Sridhar Guriviredddy, Ph: 972.996.2048 From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 12 11:38:59 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07729 for ; Thu, 12 Jul 2001 11:38:57 -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 IAA03601; Thu, 12 Jul 2001 08:37:29 -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 IAA04700; Thu, 12 Jul 2001 08:35:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6CFYcW11366 for mobile-ip-dist; Thu, 12 Jul 2001 08:34:38 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6CFYYN11359 for ; Thu, 12 Jul 2001 08:34:34 -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 IAA22309 for ; Thu, 12 Jul 2001 08:34:44 -0700 (PDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id JAA14795 for ; Thu, 12 Jul 2001 09:34:42 -0600 (MDT) Received: (qmail 25242 invoked by uid 500); 12 Jul 2001 15:22:22 -0000 Date: Thu, 12 Jul 2001 08:22:22 -0700 From: Pat Calhoun To: mobile-ip@sunroof.eng.sun.com Cc: seamoby@cdma-2000.org Subject: Re: [mobile-ip] Agent Discovery during handover Message-ID: <20010712082222.N5588@charizard.diameter.org> Mail-Followup-To: mobile-ip@sunroof.eng.sun.com, seamoby@cdma-2000.org References: <034BEFD03799D411A59F00508BDF754603008AD1@esealnt448.al.sw.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: <034BEFD03799D411A59F00508BDF754603008AD1@esealnt448.al.sw.ericsson.se>; from Hesham.Soliman@era.ericsson.se on Thu, Jul 12, 2001 at 05:17:46PM +0200 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 Thu, Jul 12, 2001 at 05:17:46PM +0200, Hesham Soliman (ERA) wrote: > Pat, > > Is it strictly AP discovery or is it a mix of AP/AR discovery > that Seamoby is looking into ? > I think the distinction is important because the solution will > vary considerably. The problem statement is in the process of being written, so I cannot answer that question. I would hope that both AP and ARs are supported, but unfortunately cannot predict the future :) PatC From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 12 11:46:34 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08733 for ; Thu, 12 Jul 2001 11:46:34 -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 IAA08511; Thu, 12 Jul 2001 08:46: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 IAA05732; Thu, 12 Jul 2001 08:41:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6CFeN811412 for mobile-ip-dist; Thu, 12 Jul 2001 08:40:23 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6CFeJN11405 for ; Thu, 12 Jul 2001 08:40:19 -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 IAA28089 for ; Thu, 12 Jul 2001 08:40:29 -0700 (PDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id JAA26465 for ; Thu, 12 Jul 2001 09:41:40 -0600 (MDT) Received: (qmail 25625 invoked by uid 500); 12 Jul 2001 15:25:45 -0000 Date: Thu, 12 Jul 2001 08:25:44 -0700 From: Pat Calhoun To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: mobile-ip] Registration revocation issues Message-ID: <20010712082544.O5588@charizard.diameter.org> References: <200107120002.f6C02mr541640@jurassic.eng.sun.com> <20010712113001.A22611@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010712113001.A22611@cisco.com>; from mchandra@cisco.com on Thu, Jul 12, 2001 at 11:30:01AM -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: On Thu, Jul 12, 2001 at 11:30:01AM -0400, Madhavi W. Chandra wrote: > Sounds like a good argument for an Acknowledgment mechanism also. I > guess that's what your above paragraph is suggesting anyway. Correct, a reply *is* required, unless best-effort is sufficient, which I seriously doubt it is. PatC From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 12 11:53:57 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09903 for ; Thu, 12 Jul 2001 11:53: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 JAA00940; Thu, 12 Jul 2001 09:53: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 IAA08419; Thu, 12 Jul 2001 08:53:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6CFqIa11486 for mobile-ip-dist; Thu, 12 Jul 2001 08:52:18 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6CFqEN11479 for ; Thu, 12 Jul 2001 08:52:14 -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 IAA29980 for ; Thu, 12 Jul 2001 08:52:20 -0700 (PDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA03277 for ; Thu, 12 Jul 2001 09:53:32 -0600 (MDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f6CFqSZ00180 for ; Thu, 12 Jul 2001 08:52:28 -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 AAT10281; Thu, 12 Jul 2001 08:51:03 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA06739; Thu, 12 Jul 2001 08:51:03 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15181.51047.455144.138081@thomasm-u1.cisco.com> Date: Thu, 12 Jul 2001 08:51:03 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Comments/Questions to the Home Agent Cookie Draft 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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hannes Tschofenig writes: > hi > > reading the draft i have some comments/questions: > > - i think that the protocol is vulnerable to a denial of service attack to > some extend since the cn has to keep state for a certain time before being > able to verify the response from the home agent? what prevents an adversary > from sending many bogus requests to the cn and therefore to force him to > allocate kernel memory etc. ? The DoS is mitigated by the overall number of binding cache entries, which is limited. I believe the draft make some mention of that. There are probably other measures that could be taken as well. > - if the cn includes his public key then the mn and the cn share a shared > secret after the protocol exchange is finished. > subsequent binding updates however still have the same structure as the > first (both cookie values). > such a bu could be simply protected by a keyed message digest attached to > the bu message . As I recall, the reason that it sends both was to not make any assumptions of hard state on the CN. That is, if the CN drops the binding from its cache, we'd like to make certain that a subsequent BU works. There's no real requirement that it behave this way, as it could conceivably just fail and retry, but given the relatively small number of bytes for a cookie, it didn't seem like a big deal. I'm not terrible attached one way or the other though. > - if the public key is not included then the cookie(mn,cn) cannot be > verified and the mn and cn do not share a key afterwards. maybe it is a good > idea to include the pk mandatory in the message from the cn to the ha. it is > obvious that the cn does not need to create a new pk/sk pair for every > session and hence there is not too much overhead associated with the > additional message part. I mainly wanted to make the use of pk completely optional for both the HA and CN; ie, the CN or HA doesn't need to have any pk code on it at all. I guess I don't understand what the advantage of including it would be if the CN doesn't want to take the time to do a public key decryption... Note that if CN doesn't want to do that, but HA provides that service, it will delay the response back for the amount of time it takes HA to do that pk encryption... > - if i understood the protocol correctly then two sequence numbers are used: > the binding update includes a sequence number field and the cookie(mn,cn) > value too. is this really necessary? Maybe not... if I remember correctly, the sequence number of the BU was too small though. > what happens if the sequence numbers are out-of-sync (there is no protocol > for re-synchronization) Can you describe a scenario that they'd get out of sync? I _think_ this is taken into account in section 5.3.2. > - the term checksum inside the cookie should be changed to e.g. key message > digest > > - the cookie checksum (keyed message digest computation) should be done with > a standard technique e.g. HMAC-MD5 .... The actual crypto stuff isn't complete and needs work. There were some odd considerations that I can't think of off the top of my head of why a standard HMAC wasn't the right thing, (NAT traversal considerations? it was something weird). > - is the hop-by-hop option really necessary? why not to address the home > agent directly with a message? I think in the most recent version I nuked the hop-by-hop option in favor of an anycast address. > - the argumentation for the home less scenario seems to be a little bit > difficult: the main property of the home agent cookie draft is the usage of > the home agent and the shared secret between the mn and the ha. > hence i have some doubts that the homeless scenario is really useful. Useful... questionable. Inevitable... definitely. The problem is that if there isn't a HA between "MN" and CN, then the "MN" will receive the queries, etc. You can consider this a bug or a feature. The bug is if it's a non-mobile attacker trying to create bindings on CN. This scenario needs to be considered (and is in the draft). But it's also something of a feature too. Maybe not a great one, but it falls out as a natural consequence. > - if the ha is supposed to verify the cookie(mn,ha) then the binding update > should be included since the home agent may not have the full information to > reconstruct the binding update e.g. because he does not know the sequence > number included in the BU from the mn to the cn. (however if the > cookie(mn,cn) is exactly set to the same sequence > number then it may be possible - but i think that this is not described > anywhere.) Yes, I think that in the most recent version using anycast, I made the cookies stuff extensions of the BU itself. I'm not sure that that is clear in the draft, but it should be made to be clear if not. I have another draft which explicitly requires that the BU be self-describing (to use ESP for BU's). thanks, Mike From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 12 12:02:35 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11342 for ; Thu, 12 Jul 2001 12:02:35 -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 JAA17725; Thu, 12 Jul 2001 09:02:14 -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 IAA08705; Thu, 12 Jul 2001 08:55:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6CFs8R11508 for mobile-ip-dist; Thu, 12 Jul 2001 08:54:08 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6CFs5N11501 for ; Thu, 12 Jul 2001 08:54:05 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA08564 for ; Thu, 12 Jul 2001 08:54:15 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA23882 for ; Thu, 12 Jul 2001 08:54: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 IAA26661; Thu, 12 Jul 2001 08:54:14 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6CFsDq11679; Thu, 12 Jul 2001 08:54:13 -0700 X-mProtect: Thu, 12 Jul 2001 08:54:13 -0700 Nokia Silicon Valley Messaging Protection Received: from maxdialin18.iprg.nokia.com (205.226.20.248, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdsmpvuD; Thu, 12 Jul 2001 08:54:10 PDT Message-ID: <3B4DC846.C499FEEE@iprg.nokia.com> Date: Thu, 12 Jul 2001 08:54:46 -0700 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: mtanis@lucent.com CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Agent Discovery during handover References: <475FF955A05DD411980D00508B6D5FB00211A9F8@en0033exch001u.uk.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 Hello Michael, As others have pointed out, it's not a trivial question. And you are likely to get a diversity of opinions! Chip's answer points out that it is at least as difficult as choosing a route from among several alternatives. But if we assume that all routes are equally preferable except for wishing to minimize the number of registrations, and assuming that no other information is available, then there are two good strategies. 1) Pick the one with the best signal strength, making some allowance for hysteresis. 2) If signal strength is not available, then pick the newest beacon. Don't switch back to old beacons unless the newer beacons stop working. The latter strategy is called "Eager Cell Switching", and it works better than "Lazy Cell Switching" because moving bodies tend to continue moving (inertia) in the same direction. Regards, Charlie P. "Tanis, Michael (Michael)" wrote: > Hello all, > > I am currently doing my MSc project in simulating the Agent Discovery > process in OPNET. There is a critical point where the MN is receiving > advertisements from two or more Agents. What should be the reaction of the > MN? Should it start registration according to the signal power received, > according to the Lifetime field or to the services offered ? > > I would really appreciate it if someone could answer the question or point > me to the suitable document > > Thanks in advance, > > -------------------------------- > Michael Tanis > > O Lucent Technologies UMTS-SAE > Optimus Building > Windmill Hill Business Park > Swindon > Wilts SN5 6PP > United Kingdom > > Work Tel: +44 1793 897856 > Mobile : +44 7779 032004 > e-mail : mtanis@lucent.com From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 12 12:14:54 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13424 for ; Thu, 12 Jul 2001 12:14:53 -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 JAA23594; Thu, 12 Jul 2001 09:14: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 JAA04917; Thu, 12 Jul 2001 09:14:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6CGD9l11595 for mobile-ip-dist; Thu, 12 Jul 2001 09:13:09 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6CGD5N11588 for ; Thu, 12 Jul 2001 09:13:05 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA15893 for ; Thu, 12 Jul 2001 09:13:16 -0700 (PDT) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA05994 for ; Thu, 12 Jul 2001 09:13:15 -0700 (PDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id JAA16654 for ; Thu, 12 Jul 2001 09:13:14 -0700 (MST)] Received: [from m-il06-r1.mot.com (m-il06-r1.mot.com [129.188.137.193]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id JAA01771 for ; Thu, 12 Jul 2001 09:13:13 -0700 (MST)] Received: from [140.101.173.9] by m-il06-r1.mot.com with ESMTP for mobile-ip@sunroof.eng.sun.com; Thu, 12 Jul 2001 11:13:12 -0500 Received: (from root@localhost) by zorglub.crm.mot.com (8.8.8/8.8.8/crm-1.6) id SAA10241 for mobile-ip@sunroof.eng.sun.com.DELIVER; Thu, 12 Jul 2001 18:13:10 +0200 (METDST) Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by zorglub.crm.mot.com (8.8.8/8.8.8/crm-1.6) with ESMTP id SAA10180 for ; Thu, 12 Jul 2001 18:13:09 +0200 (METDST) From: petrescu@crm.mot.com To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] draft-ietf-mobileip-ipv6-14.txt References: <3B3ECBE0.85767958@iprg.nokia.com> Date: 12 Jul 2001 18:13:04 +0200 Message-Id: Lines: 55 User-Agent: Emacs Gnus 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: Hello Charlie, Regarding the IPSec story, and in order to enlighten my understanding of where the Mobile-IPv6 protocol is going to, could you please share your vue on how the -14 draft fits into an earlier proposition by one of this WG Chairs on "next steps". IIRC, it was suggested that a threat model should be first designed, then the 7 proposals should be compared against this model, then a sort of implementation team will try to implement and help confirming the chosen proposal. Have all those steps been included in the decisions taken in your draft, and if yes could you please share any small set of the reasonings here? Please advise, thanks, Alex "Charles E. Perkins" writes: > Hello folks, > > I believe that most of the current issues with Mobile IPv6 are > resolved at least to the point of some local equilibrium -- > except, of course, that we still do not know how to evaluate > security design decisions. Thus, I have supplied a newly > revised text to be distributed. It is also available at the > following URL: > http://people.nokia.net/charliep/txt/mobilev6/mobilev6.txt > > The new text is improved (thanks to Ken and T.J. and Mattias) > from the drafty version publicized a couple of weeks ago. > No major comments about the reduced reliance on AH were received, > and so I thought that the newly specified structure for the > Binding Update option was acceptable. If not, I'll happily > make whatever changes are required, including going back to > a design which relies on AH. > > There is one unsatisfied citation -- namely, the citation for > the as yet unidentifiable key distribution draft. The Mobile IPv6 > draft is completely neutral on this subject; there is only the > (currently false) assumption that some key distribution draft > does exist. > > Other changes include the new Mobile Prefix Advertisement > message for distributing prefix information to roaming mobile > nodes whenever necessary, and a scheduling algorithm for that. > Please consult the "Changes" section of the appendix for a more > complete list. > > Comments are welcome as always; please send editorial comments to > me directly, and design questions, improvements, and observations > to the list. > > Regards, > Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 12 12:42:44 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17472 for ; Thu, 12 Jul 2001 12:42:43 -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 JAA06744; Thu, 12 Jul 2001 09:42: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 JAA09676; Thu, 12 Jul 2001 09:40:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6CGdBC11679 for mobile-ip-dist; Thu, 12 Jul 2001 09:39:11 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6CGd7N11672 for ; Thu, 12 Jul 2001 09:39:07 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id JAA21027; Thu, 12 Jul 2001 09:39:18 -0700 (PDT) Message-Id: <200107121639.JAA21027@heliopolis.eng.sun.com> Date: Thu, 12 Jul 2001 09:39:18 -0700 (PDT) From: James Kempf Subject: Re: [seamoby] RE: [mobile-ip] Agent Discovery during handover To: mobile-ip@sunroof.eng.sun.com, seamoby@cdma-2000.org, Hesham.Soliman@era.ericsson.se MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 2PBHjS1ulT3OSeVku/yI2A== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 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: Hesham, The current draft focusses on AR discovery, because, from the viewpoint of an IP network, APs are transparent bridges. Of course, it possible, even likely, that APs may have an IP address but I think they would then be likely classified as hosts since they do not perform a routing function (the subnet is the same on both sides). Do you think that APs should be included? jak >Delivered-To: seamoby-list@charizard.diameter.org >From: "Hesham Soliman \(ERA\)" >To: "'mobile-ip@sunroof.eng.sun.com'" , seamoby@cdma-2000.org >Subject: [seamoby] RE: [mobile-ip] Agent Discovery during handover >Date: Thu, 12 Jul 2001 17:17:46 +0200 > >Pat, > >Is it strictly AP discovery or is it a mix of AP/AR discovery >that Seamoby is looking into ? >I think the distinction is important because the solution will >vary considerably. > >Hesham > > >> -----Original Message----- >> From: Pat Calhoun [SMTP:pcalhoun@diameter.org] >> Sent: Thursday, 12 July 2001 4:35 >> To: mobile-ip@sunroof.eng.sun.com >> Subject: Re: [mobile-ip] Agent Discovery during handover >> >> The Seamoby WG is working on defining handoff candidates discovery based >> on certain characteristics or required features. In MIP, the fact that >> you've received an agent advertisement is sufficient. >> >> So I suggest you send e-mail to the seamoby list. >> >> Thanks, >> >> PatC >> On Thu, Jul 12, 2001 at 03:14:26PM +0100, Tanis, Michael (Michael) wrote: >> > Hello all, >> > >> > I am currently doing my MSc project in simulating the Agent Discovery >> > process in OPNET. There is a critical point where the MN is receiving >> > advertisements from two or more Agents. What should be the reaction of the >> > MN? Should it start registration according to the signal power received, >> > according to the Lifetime field or to the services offered ? >> > >> > I would really appreciate it if someone could answer the question or point >> > me to the suitable document >> > >> > Thanks in advance, >> > >> > >> > -------------------------------- >> > Michael Tanis >> > >> > O Lucent Technologies UMTS-SAE >> > Optimus Building >> > Windmill Hill Business Park >> > Swindon >> > Wilts SN5 6PP >> > United Kingdom >> > >> > Work Tel: +44 1793 897856 >> > Mobile : +44 7779 032004 >> > e-mail : mtanis@lucent.com >> > From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 12 12:55:48 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA19181 for ; Thu, 12 Jul 2001 12:55:48 -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 KAA22813; Thu, 12 Jul 2001 10:55:16 -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 JAA12797; Thu, 12 Jul 2001 09:54:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6CGrr111745 for mobile-ip-dist; Thu, 12 Jul 2001 09:53:53 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6CGrnN11738 for ; Thu, 12 Jul 2001 09:53:50 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA07890 for ; Thu, 12 Jul 2001 09:54:00 -0700 (PDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA28967 for ; Thu, 12 Jul 2001 09:53:58 -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.11.0/8.11.0/WIREfire-1.3) with SMTP id f6CGrwN12469 for ; Thu, 12 Jul 2001 18:53:58 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu Jul 12 18:53:57 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Thu, 12 Jul 2001 18:53:57 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008AD4@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'James Kempf'" , mobile-ip@sunroof.eng.sun.com, seamoby@cdma-2000.org Subject: RE: [seamoby] RE: [mobile-ip] Agent Discovery during handover Date: Thu, 12 Jul 2001 18:53:54 +0200 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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: James, > The current draft focusses on AR discovery, because, from the viewpoint > of an IP network, APs are transparent bridges. > => Sounds good. > Of course, it possible, > even likely, that APs may have an IP address but I think they > would then be likely classified as hosts since they do not perform > a routing function (the subnet is the same on both sides). > => Right, either they're routers or bridges. If they're routers they're covered by what you mentioned above. > Do you think that APs should be included? > => I'm not really sure ! The APs can't always give all the necessary information anyway. If more than one AP are connected to the same AR then it might be easier to get the information from the AR. The tricky part though is how the AR will be able to send different sets of information to different nodes ! Sounds like a combination of the L2 API and the L3 information from the AR would provide the right sets of information for the MN to be able to make an intelligent decision. I haven't really gone through all y semoby mail for a while. Can you point me to the problem statement draft if it exists ? Cheers, Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 12 13:23:22 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA22874 for ; Thu, 12 Jul 2001 13:23:22 -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 KAA28169; Thu, 12 Jul 2001 10:23:07 -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 KAA19334; Thu, 12 Jul 2001 10:22:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6CHLeY11854 for mobile-ip-dist; Thu, 12 Jul 2001 10:21:40 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6CHLaN11847 for ; Thu, 12 Jul 2001 10:21:36 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id KAA23373; Thu, 12 Jul 2001 10:21:48 -0700 (PDT) Message-Id: <200107121721.KAA23373@heliopolis.eng.sun.com> Date: Thu, 12 Jul 2001 10:21:47 -0700 (PDT) From: James Kempf Subject: RE: [seamoby] RE: [mobile-ip] Agent Discovery during handover To: James.Kempf@Sun.COM, mobile-ip@sunroof.eng.sun.com, seamoby@cdma-2000.org, Hesham.Soliman@era.ericsson.se MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: BLRg72ec78jisYgkolZEtg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 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: Hesham, > => I'm not really sure ! > The APs can't always give all the necessary information > anyway. If more than one AP are connected to the same > AR then it might be easier to get the information from the > AR. The tricky part though is how the AR will be able > to send different sets of information to different nodes ! > Right, the problem is when there are APs from multiple radio technologies connected under the same AR. The AR can advertise that it has multiple radio technology APs, but there isn't really any way, within IP, for a MN or AR that wants to handoff to a different technology to do it, because all the MN or AR sees is the AR. It's different if the AR is also an AP or only has APs of a single radio technology. > Sounds like a combination of the L2 API and the L3 > information from the AR would provide the right sets > of information for the MN to be able to make an intelligent > decision. > Yes, I think that's probably so. > I haven't really gone through all y semoby mail for a while. > Can you point me to the problem statement draft if it > exists ? It hasn't been posted yet. I think Hemant will be posting it today or tomorrow. jak From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 12 13:43:58 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA25493 for ; Thu, 12 Jul 2001 13:43:57 -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 LAA03229; Thu, 12 Jul 2001 11:43: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 KAA24319; Thu, 12 Jul 2001 10:43:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6CHgfv11895 for mobile-ip-dist; Thu, 12 Jul 2001 10:42:41 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6CHgbN11888 for ; Thu, 12 Jul 2001 10:42:37 -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 KAA05365 for ; Thu, 12 Jul 2001 10:42: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 LAA06544 for ; Thu, 12 Jul 2001 11:43: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 KAA05605 for ; Thu, 12 Jul 2001 10:42:46 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6CHgjE06121 for ; Thu, 12 Jul 2001 10:42:45 -0700 X-mProtect: Thu, 12 Jul 2001 10:42:45 -0700 Nokia Silicon Valley Messaging Protection Received: from tpagtzis.iprg.nokia.com (205.226.2.115, claiming to be "cs.ucl.ac.uk") by darkstar.iprg.nokia.com(P1.5 smtpd83vArc; Thu, 12 Jul 2001 10:42:44 PDT Message-ID: <3B4DE194.CAE79D50@cs.ucl.ac.uk> Date: Thu, 12 Jul 2001 10:42:44 -0700 From: Theo Pagtzis Organization: UCL/NOKIA X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.1-STABLE i386) X-Accept-Language: el, en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [seamoby] RE: [mobile-ip] Agent Discovery during handover References: <034BEFD03799D411A59F00508BDF754603008AD4@esealnt448.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, we have been pondering on that for some time, and have come up with the decision that there exists a need to diferentiate between a mobility neighbourhood and a routing neighbourhood, in terms of APs and ARs. This is described in draft-pagtzis-mobileip-proactivev6-00.txt/.ps which is available at http://www.cs.ucl.ac.uk/staff/t.pagtzis/docs/docs.html A mobility neighbourhood actually accounts for a set of access points which a routing neighbourhood accounts for a set of routing entities. We believe that the mobility neighbourhood needs to provide information to the routing neighbourhood to effect either seamlessness or proactivity, whichever comes first. Now with respect to the AP discovery, we feel that it should be more of a configuration task where each AR is configured with details about its individual AP(s) only on a one-to-one basis The rest can be pushed through L3 from such configuration specifics over a protocol without going through an L2 API. Perhaps you want to see the draft submitted on this particular issue. It would be nice to receive your views on the matter. Theo UCL/ Mobile System "Hesham Soliman (ERA)" wrote: > > The current draft focusses on AR discovery, because, from the viewpoint > > of an IP network, APs are transparent bridges. > > > => Sounds good. > > > Of course, it possible, > > even likely, that APs may have an IP address but I think they > > would then be likely classified as hosts since they do not perform > > a routing function (the subnet is the same on both sides). > > > => Right, either they're routers or bridges. If they're routers > they're covered by what you mentioned above. > > > Do you think that APs should be included? > > > => I'm not really sure ! > The APs can't always give all the necessary information > anyway. If more than one AP are connected to the same > AR then it might be easier to get the information from the > AR. The tricky part though is how the AR will be able > to send different sets of information to different nodes ! > > Sounds like a combination of the L2 API and the L3 > information from the AR would provide the right sets > of information for the MN to be able to make an intelligent > decision. > > I haven't really gone through all y semoby mail for a while. > Can you point me to the problem statement draft if it > exists ? > > Cheers, > Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 12 14:18:52 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA00004 for ; Thu, 12 Jul 2001 14:18:51 -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 MAA27118; Thu, 12 Jul 2001 12:13: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 LAA00919; Thu, 12 Jul 2001 11:12:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6CIBmh11987 for mobile-ip-dist; Thu, 12 Jul 2001 11:11:48 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6CIBiN11980 for ; Thu, 12 Jul 2001 11:11:44 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA25473 for ; Thu, 12 Jul 2001 11:11:53 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA12851 for ; Thu, 12 Jul 2001 11:11:47 -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 LAA08111 for ; Thu, 12 Jul 2001 11:10:48 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6CIAlm22245 for ; Thu, 12 Jul 2001 11:10:47 -0700 X-mProtect: Thu, 12 Jul 2001 11:10:47 -0700 Nokia Silicon Valley Messaging Protection Received: from tpagtzis.iprg.nokia.com (205.226.2.115, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdjXGyDz; Thu, 12 Jul 2001 11:10:46 PDT Message-ID: <3B4DE827.479B63FA@iprg.nokia.com> Date: Thu, 12 Jul 2001 11:10:47 -0700 From: Theo Pagtzis Organization: UCL/NOKIA X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.1-STABLE i386) X-Accept-Language: el, en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: [Fwd: Re: [seamoby] RE: [mobile-ip] Agent Discovery during handover] 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 excuse the repost but the my mobile-ip mailer seemes not to like my UCL address -------- Original Message -------- Subject: Re: [seamoby] RE: [mobile-ip] Agent Discovery during handover Date: Thu, 12 Jul 2001 10:42:44 -0700 From: Theo Pagtzis Reply-To: mobile-ip@sunroof.eng.sun.com Organization: UCL/NOKIA To: mobile-ip@sunroof.eng.sun.com References: <034BEFD03799D411A59F00508BDF754603008AD4@esealnt448.al.sw.ericsson.se> Hello Hesham, we have been pondering on that for some time, and have come up with the decision that there exists a need to diferentiate between a mobility neighbourhood and a routing neighbourhood, in terms of APs and ARs. This is described in draft-pagtzis-mobileip-proactivev6-00.txt/.ps which is available at http://www.cs.ucl.ac.uk/staff/t.pagtzis/docs/docs.html A mobility neighbourhood actually accounts for a set of access points which a routing neighbourhood accounts for a set of routing entities. We believe that the mobility neighbourhood needs to provide information to the routing neighbourhood to effect either seamlessness or proactivity, whichever comes first. Now with respect to the AP discovery, we feel that it should be more of a configuration task where each AR is configured with details about its individual AP(s) only on a one-to-one basis The rest can be pushed through L3 from such configuration specifics over a protocol without going through an L2 API. Perhaps you want to see the draft submitted on this particular issue. It would be nice to receive your views on the matter. Theo UCL/ Mobile System "Hesham Soliman (ERA)" wrote: > > The current draft focusses on AR discovery, because, from the viewpoint > > of an IP network, APs are transparent bridges. > > > => Sounds good. > > > Of course, it possible, > > even likely, that APs may have an IP address but I think they > > would then be likely classified as hosts since they do not perform > > a routing function (the subnet is the same on both sides). > > > => Right, either they're routers or bridges. If they're routers > they're covered by what you mentioned above. > > > Do you think that APs should be included? > > > => I'm not really sure ! > The APs can't always give all the necessary information > anyway. If more than one AP are connected to the same > AR then it might be easier to get the information from the > AR. The tricky part though is how the AR will be able > to send different sets of information to different nodes ! > > Sounds like a combination of the L2 API and the L3 > information from the AR would provide the right sets > of information for the MN to be able to make an intelligent > decision. > > I haven't really gone through all y semoby mail for a while. > Can you point me to the problem statement draft if it > exists ? > > Cheers, > Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 12 15:15:50 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA09332 for ; Thu, 12 Jul 2001 15:15:49 -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 MAA21645; Thu, 12 Jul 2001 12:15:29 -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 MAA26005; Thu, 12 Jul 2001 12:15:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6CJE4O12263 for mobile-ip-dist; Thu, 12 Jul 2001 12:14:04 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6CJE1N12256 for ; Thu, 12 Jul 2001 12:14:01 -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 MAA14367 for ; Thu, 12 Jul 2001 12:14:11 -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 NAA25559 for ; Thu, 12 Jul 2001 13:15: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 MAA13605; Thu, 12 Jul 2001 12:12:38 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6CJCcC03854; Thu, 12 Jul 2001 12:12:38 -0700 X-mProtect: Thu, 12 Jul 2001 12:12:38 -0700 Nokia Silicon Valley Messaging Protection Received: from tpagtzis.iprg.nokia.com (205.226.2.115, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdIMYcnv; Thu, 12 Jul 2001 12:12:37 PDT Message-ID: <3B4DF6A5.144ED79D@iprg.nokia.com> Date: Thu, 12 Jul 2001 12:12:37 -0700 From: Theo Pagtzis Organization: UCL/NOKIA X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.1-STABLE i386) X-Accept-Language: el, en MIME-Version: 1.0 To: pcalhoun@diameter.org, mobile-ip@sunroof.eng.sun.com, seamoby@diameter.org, seamoby@cdma-2000.org Subject: [mobile-ip] Issues leading to the design of the proactive mobility draft 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 Pat/all, The issues that led to the draft specification proposed on proactive mobility (draft-pagtzis-mobileip-proactivev6-00.txt/.ps) was driven by a number of factors: 1) to effect seamlessness the MN must not wait until it reaches the overlap area between two coverage areas before it initiates generation of IP state, what we call roaming state. For irregular mobility patterns and high speed movement this is not going to be sufficient for elimination of disruption in IP 'connectivity' 1.a) since we would not like the MN to wait till the overlap area between cells is reached, we have considered that a 1-level lookahead of IP connectivity state should be sufficient for 360 degrees of movement. That is proactive allocation of roaming state. However how can you say what is around you in terms of routing entities that can provide you with this roaming context state? Thus we reached issue (2) 2) effecting a proactive mobility approach requires that the approach makes two distinctions a mobility neighbourhood - a set of coverage areas. Basically what the MN 'feels' _first_ when roving around. a routing neighbourhood - a set of routing entities. Basically what the MN 'sees' _apparently first_ when getting IP connectivity. 2.a) This requires that _no_ assumptions are made about specific routing neighbourhood topologies over a mobility neighbourhood otherwise. This why we have considered spanning tree topologies as a generich topology vehicle. 2.b) the need to establish a mapping between the mobility neighbourhood and the routing neighbourhood so that roaming state is producable proactively. 2.c) how could we take as example the generation of roaming state proactively for the generation of other context state classes/ontologies. I.e. what if it is not just roaming state that we want to know ahead of time at candidate points of attachement. 3) if roaming state is generate proactively how to proceed in mapping it in an abstract routing identifier that can determine the existence of the MN in the mobility neighbourhood of its current point of attachment. In other words, how to map a plurality of IP (soft) CoA behind an routing identifier during the period of handoff for 360 degrees. Multicast was considered as the level of indirection. Attention must be paid to the fact that such mapping is transparent to the peer entities of the MN, i.e. it is effected at the point of attachement of the MN. 4) to eliminate cell bouncing between two or more coverage areas. Movement paths for an MN depending on the mean of transport used is not usually correlated to the placement pattern of AP. Hence cell-bouncing is expected to be the first candidate of problems in seamless mobility. 5) How to manage multicast group membership indirectly with respect to mobility management issues concerning enabling of roaming state behind this abstract (CoA) routing identifier for a single MN. 6) How to manage the refresh of the roaming state for a single MN so that it stays valid throughout its mobility pattern within a mobility neighbourhood. 7) Neighbour discovery issues for indirect mobility management. These are the issues we have considered as essential in any proactive mobility design, and thus have driven the specification of this draft. Based on these issues we would like to hear what the community feels on the approaches followed. Theo From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 12 15:22:12 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA10327 for ; Thu, 12 Jul 2001 15:22:11 -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 NAA18100; Thu, 12 Jul 2001 13:21: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 MAA27323; Thu, 12 Jul 2001 12:21:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6CJKJY12296 for mobile-ip-dist; Thu, 12 Jul 2001 12:20:19 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6CJKGN12289 for ; Thu, 12 Jul 2001 12:20:16 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id MAA00166; Thu, 12 Jul 2001 12:20:26 -0700 (PDT) Message-Id: <200107121920.MAA00166@heliopolis.eng.sun.com> Date: Thu, 12 Jul 2001 12:20:25 -0700 (PDT) From: James Kempf Subject: Re: [mobile-ip] Issues leading to the design of the proactive mobility draft To: pcalhoun@diameter.org, mobile-ip@sunroof.eng.sun.com, seamoby@diameter.org, seamoby@cdma-2000.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: U6e0XNiYpNnJ7W3zkbq/FA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 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: Hi Theo, Thanx for the updates in the thought behind your draft. The draft is somewhat volumnous and will take some time to assess, but it looks quite interesting. jak >X-mProtect: Thu, 12 Jul 2001 12:12:38 -0700 Nokia Silicon Valley Messaging Protection >Date: Thu, 12 Jul 2001 12:12:37 -0700 >From: Theo Pagtzis >To: pcalhoun@diameter.org, mobile-ip@sunroof.eng.sun.com, seamoby@diameter.org, seamoby@cdma-2000.org >Subject: [mobile-ip] Issues leading to the design of the proactive mobility draft > >Hi Pat/all, > > The issues that led to the draft specification proposed on proactive >mobility >(draft-pagtzis-mobileip-proactivev6-00.txt/.ps) was driven by a number >of factors: > >1) to effect seamlessness the MN must not wait until it reaches the >overlap area between two coverage areas before it initiates generation >of IP state, what we call roaming state. For irregular mobility patterns >and high speed movement this is not going to be sufficient for >elimination of disruption in IP 'connectivity' > >1.a) since we would not like the MN to wait till the overlap area >between cells is reached, we have considered that a 1-level lookahead of >IP connectivity state should be sufficient for 360 degrees of movement. >That is proactive allocation of roaming state. > >However how can you say what is around you in terms of routing entities >that can provide you with this roaming context state? Thus we reached >issue (2) > >2) effecting a proactive mobility approach requires that the approach >makes two distinctions > > a mobility neighbourhood - a set of coverage areas. Basically what >the MN 'feels' _first_ when roving around. > a routing neighbourhood - a set of routing entities. Basically what >the MN 'sees' _apparently first_ when getting IP connectivity. > >2.a) This requires that _no_ assumptions are made about specific routing >neighbourhood topologies over a mobility neighbourhood otherwise. This >why we have considered spanning tree topologies as a generich topology >vehicle. > >2.b) the need to establish a mapping between the mobility neighbourhood >and the routing neighbourhood so that roaming state is producable >proactively. > >2.c) how could we take as example the generation of roaming state >proactively for the generation of other context state >classes/ontologies. I.e. what if it is not just roaming state that we >want to know ahead of time at candidate points of attachement. > >3) if roaming state is generate proactively how to proceed in mapping it >in an abstract routing identifier that can determine the existence of >the MN in the mobility neighbourhood of its current point of attachment. >In other words, how to map a plurality of IP (soft) CoA behind an >routing identifier during the period of handoff for 360 degrees. >Multicast was considered as the level of indirection. Attention must be >paid to the fact that such mapping is transparent to the peer entities >of the MN, i.e. it is effected at the point of attachement of the MN. > >4) to eliminate cell bouncing between two or more coverage areas. >Movement paths for an MN depending on the mean of transport used is not >usually correlated to the placement pattern of AP. Hence cell-bouncing >is expected to be the first candidate of problems in seamless mobility. > >5) How to manage multicast group membership indirectly with respect to >mobility management issues concerning enabling of roaming state behind >this abstract (CoA) routing identifier for a single MN. > >6) How to manage the refresh of the roaming state for a single MN so >that it stays valid throughout its mobility pattern within a mobility >neighbourhood. > >7) Neighbour discovery issues for indirect mobility management. > > >These are the issues we have considered as essential in any proactive >mobility design, and thus have driven the specification of this draft. >Based on these issues we would like to hear what the community feels on >the approaches followed. > > >Theo > > > From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 12 15:29:28 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA11335 for ; Thu, 12 Jul 2001 15:29: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 NAA23081; Thu, 12 Jul 2001 13:28: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 MAA28793; Thu, 12 Jul 2001 12:28:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6CJRmI12330 for mobile-ip-dist; Thu, 12 Jul 2001 12:27:48 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6CJRjN12323 for ; Thu, 12 Jul 2001 12:27: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 MAA28561 for ; Thu, 12 Jul 2001 12:27:50 -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 NAA22220 for ; Thu, 12 Jul 2001 13:27:48 -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 MAA14736 for ; Thu, 12 Jul 2001 12:27:49 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6CJRn823482 for ; Thu, 12 Jul 2001 12:27:49 -0700 X-mProtect: Thu, 12 Jul 2001 12:27:49 -0700 Nokia Silicon Valley Messaging Protection Received: from tpagtzis.iprg.nokia.com (205.226.2.115, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdzzvVnh; Thu, 12 Jul 2001 12:27:46 PDT Message-ID: <3B4DFA33.FA21BD3F@iprg.nokia.com> Date: Thu, 12 Jul 2001 12:27:47 -0700 From: Theo Pagtzis Organization: UCL/NOKIA X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.1-STABLE i386) X-Accept-Language: el, en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] [Fwd: Warning: mobile-ip-dist@zygox.com ..] Content-Type: multipart/mixed; boundary="------------43C06209F2DC9AB6D134190C" 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. --------------43C06209F2DC9AB6D134190C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi again, could somebody check what on earth is happening with the list and I receive this email all the time. I have both UCL and NOKIA addresses subscribed to be on the safe side in terms of membership but this is getting on my synapses.. Can anybody hint why this is happening or resolve the problem altogether? Thanks Theo -------- Original Message -------- Subject: Warning: mobile-ip-dist@zygox.com - User unknown! Date: Thu, 12 Jul 2001 12:36:06 -0700 From: MDaemon@zygox.com Reply-To: MDaemon@zygox.com To: tpagtzis@iprg.nokia.com mobile-ip-dist@zygox.com - no such user here. There is no user by that name at this server. : Message contains [1] file attachments --------------43C06209F2DC9AB6D134190C Content-Type: message/rfc822; name="md75000790242.md" Content-Disposition: inline; filename="md75000790242.md" Received: from pop.ncal.verio.com [129.250.37.38] by zygox.com [66.88.129.158] with DomainPOP (MDaemon.v3.5.7.R) for ; Thu, 12 Jul 2001 12:35:16 -0700 Received: from dfw-smtpin2.email.verio.net ([129.250.38.52]) by dfw-spool2.email.verio.net (Netscape Messaging Server 4.15) with ESMTP id GGDKBS04.ZQM for ; Thu, 12 Jul 2001 19:19:04 +0000 Received: from dfw-smtpout2.email.verio.net ([129.250.36.42]) by dfw-smtpin2.email.verio.net with esmtp id 15KlzL-0005D3-00 for zygoxweb@ncal.verio.com; Thu, 12 Jul 2001 19:19:03 +0000 Received: from [129.250.38.51] (helo=dfw-smtpin1.email.verio.net) by dfw-smtpout2.email.verio.net with esmtp id 15KlzL-0004Jb-00 for zygoxweb@ncal.verio.com; Thu, 12 Jul 2001 19:19:03 +0000 Received: from [192.18.98.43] (helo=patan.sun.com) by dfw-smtpin1.email.verio.net with esmtp id 15KlzL-00053J-00 for cbharath@zygox.com; Thu, 12 Jul 2001 19:19:03 +0000 Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA14924; Thu, 12 Jul 2001 13:17: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 MAA26366; Thu, 12 Jul 2001 12:17:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6CJE4O12263 for mobile-ip-dist; Thu, 12 Jul 2001 12:14:04 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6CJE1N12256 for ; Thu, 12 Jul 2001 12:14:01 -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 MAA14367 for ; Thu, 12 Jul 2001 12:14:11 -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 NAA25559 for ; Thu, 12 Jul 2001 13:15: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 MAA13605; Thu, 12 Jul 2001 12:12:38 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6CJCcC03854; Thu, 12 Jul 2001 12:12:38 -0700 X-mProtect: Thu, 12 Jul 2001 12:12:38 -0700 Nokia Silicon Valley Messaging Protection Received: from tpagtzis.iprg.nokia.com (205.226.2.115, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdIMYcnv; Thu, 12 Jul 2001 12:12:37 PDT Message-ID: <3B4DF6A5.144ED79D@iprg.nokia.com> Date: Thu, 12 Jul 2001 12:12:37 -0700 From: Theo Pagtzis Organization: UCL/NOKIA X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.1-STABLE i386) X-Accept-Language: el, en MIME-Version: 1.0 To: pcalhoun@diameter.org, mobile-ip@sunroof.eng.sun.com, seamoby@diameter.org, seamoby@cdma-2000.org Subject: [mobile-ip] Issues leading to the design of the proactive mobility draft 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: X-Envelope-To: cbharath@zygox.com X-MDRemoteIP: 129.250.37.38 X-MDRcpt-To: mobile-ip-dist@zygox.com X-MDaemon-Deliver-To: mobile-ip-dist@zygox.com Content-Transfer-Encoding: 7bit Hi Pat/all, The issues that led to the draft specification proposed on proactive mobility (draft-pagtzis-mobileip-proactivev6-00.txt/.ps) was driven by a number of factors: 1) to effect seamlessness the MN must not wait until it reaches the overlap area between two coverage areas before it initiates generation of IP state, what we call roaming state. For irregular mobility patterns and high speed movement this is not going to be sufficient for elimination of disruption in IP 'connectivity' 1.a) since we would not like the MN to wait till the overlap area between cells is reached, we have considered that a 1-level lookahead of IP connectivity state should be sufficient for 360 degrees of movement. That is proactive allocation of roaming state. However how can you say what is around you in terms of routing entities that can provide you with this roaming context state? Thus we reached issue (2) 2) effecting a proactive mobility approach requires that the approach makes two distinctions a mobility neighbourhood - a set of coverage areas. Basically what the MN 'feels' _first_ when roving around. a routing neighbourhood - a set of routing entities. Basically what the MN 'sees' _apparently first_ when getting IP connectivity. 2.a) This requires that _no_ assumptions are made about specific routing neighbourhood topologies over a mobility neighbourhood otherwise. This why we have considered spanning tree topologies as a generich topology vehicle. 2.b) the need to establish a mapping between the mobility neighbourhood and the routing neighbourhood so that roaming state is producable proactively. 2.c) how could we take as example the generation of roaming state proactively for the generation of other context state classes/ontologies. I.e. what if it is not just roaming state that we want to know ahead of time at candidate points of attachement. 3) if roaming state is generate proactively how to proceed in mapping it in an abstract routing identifier that can determine the existence of the MN in the mobility neighbourhood of its current point of attachment. In other words, how to map a plurality of IP (soft) CoA behind an routing identifier during the period of handoff for 360 degrees. Multicast was considered as the level of indirection. Attention must be paid to the fact that such mapping is transparent to the peer entities of the MN, i.e. it is effected at the point of attachement of the MN. 4) to eliminate cell bouncing between two or more coverage areas. Movement paths for an MN depending on the mean of transport used is not usually correlated to the placement pattern of AP. Hence cell-bouncing is expected to be the first candidate of problems in seamless mobility. 5) How to manage multicast group membership indirectly with respect to mobility management issues concerning enabling of roaming state behind this abstract (CoA) routing identifier for a single MN. 6) How to manage the refresh of the roaming state for a single MN so that it stays valid throughout its mobility pattern within a mobility neighbourhood. 7) Neighbour discovery issues for indirect mobility management. These are the issues we have considered as essential in any proactive mobility design, and thus have driven the specification of this draft. Based on these issues we would like to hear what the community feels on the approaches followed. Theo --------------43C06209F2DC9AB6D134190C-- From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 12 16:24:53 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA18868 for ; Thu, 12 Jul 2001 16:24: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 OAA00566; Thu, 12 Jul 2001 14:24: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 NAA05908; Thu, 12 Jul 2001 13:23:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6CKM7X12431 for mobile-ip-dist; Thu, 12 Jul 2001 13:22:07 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6CKM3N12424 for ; Thu, 12 Jul 2001 13:22:03 -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 NAA27928 for ; Thu, 12 Jul 2001 13:22:13 -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 OAA29157 for ; Thu, 12 Jul 2001 14:22:11 -0600 (MDT) Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21) id ; Thu, 12 Jul 2001 16:21:15 -0400 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] 2002bis change to Authenticator Spec Date: Thu, 12 Jul 2001 16:21:15 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) 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: The IESG notes that MD5 as used in 2002 has known weaknesses and there are better methods recommended now (e.g., HMAC). In order to transition Mobile IP implementations to the stronger method, we recommend that HMAC become mandatory, with the currently implemented MD5 a SHOULD, with text noting that it should be implemented in cases where backwards compatability is necessary. This will allow new and updated implementations to interoperate with implementations of RFC 2002, but provides a clear path for moving away from MD5 as implementations are upgraded to the revised specification. Another thing to note is that this will probably come up again when we try to move MIPv4 to Draft Standard, the new functionality causing a recycle at Proposed. Feedback requested, please. Here's the proposed new text: ----------------------------- 3.5.1. Computing Authentication Extension Values The default authentication algorithm uses HMAC-MD5 [22] to compute a 128-bit "message digest" of the registration message. The key used in the HMAC computation is the 128-bit shared secret defined by the mobility security association between the communicating nodes. The data over which the HMAC is computed is defined as: - the UDP payload (that is, the Registration Request or Registration Reply data), - all prior Extensions in their entirety, and - the Type, Length, and SPI of this Extension. Note that the Authenticator field itself and the UDP header are NOT included in the computation of the default Authenticator value. See Section 5.1 for information about support requirements for message authentication codes, which are to be used with the various authentication Extensions. The Security Parameter Index (SPI) within any of the authentication Extensions defines the security context which is used to compute the Authenticator value and which MUST be used by the receiver to check that value. In particular, the SPI selects the authentication algorithm and mode (Section 5.1) and secret (a shared key, or appropriate public/private key pair) used in computing the Authenticator. In order to ensure interoperability between different implementations of the Mobile IP protocol, an implementation MUST be able to associate any SPI value with any authentication algorithm and mode which it implements. In addition, all implementations of Mobile IP MUST implement the default authentication algorithm (HMAC-MD5) defined above. 5.1. Message Authentication Codes Home agents and mobile nodes MUST be able to perform authentication. The default algorithm is HMAC-MD5 [22], with a key size of 128 bits. The foreign agent MUST also support authentication using HMAC-MD5 and key sizes of 128 bits or greater, with manual key distribution. Keys with arbitrary binary values MUST be supported. The "prefix+suffix" use of MD5 to protect data and a shared secret is considered vulnerable to attack by the cryptographic community. Where backward compatibility with existing Mobile IP implementations that use this mode is needed, new implementations SHOULD include keyed MD5 [39] as one of the additional authentication algorithms for use when producing and verifying the authentication data that is supplied with Mobile IP registration messages, for instance in the extensions specified in sections 3.5.2, 3.5.3, and 3.5.4. The previously specified operation uses keyed-MD5 [39] in "prefix+suffix" mode to compute a 128-bit "message digest" of the registration message. The default authenticator is a 128-bit value computed as the MD5 checksum over the the following stream of bytes: - the shared secret defined by the mobility security association between the nodes and by the SPI value specified in the authentication Extension, followed by - the protected fields from the registration message, in the order specified above, followed by - the shared secret again. More authentication algorithms, algorithm modes, key distribution methods, and key sizes MAY also be supported for all of these extensions. From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 12 16:25:08 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA18909 for ; Thu, 12 Jul 2001 16:25:07 -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 NAA20156; Thu, 12 Jul 2001 13:23:56 -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 NAA05889; Thu, 12 Jul 2001 13:23:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6CKLXk12422 for mobile-ip-dist; Thu, 12 Jul 2001 13:21:33 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6CKLUN12415 for ; Thu, 12 Jul 2001 13:21:30 -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 NAA23460 for ; Thu, 12 Jul 2001 13:21:40 -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 OAA28465 for ; Thu, 12 Jul 2001 14:22:51 -0600 (MDT) Received: from mira-sjcm-3.cisco.com (mira-sjcm-3.cisco.com [171.69.24.15]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f6CKLlT04539 for ; Thu, 12 Jul 2001 13:21:48 -0700 (PDT) Received: from GDOMMETY-W2K2.cisco.com (dhcp-128-107-161-79.cisco.com [128.107.161.79]) by mira-sjcm-3.cisco.com (Mirapoint) with ESMTP id AAA00173; Thu, 12 Jul 2001 13:21:35 -0700 (PDT) Message-Id: <4.3.2.7.2.20010712132354.01e882a0@mira-sjcm-3.cisco.com> X-Sender: gdommety@mira-sjcm-3.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 12 Jul 2001 13:24:10 -0700 To: mobile-ip@sunroof.eng.sun.com From: Gopal Dommety Subject: Re: [mobile-ip] [Fwd: Warning: mobile-ip-dist@zygox.com ..] In-Reply-To: <3B4DFA33.FA21BD3F@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: send email to zygox.com -gopal At 12:27 PM 7/12/2001 -0700, you wrote: >Hi again, > > could somebody check what on earth is happening with the list and I >receive this email all the time. I have both UCL and NOKIA addresses >subscribed to be on the safe side in terms of membership but this is >getting on my synapses.. > >Can anybody hint why this is happening or resolve the problem >altogether? > >Thanks > >Theo > >-------- Original Message -------- >Subject: Warning: mobile-ip-dist@zygox.com - User unknown! >Date: Thu, 12 Jul 2001 12:36:06 -0700 >From: MDaemon@zygox.com >Reply-To: MDaemon@zygox.com >To: tpagtzis@iprg.nokia.com > >mobile-ip-dist@zygox.com - no such user here. > >There is no user by that name at this server. > >: Message contains [1] file attachmentsReceived: from pop.ncal.verio.com >[129.250.37.38] by zygox.com [66.88.129.158] > with DomainPOP (MDaemon.v3.5.7.R) > for ; Thu, 12 Jul 2001 12:35:16 -0700 >Received: from dfw-smtpin2.email.verio.net ([129.250.38.52]) by > dfw-spool2.email.verio.net (Netscape Messaging Server 4.15) with > ESMTP id GGDKBS04.ZQM for ; Thu, 12 Jul > 2001 19:19:04 +0000 >Received: from dfw-smtpout2.email.verio.net ([129.250.36.42]) > by dfw-smtpin2.email.verio.net with esmtp > id 15KlzL-0005D3-00 > for zygoxweb@ncal.verio.com; Thu, 12 Jul 2001 19:19:03 +0000 >Received: from [129.250.38.51] (helo=dfw-smtpin1.email.verio.net) > by dfw-smtpout2.email.verio.net with esmtp > id 15KlzL-0004Jb-00 > for zygoxweb@ncal.verio.com; Thu, 12 Jul 2001 19:19:03 +0000 >Received: from [192.18.98.43] (helo=patan.sun.com) > by dfw-smtpin1.email.verio.net with esmtp > id 15KlzL-00053J-00 > for cbharath@zygox.com; Thu, 12 Jul 2001 19:19:03 +0000 >Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) > by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA14924; > Thu, 12 Jul 2001 13:17: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 MAA26366; > Thu, 12 Jul 2001 12:17:18 -0700 (PDT) >Received: (from majordomo@localhost) > by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id > f6CJE4O12263 > for mobile-ip-dist; Thu, 12 Jul 2001 12:14:04 -0700 (PDT) >Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) > by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP > id f6CJE1N12256 > for ; Thu, 12 Jul 2001 12:14:01 > -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 MAA14367 > for ; Thu, 12 Jul 2001 12:14:11 > -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 NAA25559 > for ; Thu, 12 Jul 2001 13:15: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 MAA13605; > Thu, 12 Jul 2001 12:12:38 -0700 (PDT) >Received: (from root@localhost) > by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6CJCcC03854; > Thu, 12 Jul 2001 12:12:38 -0700 >X-mProtect: Thu, 12 Jul 2001 12:12:38 -0700 Nokia Silicon Valley Messaging >Protection >Received: from tpagtzis.iprg.nokia.com (205.226.2.115, claiming to be >"iprg.nokia.com") > by darkstar.iprg.nokia.com(P1.5 smtpdIMYcnv; Thu, 12 Jul 2001 > 12:12:37 PDT >Message-ID: <3B4DF6A5.144ED79D@iprg.nokia.com> >Date: Thu, 12 Jul 2001 12:12:37 -0700 >From: Theo Pagtzis >Organization: UCL/NOKIA >X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.1-STABLE i386) >X-Accept-Language: el, en >MIME-Version: 1.0 >To: pcalhoun@diameter.org, mobile-ip@sunroof.eng.sun.com, >seamoby@diameter.org, > seamoby@cdma-2000.org >Subject: [mobile-ip] Issues leading to the design of the proactive >mobility draft >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: > >X-Envelope-To: cbharath@zygox.com >X-MDRemoteIP: 129.250.37.38 >X-MDRcpt-To: mobile-ip-dist@zygox.com >X-MDaemon-Deliver-To: mobile-ip-dist@zygox.com > >Hi Pat/all, > > The issues that led to the draft specification proposed on proactive >mobility >(draft-pagtzis-mobileip-proactivev6-00.txt/.ps) was driven by a number >of factors: > >1) to effect seamlessness the MN must not wait until it reaches the >overlap area between two coverage areas before it initiates generation >of IP state, what we call roaming state. For irregular mobility patterns >and high speed movement this is not going to be sufficient for >elimination of disruption in IP 'connectivity' > >1.a) since we would not like the MN to wait till the overlap area >between cells is reached, we have considered that a 1-level lookahead of >IP connectivity state should be sufficient for 360 degrees of movement. >That is proactive allocation of roaming state. > >However how can you say what is around you in terms of routing entities >that can provide you with this roaming context state? Thus we reached >issue (2) > >2) effecting a proactive mobility approach requires that the approach >makes two distinctions > > a mobility neighbourhood - a set of coverage areas. Basically what >the MN 'feels' _first_ when roving around. > a routing neighbourhood - a set of routing entities. Basically what >the MN 'sees' _apparently first_ when getting IP connectivity. > >2.a) This requires that _no_ assumptions are made about specific routing >neighbourhood topologies over a mobility neighbourhood otherwise. This >why we have considered spanning tree topologies as a generich topology >vehicle. > >2.b) the need to establish a mapping between the mobility neighbourhood >and the routing neighbourhood so that roaming state is producable >proactively. > >2.c) how could we take as example the generation of roaming state >proactively for the generation of other context state >classes/ontologies. I.e. what if it is not just roaming state that we >want to know ahead of time at candidate points of attachement. > >3) if roaming state is generate proactively how to proceed in mapping it >in an abstract routing identifier that can determine the existence of >the MN in the mobility neighbourhood of its current point of attachment. >In other words, how to map a plurality of IP (soft) CoA behind an >routing identifier during the period of handoff for 360 degrees. >Multicast was considered as the level of indirection. Attention must be >paid to the fact that such mapping is transparent to the peer entities >of the MN, i.e. it is effected at the point of attachement of the MN. > >4) to eliminate cell bouncing between two or more coverage areas. >Movement paths for an MN depending on the mean of transport used is not >usually correlated to the placement pattern of AP. Hence cell-bouncing >is expected to be the first candidate of problems in seamless mobility. > >5) How to manage multicast group membership indirectly with respect to >mobility management issues concerning enabling of roaming state behind >this abstract (CoA) routing identifier for a single MN. > >6) How to manage the refresh of the roaming state for a single MN so >that it stays valid throughout its mobility pattern within a mobility >neighbourhood. > >7) Neighbour discovery issues for indirect mobility management. > > >These are the issues we have considered as essential in any proactive >mobility design, and thus have driven the specification of this draft. >Based on these issues we would like to hear what the community feels on >the approaches followed. > > >Theo From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 12 16:40:38 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA20940 for ; Thu, 12 Jul 2001 16:40: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 OAA12288; Thu, 12 Jul 2001 14:40: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 NAA09605; Thu, 12 Jul 2001 13:40:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6CKdPk12507 for mobile-ip-dist; Thu, 12 Jul 2001 13:39:25 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6CKdLN12500 for ; Thu, 12 Jul 2001 13:39:21 -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 NAA12709; Thu, 12 Jul 2001 13:39:32 -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 OAA06492; Thu, 12 Jul 2001 14:40:41 -0600 (MDT) Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.24.14]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f6CKdbT16593; Thu, 12 Jul 2001 13:39:37 -0700 (PDT) Received: from alpesh-u5.cisco.com (alpesh-u5.cisco.com [128.107.162.126]) by mira-sjcm-2.cisco.com (Mirapoint) with SMTP id AMX00046; Thu, 12 Jul 2001 13:39:22 -0700 (PDT) Message-Id: <200107122039.AMX00046@mira-sjcm-2.cisco.com> Date: Thu, 12 Jul 2001 13:39:22 -0700 (PDT) From: Alpesh Patel Subject: [mobile-ip] Question about draft: Generalized Key Distribution Extensions for MiP To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: xJYp4XCNcQ7O1k/FGJ6ZfQ== X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 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: Hi, I am a late follower of this draft and our team had a question about why reinvent the wheel about key distribution. I was wondering why not use IKE for Key distribution and define a new Domain of Interpretation for MobileIP? -alpesh From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 12 16:41:04 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA21001 for ; Thu, 12 Jul 2001 16:41:04 -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 NAA27399; Thu, 12 Jul 2001 13:40:31 -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 NAA09431; Thu, 12 Jul 2001 13:39:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6CKcJH12489 for mobile-ip-dist; Thu, 12 Jul 2001 13:38:20 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6CKcGN12482 for ; Thu, 12 Jul 2001 13:38:16 -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 NAA09159 for ; Thu, 12 Jul 2001 13:38:27 -0700 (PDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA05948 for ; Thu, 12 Jul 2001 14:39:37 -0600 (MDT) Received: from mira-sjcm-3.cisco.com (mira-sjcm-3.cisco.com [171.69.24.15]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f6CKcUt11621 for ; Thu, 12 Jul 2001 13:38:30 -0700 (PDT) Received: from GDOMMETY-W2K2.cisco.com (dhcp-128-107-161-79.cisco.com [128.107.161.79]) by mira-sjcm-3.cisco.com (Mirapoint) with ESMTP id AAA00596; Thu, 12 Jul 2001 13:38:20 -0700 (PDT) Message-Id: <4.3.2.7.2.20010712133853.01eda218@mira-sjcm-3.cisco.com> X-Sender: gdommety@mira-sjcm-3.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 12 Jul 2001 13:40:53 -0700 To: mobile-ip@sunroof.eng.sun.com From: Gopal Dommety Subject: Re: [mobile-ip] 2002bis change to Authenticator Spec In-Reply-To: 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 04:21 PM 7/12/2001 -0400, you wrote: >The IESG notes that MD5 as used in 2002 has known weaknesses and >there are better methods recommended now (e.g., HMAC). In order to >transition Mobile IP implementations to the stronger method, we >recommend that HMAC become mandatory, with the currently implemented >MD5 a SHOULD, with text noting that it should be implemented in cases >where backwards compatability is necessary. This will allow new and >updated implementations to interoperate with implementations of RFC >2002, but provides a clear path for moving away from MD5 as >implementations are upgraded to the revised specification. Why not have MD5 also a MUST? -Gopal >Another thing to note is that this will probably come up again when >we try to move MIPv4 to Draft Standard, the new functionality causing >a recycle at Proposed. > >Feedback requested, please. > >Here's the proposed new text: > >----------------------------- >3.5.1. Computing Authentication Extension Values > > The default authentication algorithm uses HMAC-MD5 [22] to compute > a 128-bit "message digest" of the registration message. The key > used in the HMAC computation is the 128-bit shared secret defined > by the mobility security association between the communicating > nodes. The data over which the HMAC is computed is defined as: > > - the UDP payload (that is, the Registration Request or > Registration Reply data), > > - all prior Extensions in their entirety, and > > - the Type, Length, and SPI of this Extension. > > Note that the Authenticator field itself and the UDP header are NOT > included in the computation of the default Authenticator value. > See Section 5.1 for information about support requirements for > message authentication codes, which are to be used with the various > authentication Extensions. > > The Security Parameter Index (SPI) within any of the authentication > Extensions defines the security context which is used to compute > the Authenticator value and which MUST be used by the receiver to > check that value. In particular, the SPI selects the authentication > algorithm and mode (Section 5.1) and secret (a shared key, or > appropriate public/private key pair) used in computing the > Authenticator. In order to ensure interoperability between different > implementations of the Mobile IP protocol, an implementation MUST be > able to associate any SPI value with any authentication algorithm > and mode which it implements. In addition, all implementations > of Mobile IP MUST implement the default authentication algorithm > (HMAC-MD5) defined above. > > > > >5.1. Message Authentication Codes > > Home agents and mobile nodes MUST be able to perform authentication. > The default algorithm is HMAC-MD5 [22], with a key size of 128 > bits. The foreign agent MUST also support authentication using HMAC-MD5 > and key sizes of 128 bits or greater, with manual key distribution. Keys > with arbitrary binary values MUST be supported. > > The "prefix+suffix" use of MD5 to protect data and a shared secret is >considered > vulnerable to attack by the cryptographic community. Where backward >compatibility > with existing Mobile IP implementations that use this mode is needed, > new implementations SHOULD include keyed MD5 [39] as one of the >additional > authentication algorithms for use when producing and verifying the > authentication data that is supplied with Mobile IP registration > messages, for instance in the extensions specified in sections 3.5.2, > 3.5.3, and 3.5.4. > > The previously specified operation uses keyed-MD5 [39] in > "prefix+suffix" mode to compute a 128-bit "message digest" of the > registration message. The default authenticator is a 128-bit value > computed as the MD5 checksum over the the following stream of bytes: > > - the shared secret defined by the mobility security association > between the nodes and by the SPI value specified in the > authentication Extension, followed by > > - the protected fields from the registration message, in the order > specified above, followed by > > - the shared secret again. > > More authentication algorithms, algorithm modes, key distribution >methods, > and key sizes MAY also be supported for all of these extensions. From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 12 17:16:37 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25627 for ; Thu, 12 Jul 2001 17:16:36 -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 OAA12166; Thu, 12 Jul 2001 14:15:59 -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 OAA04571; Thu, 12 Jul 2001 14:15:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6CLDrl12581 for mobile-ip-dist; Thu, 12 Jul 2001 14:13:53 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6CLDoN12574 for ; Thu, 12 Jul 2001 14:13:50 -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 OAA16591 for ; Thu, 12 Jul 2001 14:14:01 -0700 (PDT) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA22412 for ; Thu, 12 Jul 2001 15:15:13 -0600 (MDT) Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21) id ; Thu, 12 Jul 2001 17:13:03 -0400 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] 2002bis change to Authenticator Spec Date: Thu, 12 Jul 2001 17:13:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) 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: Gopal Dommety [mailto:gdommety@cisco.com] > Sent: Thursday, July 12, 2001 4:41 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] 2002bis change to Authenticator Spec > > > At 04:21 PM 7/12/2001 -0400, you wrote: > >The IESG notes that MD5 as used in 2002 has known weaknesses and > >there are better methods recommended now (e.g., HMAC). In order to > >transition Mobile IP implementations to the stronger method, we > >recommend that HMAC become mandatory, with the currently implemented > >MD5 a SHOULD, with text noting that it should be implemented in cases > >where backwards compatability is necessary. This will allow new and > >updated implementations to interoperate with implementations of RFC > >2002, but provides a clear path for moving away from MD5 as > >implementations are upgraded to the revised specification. > > > Why not have MD5 also a MUST? has known weaknesses. > > -Gopal > > > >Another thing to note is that this will probably come up again when > >we try to move MIPv4 to Draft Standard, the new functionality causing > >a recycle at Proposed. > > > >Feedback requested, please. > > > >Here's the proposed new text: > > > >----------------------------- > >3.5.1. Computing Authentication Extension Values > > > > The default authentication algorithm uses HMAC-MD5 [22] > to compute > > a 128-bit "message digest" of the registration message. The key > > used in the HMAC computation is the 128-bit shared secret defined > > by the mobility security association between the communicating > > nodes. The data over which the HMAC is computed is defined as: > > > > - the UDP payload (that is, the Registration Request or > > Registration Reply data), > > > > - all prior Extensions in their entirety, and > > > > - the Type, Length, and SPI of this Extension. > > > > Note that the Authenticator field itself and the UDP > header are NOT > > included in the computation of the default Authenticator value. > > See Section 5.1 for information about support requirements for > > message authentication codes, which are to be used with > the various > > authentication Extensions. > > > > The Security Parameter Index (SPI) within any of the > authentication > > Extensions defines the security context which is used to compute > > the Authenticator value and which MUST be used by the receiver to > > check that value. In particular, the SPI selects the > authentication > > algorithm and mode (Section 5.1) and secret (a shared key, or > > appropriate public/private key pair) used in computing the > > Authenticator. In order to ensure interoperability > between different > > implementations of the Mobile IP protocol, an > implementation MUST be > > able to associate any SPI value with any authentication algorithm > > and mode which it implements. In addition, all implementations > > of Mobile IP MUST implement the default authentication algorithm > > (HMAC-MD5) defined above. > > > > > > > > > >5.1. Message Authentication Codes > > > > Home agents and mobile nodes MUST be able to perform > authentication. > > The default algorithm is HMAC-MD5 [22], with a key size of 128 > > bits. The foreign agent MUST also support > authentication using HMAC-MD5 > > and key sizes of 128 bits or greater, with manual key > distribution. Keys > > with arbitrary binary values MUST be supported. > > > > The "prefix+suffix" use of MD5 to protect data and a > shared secret is > >considered > > vulnerable to attack by the cryptographic community. > Where backward > >compatibility > > with existing Mobile IP implementations that use this > mode is needed, > > new implementations SHOULD include keyed MD5 [39] as one of the > >additional > > authentication algorithms for use when producing and > verifying the > > authentication data that is supplied with Mobile IP registration > > messages, for instance in the extensions specified in > sections 3.5.2, > > 3.5.3, and 3.5.4. > > > > The previously specified operation uses keyed-MD5 [39] in > > "prefix+suffix" mode to compute a 128-bit "message digest" of the > > registration message. The default authenticator is a > 128-bit value > > computed as the MD5 checksum over the the following > stream of bytes: > > > > - the shared secret defined by the mobility security > association > > between the nodes and by the SPI value specified in the > > authentication Extension, followed by > > > > - the protected fields from the registration message, > in the order > > specified above, followed by > > > > - the shared secret again. > > > > More authentication algorithms, algorithm modes, key distribution > >methods, > > and key sizes MAY also be supported for all of these extensions. > From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 12 17:42:08 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA28899 for ; Thu, 12 Jul 2001 17:42:08 -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 OAA22965; Thu, 12 Jul 2001 14:42:14 -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 OAA10080; Thu, 12 Jul 2001 14:41:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6CLdr512653 for mobile-ip-dist; Thu, 12 Jul 2001 14:39:53 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.81.144] (may be forged)) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6CLdmN12646 for ; Thu, 12 Jul 2001 14:39:48 -0700 (PDT) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by jurassic.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with SMTP id f6CLdor797114 for ; Thu, 12 Jul 2001 14:39:51 -0700 (PDT) Message-Id: <200107122139.f6CLdor797114@jurassic.eng.sun.com> Date: Thu, 12 Jul 2001 17:40:22 -0400 (EDT) From: Steven Glass - Solaris Software Subject: [mobile-ip] zygox.com weirdness To: mobile-ip@sunroof.eng.sun.com X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5_11 SunOS 5.8.1 sun4u sparc Content-Type: text X-Sun-Text-Type: 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: FYI: I'm aware that MDaemon@zygox.com is returning postings with "mobile-ip-dist@zygox.com - User unknown!" (without the headers, of course). This address isn't subscribed, and I've contacted the zygox.com folks to try and track it down. Cheers, Steve your verbose mobile-ip administrator From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 12 18:29:37 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA05184 for ; Thu, 12 Jul 2001 18:29: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 QAA25267; Thu, 12 Jul 2001 16:29: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 PAA02992; Thu, 12 Jul 2001 15:29:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6CMSHV12749 for mobile-ip-dist; Thu, 12 Jul 2001 15:28:17 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6CMSDN12742 for ; Thu, 12 Jul 2001 15:28:14 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id PAA10460 for ; Thu, 12 Jul 2001 15:28:24 -0700 (PDT) Message-Id: <200107122228.PAA10460@heliopolis.eng.sun.com> Date: Thu, 12 Jul 2001 15:28:23 -0700 (PDT) From: James Kempf Subject: [mobile-ip] 01 Version of BETH Draft To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 0Xv4GQHTAgNMc9FjBwoqcg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 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: Folks, Just posted the 01 Version of the BETH draft to the IETF Drafts editor. Since the 00 deadline is tomorrow, it will probably take a while to go through the queue. I've asked Pat to post it at diameter.org, so it may be available tomorrow if Pat gets a chance to post it. Most changes are editorial. The only substantive ones are: 1) Reference to context transfer has been removed from the protocol description. It is not necessary for the protocol, though having it is a benefit. We do talk about how the protocol could benefit from context transfer. 2) The handoff smoothing section was moved to an appendix since it is ancilliary to the protocol. In the handoff smoothing section, we derive a forumla that bounds the rate of the incoming data stream, given the rate of the wireless link and the handover latency, in order to avoid propagating the handover latency into the user perceptible region. If the incoming data stream rate exceeds this bound, the user is likely to hear an artifact (for audio streams). jak From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 12 19:16:31 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA10706 for ; Thu, 12 Jul 2001 19:16: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 RAA24135; Thu, 12 Jul 2001 17:16: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 QAA13393; Thu, 12 Jul 2001 16:15:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6CNE0k12922 for mobile-ip-dist; Thu, 12 Jul 2001 16:14:00 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6CNDuN12915 for ; Thu, 12 Jul 2001 16:13:56 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA29413 for ; Thu, 12 Jul 2001 16:14:06 -0700 (PDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA12093 for ; Thu, 12 Jul 2001 16:14:06 -0700 (PDT) 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 f6CNCOB11968 for ; Thu, 12 Jul 2001 16:12:24 -0700 (PDT) Received: from cisco.com (kleung-ss20.cisco.com [128.107.162.56]) by mira-sjcm-2.cisco.com (Mirapoint) with ESMTP id AMY01797 (AUTH kleung); Thu, 12 Jul 2001 16:14:03 -0700 (PDT) Message-ID: <3B4E2F3B.6DFCE083@cisco.com> Date: Thu, 12 Jul 2001 16:14:03 -0700 From: "Kent K. Leung" X-Mailer: Mozilla 4.51 [en] (X11; U; SunOS 5.6 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] 2002bis change to Authenticator Spec 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 I agree with the need to transition to stronger authentication. But concern with backward compatibility of current deployment. Though this issue is noted in update and SHOULD is used, for implementations with only HMAC, this will cause interoperability problem since existing implementations cannot be configured with HMAC (obviously). Would using a MUST for MD5 be harmful since the strongly recommended method is HMAC anyways. For implementations that just can't do HMAC for whatever reasons, they can still interop with others (though knowingly using a weaker method). As stated in update, it's up to user to select which authentication method by the SPI. So mandating support of both methods allows users to interoperate with RFC 2002 and 2002bis implementations seamlessly. Of course, HMAC is preferred method. Kent Phil Roberts wrote: > > -----Original Message----- > > From: Gopal Dommety [mailto:gdommety@cisco.com] > > Sent: Thursday, July 12, 2001 4:41 PM > > To: mobile-ip@sunroof.eng.sun.com > > Subject: Re: [mobile-ip] 2002bis change to Authenticator Spec > > > > > > At 04:21 PM 7/12/2001 -0400, you wrote: > > >The IESG notes that MD5 as used in 2002 has known weaknesses and > > >there are better methods recommended now (e.g., HMAC). In order to > > >transition Mobile IP implementations to the stronger method, we > > >recommend that HMAC become mandatory, with the currently implemented > > >MD5 a SHOULD, with text noting that it should be implemented in cases > > >where backwards compatability is necessary. This will allow new and > > >updated implementations to interoperate with implementations of RFC > > >2002, but provides a clear path for moving away from MD5 as > > >implementations are upgraded to the revised specification. > > > > > > Why not have MD5 also a MUST? > > has known weaknesses. From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 13 06:57:59 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA17504 for ; Fri, 13 Jul 2001 06:57: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 EAA10148; Fri, 13 Jul 2001 04:58: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 DAA12163; Fri, 13 Jul 2001 03:56:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6DAtOl13727 for mobile-ip-dist; Fri, 13 Jul 2001 03:55:24 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6DAsHN13712; Fri, 13 Jul 2001 03:54:17 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA12030; Fri, 13 Jul 2001 03:54:27 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA06552; Fri, 13 Jul 2001 03:54:26 -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 GAA16750; Fri, 13 Jul 2001 06:53:35 -0400 (EDT) Message-Id: <200107131053.GAA16750@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ngtrans@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Subject: [mobile-ip] I-D ACTION:draft-engelstad-ngtrans-mipv4-over-mipv6-00.txt Date: Fri, 13 Jul 2001 06:53:34 -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. Title : Transitional Integration of Mobile IPv4 and Mobile IPv6 Author(s) : P. Engelstad Filename : draft-engelstad-ngtrans-mipv4-over-mipv6-00.txt Pages : 11 Date : 12-Jul-01 This draft outlines how Mobile IPv4 and Mobile IPv6 can work in conjunction to provide transparent L3 mobility to a dual stack mobile node. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-engelstad-ngtrans-mipv4-over-mipv6-00.txt 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-engelstad-ngtrans-mipv4-over-mipv6-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-engelstad-ngtrans-mipv4-over-mipv6-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: <20010712143753.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-engelstad-ngtrans-mipv4-over-mipv6-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-engelstad-ngtrans-mipv4-over-mipv6-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010712143753.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 13 11:39:34 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA24792 for ; Fri, 13 Jul 2001 11:39:33 -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 JAA18808; Fri, 13 Jul 2001 09:39: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 IAA00991; Fri, 13 Jul 2001 08:37:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6DFao414347 for mobile-ip-dist; Fri, 13 Jul 2001 08:36:50 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6DFakN14340 for ; Fri, 13 Jul 2001 08:36:46 -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 IAA20073 for ; Fri, 13 Jul 2001 08:36:56 -0700 (PDT) Received: from meshpdc.meshnetworks.com ([205.245.27.196]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA05827 for ; Fri, 13 Jul 2001 09:38:07 -0600 (MDT) Received: by meshpdc.meshnetworks.com with Internet Mail Service (5.5.2653.19) id <3JV1KPH8>; Fri, 13 Jul 2001 11:36:50 -0400 Message-ID: <0DF9FBC42474A24CA50F7A27FB08E0484455A1@meshpdc.meshnetworks.com> From: Phillip Neumiller To: "'Govind.Krishnamurthi@nokia.com'" , mobile-ip@sunroof.eng.sun.com Cc: seamoby@cdma-2000.org Subject: [mobile-ip] RE: [seamoby] Resend:New Draft:Issues in Candidate Access Router Discovery Date: Fri, 13 Jul 2001 11:36: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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Amazing. I am stunned. Great start! More useful comments later... One comment right now is that I have a candidate algorithm in mind (:-)), also I am again finding it difficult to see how this will work with macro-diversity since you may want to have legs across ARs in different ADs but more on that later. This draft moves MIP from blind faith to "enlightenment" a mobility renaissance is under way in the MIP WG!!! > -----Original Message----- > From: Govind.Krishnamurthi@nokia.com > [mailto:Govind.Krishnamurthi@nokia.com] > > Abstract: > Handoff in IP mobility protocols involves moving a mobile node's > Layer 3 routing reachability information from one access router to > another, before or after the mobile node has established a Layer 2 > connection with the radio access point that is covered by the new > access router. In addition, other context information about the > mobile node's packet session may be transferred from the old access > router to the new one, in order to minimize the service disruption > during the handoff process. While the exact details of how this is > accomplished vary depending on the IP mobility and seamless handoff > protocols, one common thread required for seamless handoffs is > identifying the candidate access routers for the mobile node's > handoff. When a collection of candidates has been identified, an > algorithm is run to determine the target access router, and this > router becomes the target of handoff at Layer 3. This document > presents a problem statement describing issues involved in designing > a candidate access router discovery protocol. The document does not > discuss the algorithm by which the actual target router is > identified, nor how the handoff to the target is achieved. > From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 13 12:37:13 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03411 for ; Fri, 13 Jul 2001 12:37:11 -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 JAA28388; Fri, 13 Jul 2001 09:37:18 -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 JAA18125; Fri, 13 Jul 2001 09:35:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6DGYRi14479 for mobile-ip-dist; Fri, 13 Jul 2001 09:34:27 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6DGYON14472 for ; Fri, 13 Jul 2001 09:34:24 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id JAA12932; Fri, 13 Jul 2001 09:34:34 -0700 (PDT) Message-Id: <200107131634.JAA12932@heliopolis.eng.sun.com> Date: Fri, 13 Jul 2001 09:34:34 -0700 (PDT) From: James Kempf Subject: [mobile-ip] RE: [seamoby] Resend:New Draft:Issues in Candidate Access Router Discovery To: Govind.Krishnamurthi@nokia.com, mobile-ip@sunroof.eng.sun.com, PNeumiller@MeshNetworks.com Cc: seamoby@cdma-2000.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: DgI4Au/+4HvwInDp1XKmDQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 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: Phil, Thanx for the positive comments. Regarding macrodiversity, I tend to look at it as an L2 issue. I know that in the past you've expressed a view that it can be upleveled to IP, but I'm not exactly clear what benefit that might have, especially since packet sizes in IP are large and variable. If you look at it that way, it falls more into the purview of the pwe3 working group. I've been wanting to tune in there and see whether it might not be possible to get some work going for cellular RANs, but have simply not had the time. Looking forward to seeing your protocol for CAR discovery. jak >Delivered-To: seamoby-list@charizard.diameter.org >From: Phillip Neumiller >To: "'Govind.Krishnamurthi@nokia.com'" , mobile-ip@sunroof.eng.sun.com >Cc: seamoby@cdma-2000.org >Subject: RE: [seamoby] Resend:New Draft:Issues in Candidate Access Router Discovery >Date: Fri, 13 Jul 2001 11:36:46 -0400 > >Amazing. I am stunned. Great start! More useful comments >later... One comment right now is that I have a candidate >algorithm in mind (:-)), also I am again finding it difficult >to see how this will work with macro-diversity since you may >want to have legs across ARs in different ADs but more on that >later. > >This draft moves MIP from blind faith to "enlightenment" >a mobility renaissance is under way in the MIP WG!!! > >> -----Original Message----- >> From: Govind.Krishnamurthi@nokia.com >> [mailto:Govind.Krishnamurthi@nokia.com] >> >> Abstract: >> Handoff in IP mobility protocols involves moving a mobile node's >> Layer 3 routing reachability information from one access router to >> another, before or after the mobile node has established a Layer 2 >> connection with the radio access point that is covered by the new >> access router. In addition, other context information about the >> mobile node's packet session may be transferred from the old access >> router to the new one, in order to minimize the service disruption >> during the handoff process. While the exact details of how this is >> accomplished vary depending on the IP mobility and seamless handoff >> protocols, one common thread required for seamless handoffs is >> identifying the candidate access routers for the mobile node's >> handoff. When a collection of candidates has been identified, an >> algorithm is run to determine the target access router, and this >> router becomes the target of handoff at Layer 3. This document >> presents a problem statement describing issues involved in designing >> a candidate access router discovery protocol. The document does not >> discuss the algorithm by which the actual target router is >> identified, nor how the handoff to the target is achieved. > >> From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 13 13:01:58 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA07029 for ; Fri, 13 Jul 2001 13:01:57 -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 KAA10051; Fri, 13 Jul 2001 10:02:05 -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 KAA23702; Fri, 13 Jul 2001 10:00:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6DGwxt14532 for mobile-ip-dist; Fri, 13 Jul 2001 09:58:59 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6DGwtN14521 for ; Fri, 13 Jul 2001 09:58:55 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA18501 for ; Fri, 13 Jul 2001 09:59:06 -0700 (PDT) Received: from p-mail1.cnet.fr (p-mail1.rd.francetelecom.fr [193.49.124.31]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id JAA19910 for ; Fri, 13 Jul 2001 09:59:05 -0700 (PDT) Received: by p-biset.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19) id <3ZABB9VN>; Fri, 13 Jul 2001 18:59:01 +0200 Received: from francetelecom.com (p-dico.rd.francetelecom.fr [139.100.18.135]) by p-grive.rd.francetelecom.fr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3ZBB68D4; Fri, 13 Jul 2001 18:58:56 +0200 Message-ID: <3B4F288A.43424C49@francetelecom.com> Date: Fri, 13 Jul 2001 18:57:46 +0200 From: Jean-Michel COMBES Organization: France =?iso-8859-1?Q?T=E9l=E9com?= R&D X-Mailer: Mozilla 4.75 [fr] (Windows NT 5.0; U) X-Accept-Language: fr MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] new draft References: <034BEFD03799D411A59F00508BDF754603008AE1@esealnt448.al.sw.ericsson.se> 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: X-MIME-Autoconverted: from 8bit to quoted-printable by mercury.Sun.COM id KAA10051 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA07029 Hi, Such a BU sub-options management needs some modifications (ie. adding new fields : flow label, dest port, prot number, ...) in the Binding Cache List structure, doesn't it ? If so, I think it should be necessary to describe them in the draft. Regards. JMC. "Hesham Soliman (ERA)" a écrit : > Folks, > > Based on the comments on load balancing in > HMIPv6 and the interest expressed by some, > we've submitted a separate short draft on flow movement > in MIPv6. The draft is generic and is not tied to HMIPv6 > only. The load balancing section will be taken out > of HMIPv6 and a new revision will be submitted next week. > > Until the draft is announced you can find it in: > http://standards.ericsson.net/Hesham/draft-soliman-mobileip-flow-move-00.txt > > Comments are welcome. > > Cheers, > Hesham -- 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 From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 13 13:07:34 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA07792 for ; Fri, 13 Jul 2001 13:07:34 -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 LAA26183; Fri, 13 Jul 2001 11:06: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 KAA24799; Fri, 13 Jul 2001 10:05:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6DH4LW14577 for mobile-ip-dist; Fri, 13 Jul 2001 10:04:21 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6DH4IN14570 for ; Fri, 13 Jul 2001 10:04:18 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA19957 for ; Fri, 13 Jul 2001 10:04:29 -0700 (PDT) Received: from netmail2.alcatel.com (netmail2.alcatel.com [128.251.168.51]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA20217 for ; Fri, 13 Jul 2001 10:04:28 -0700 (PDT) Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80]) by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id MAA02497; Fri, 13 Jul 2001 12:04:23 -0500 (CDT) Received: from usa.alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f6DH4N006516; Fri, 13 Jul 2001 12:04:23 -0500 (CDT) Message-ID: <3B4F2A46.44626A68@usa.alcatel.com> Date: Fri, 13 Jul 2001 12:05:10 -0500 From: Behcet Sarikaya Organization: Alcatel USA X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com CC: Govind.Krishnamurthi@nokia.com, PNeumiller@MeshNetworks.com, seamoby@cdma-2000.org Subject: Re: [mobile-ip] RE: [seamoby] Resend:New Draft:Issues in Candidate Access Router Discovery References: <200107131634.JAA12932@heliopolis.eng.sun.com> Content-Type: multipart/alternative; boundary="------------2EF20710B1BF3CBE7F983F22" 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: --------------2EF20710B1BF3CBE7F983F22 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Jim, Has this work been triggered by an email from Micheal Tanis? Since router discovery is of routing area, does your draft fall in seamoby 's charter? Just asking. James Kempf wrote: > Phil, > > Thanx for the positive comments. > > Regarding macrodiversity, I tend to look at it as an L2 issue. I know > that in the past you've expressed a view that it can be upleveled > to IP, but I'm not exactly clear what benefit that might have, especially > since packet sizes in IP are large and variable. > > If you look at it that way, it falls more into the purview of the > pwe3 working group. I've been wanting to tune in there and see whether > it might not be possible to get some work going for cellular RANs, > but have simply not had the time. > > Looking forward to seeing your protocol for CAR discovery. > > jak > > >Delivered-To: seamoby-list@charizard.diameter.org > >From: Phillip Neumiller > >To: "'Govind.Krishnamurthi@nokia.com'" , > mobile-ip@sunroof.eng.sun.com > >Cc: seamoby@cdma-2000.org > >Subject: RE: [seamoby] Resend:New Draft:Issues in Candidate Access Router > Discovery > >Date: Fri, 13 Jul 2001 11:36:46 -0400 > > > >Amazing. I am stunned. Great start! More useful comments > >later... One comment right now is that I have a candidate > >algorithm in mind (:-)), also I am again finding it difficult > >to see how this will work with macro-diversity since you may > >want to have legs across ARs in different ADs but more on that > >later. > > > >This draft moves MIP from blind faith to "enlightenment" > >a mobility renaissance is under way in the MIP WG!!! > > > >> -----Original Message----- > >> From: Govind.Krishnamurthi@nokia.com > >> [mailto:Govind.Krishnamurthi@nokia.com] > >> > >> Abstract: > >> Handoff in IP mobility protocols involves moving a mobile node's > >> Layer 3 routing reachability information from one access router to > >> another, before or after the mobile node has established a Layer 2 > >> connection with the radio access point that is covered by the new > >> access router. In addition, other context information about the > >> mobile node's packet session may be transferred from the old access > >> router to the new one, in order to minimize the service disruption > >> during the handoff process. While the exact details of how this is > >> accomplished vary depending on the IP mobility and seamless handoff > >> protocols, one common thread required for seamless handoffs is > >> identifying the candidate access routers for the mobile node's > >> handoff. When a collection of candidates has been identified, an > >> algorithm is run to determine the target access router, and this > >> router becomes the target of handoff at Layer 3. This document > >> presents a problem statement describing issues involved in designing > >> a candidate access router discovery protocol. The document does not > >> discuss the algorithm by which the actual target router is > >> identified, nor how the handoff to the target is achieved. > > > >> -- Behcet --------------2EF20710B1BF3CBE7F983F22 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Jim,
  Has this work been triggered by an email from Micheal Tanis?
Since router discovery is of routing area, does your draft fall in seamoby 's charter?

Just asking.

James Kempf wrote:

Phil,

Thanx for the positive comments.

Regarding macrodiversity, I tend to look at it as an L2 issue. I know
that in the past you've expressed a view that it can be upleveled
to IP, but I'm not exactly clear what benefit that might have, especially
since packet sizes in IP are large and variable.

If you look at it that way, it falls more into the purview of the
pwe3 working group. I've been wanting to tune in there and see whether
it might not be possible to get some work going for cellular RANs,
but have simply not had the time.

Looking forward to seeing your protocol for CAR discovery.

                jak

>Delivered-To: seamoby-list@charizard.diameter.org
>From: Phillip Neumiller <PNeumiller@MeshNetworks.com>
>To: "'Govind.Krishnamurthi@nokia.com'" <Govind.Krishnamurthi@nokia.com>,
mobile-ip@sunroof.eng.sun.com
>Cc: seamoby@cdma-2000.org
>Subject: RE: [seamoby] Resend:New Draft:Issues in Candidate Access Router
Discovery
>Date: Fri, 13 Jul 2001 11:36:46 -0400
>
>Amazing.  I am stunned.  Great start!  More useful comments
>later...  One comment right now is that I have a candidate
>algorithm in mind (:-)), also I am again finding it difficult
>to see how this will work with macro-diversity since you may
>want to have legs across ARs in different ADs but more on that
>later.
>
>This draft moves MIP from blind faith to "enlightenment"
>a mobility renaissance is under way in the MIP WG!!!
>
>> -----Original Message-----
>> From: Govind.Krishnamurthi@nokia.com
>> [mailto:Govind.Krishnamurthi@nokia.com]
>>
>> Abstract:
>> Handoff in IP mobility protocols involves moving a mobile node's
>> Layer 3 routing reachability information from one access router to
>> another, before or after the mobile node has established a Layer 2
>> connection with the radio access point that is covered by the new
>> access router. In addition, other context information about the
>> mobile node's packet session may be transferred from the old access
>> router to the new one, in order to minimize the service disruption
>> during the handoff process. While the exact details of how this is
>> accomplished vary depending on the IP mobility and seamless handoff
>> protocols, one common thread required for seamless handoffs is
>> identifying the candidate access routers for the mobile node's
>> handoff. When a collection of candidates has been identified, an
>> algorithm is run to determine the target access router, and this
>> router becomes the target of handoff at Layer 3. This document
>> presents a problem statement describing issues involved in designing
>> a candidate access router discovery protocol. The document does not
>> discuss the algorithm by which the actual target router is
>> identified, nor how the handoff to the target is achieved.
>
>>

--
Behcet --------------2EF20710B1BF3CBE7F983F22-- From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 13 13:12:02 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08528 for ; Fri, 13 Jul 2001 13:12:01 -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 KAA14720; Fri, 13 Jul 2001 10:11:21 -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 KAA26086; Fri, 13 Jul 2001 10:09:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6DH8r314646 for mobile-ip-dist; Fri, 13 Jul 2001 10:08:53 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6DH8oN14639 for ; Fri, 13 Jul 2001 10:08:50 -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 KAA25797 for ; Fri, 13 Jul 2001 10:09:00 -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 LAA27723 for ; Fri, 13 Jul 2001 11:08: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 KAA22128; Fri, 13 Jul 2001 10:08:22 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6DH8Lx03508; Fri, 13 Jul 2001 10:08:21 -0700 X-mProtect: Fri, 13 Jul 2001 10:08:21 -0700 Nokia Silicon Valley Messaging Protection Received: from tpagtzis.iprg.nokia.com (205.226.2.115, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdY1nROf; Fri, 13 Jul 2001 10:08:19 PDT Message-ID: <3B4F2B04.157F3F97@iprg.nokia.com> Date: Fri, 13 Jul 2001 10:08:20 -0700 From: Theo Pagtzis Organization: UCL/NOKIA X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.1-STABLE i386) X-Accept-Language: el, en MIME-Version: 1.0 To: "Govind.Krishnamurthi" CC: mobile-ip , seamoby , seamoby-context Subject: [mobile-ip] Re: [seamoby-context] Resend:New Draft:Issues in Candidate Access Router Discovery 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 Govind, I have already provided a detailed protocol on pessimistic and optimistic proactivity in terms of router neighbour determination and candidacy. Please see draft-pagtzis-mobileip-proactivev6-00.txt/.ps I have also gone a long way in specifying the notions of mobility and routing neighbourhood as well as provide an algorithm for their determination. My proactive mobility scheme contains as part of it, exactly what you are describing as very briefly as physical neighbourhood and its mapping to a routing neighbourhood. There are however much more issues that are not elaborated in the targer AR determination. These are also covered in the draft on proactive mobility. Also what is the date of your submission? Here your draft says it is July 2001. But what day? Theo UCL/ Mobile Systems "Govind.Krishnamurthi" wrote: > I'm resending the draft to the mailing list as I did not see it appear > in the archives. Sorry if you receive multiple copies. > BRs, > Govind. > > Abstract: > Handoff in IP mobility protocols involves moving a mobile node's > Layer 3 routing reachability information from one access router to > another, before or after the mobile node has established a Layer 2 > connection with the radio access point that is covered by the new > access router. In addition, other context information about the > mobile node's packet session may be transferred from the old access > router to the new one, in order to minimize the service disruption > during the handoff process. While the exact details of how this is > accomplished vary depending on the IP mobility and seamless handoff > protocols, one common thread required for seamless handoffs is > identifying the candidate access routers for the mobile node's > handoff. When a collection of candidates has been identified, an > algorithm is run to determine the target access router, and this > router becomes the target of handoff at Layer 3. This document > presents a problem statement describing issues involved in designing > a candidate access router discovery protocol. The document does not > discuss the algorithm by which the actual target router is > identified, nor how the handoff to the target is achieved. > > Comments are welcome. > > Best Regards, > Govind. > > <> > > ------------------------------------------------------------------------ > Name: draft-ietf-seamoby-CARdiscovery-issues-00.txt > draft-ietf-seamoby-CARdiscovery-issues-00.txt Type: Plain Text (text/plain) > Encoding: base64 > Description: draft-ietf-seamoby-CARdiscovery-issues-00.txt From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 13 13:12:57 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08683 for ; Fri, 13 Jul 2001 13:12:56 -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 LAA01077; Fri, 13 Jul 2001 11:12: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 KAA26463; Fri, 13 Jul 2001 10:11:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6DHA3X14664 for mobile-ip-dist; Fri, 13 Jul 2001 10:10:03 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6DH9xN14657 for ; Fri, 13 Jul 2001 10:09:59 -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 KAA08970 for ; Fri, 13 Jul 2001 10:10:10 -0700 (PDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA28727 for ; Fri, 13 Jul 2001 11:10:07 -0600 (MDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f6DHA7N02393 for ; Fri, 13 Jul 2001 19:10:08 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Fri Jul 13 19:10:07 2001 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 13 Jul 2001 19:04:10 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008AE5@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] new draft Date: Fri, 13 Jul 2001 19:10:02 +0200 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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > Such a BU sub-options management needs some modifications (ie. adding new fields > : flow label, dest port, prot number, ...) in the Binding Cache List structure, > doesn't it ? > If so, I think it should be necessary to describe them in the draft. > => Yes I agree, we have to do that. I've put it in the appendix for the next revision. The deadline came too fast :( Hesham From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 13 13:14:57 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08944 for ; Fri, 13 Jul 2001 13:14: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 LAA02236; Fri, 13 Jul 2001 11:14: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 KAA26833; Fri, 13 Jul 2001 10:12:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6DHBjT14694 for mobile-ip-dist; Fri, 13 Jul 2001 10:11:45 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6DHBgN14687 for ; Fri, 13 Jul 2001 10:11:42 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id KAA14813; Fri, 13 Jul 2001 10:11:53 -0700 (PDT) Message-Id: <200107131711.KAA14813@heliopolis.eng.sun.com> Date: Fri, 13 Jul 2001 10:11:53 -0700 (PDT) From: James Kempf Subject: Re: [mobile-ip] RE: [seamoby] Resend:New Draft:Issues in Candidate Access Router Discovery To: mobile-ip@sunroof.eng.sun.com Cc: Govind.Krishnamurthi@nokia.com, PNeumiller@MeshNetworks.com, seamoby@cdma-2000.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 9jjQPyLgI5PY/8Aajab+Ig== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 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: Behcet, Please see the Seamoby charter at http://www.ietf.org/html.charters/seamoby-charter.html. Handoff candidate discovery is part of the charter. jak >Date: Fri, 13 Jul 2001 12:05:10 -0500 >From: Behcet Sarikaya >To: mobile-ip@sunroof.eng.sun.com >CC: Govind.Krishnamurthi@nokia.com, PNeumiller@MeshNetworks.com, seamoby@cdma-2000.org >Subject: Re: [mobile-ip] RE: [seamoby] Resend:New Draft:Issues in Candidate Access Router Discovery > >Hi Jim, > Has this work been triggered by an email from Micheal Tanis? >Since router discovery is of routing area, does your draft fall in seamoby 's >charter? > >Just asking. > >James Kempf wrote: > >> Phil, >> >> Thanx for the positive comments. >> >> Regarding macrodiversity, I tend to look at it as an L2 issue. I know >> that in the past you've expressed a view that it can be upleveled >> to IP, but I'm not exactly clear what benefit that might have, especially >> since packet sizes in IP are large and variable. >> >> If you look at it that way, it falls more into the purview of the >> pwe3 working group. I've been wanting to tune in there and see whether >> it might not be possible to get some work going for cellular RANs, >> but have simply not had the time. >> >> Looking forward to seeing your protocol for CAR discovery. >> >> jak >> >> >Delivered-To: seamoby-list@charizard.diameter.org >> >From: Phillip Neumiller >> >To: "'Govind.Krishnamurthi@nokia.com'" , >> mobile-ip@sunroof.eng.sun.com >> >Cc: seamoby@cdma-2000.org >> >Subject: RE: [seamoby] Resend:New Draft:Issues in Candidate Access Router >> Discovery >> >Date: Fri, 13 Jul 2001 11:36:46 -0400 >> > >> >Amazing. I am stunned. Great start! More useful comments >> >later... One comment right now is that I have a candidate >> >algorithm in mind (:-)), also I am again finding it difficult >> >to see how this will work with macro-diversity since you may >> >want to have legs across ARs in different ADs but more on that >> >later. >> > >> >This draft moves MIP from blind faith to "enlightenment" >> >a mobility renaissance is under way in the MIP WG!!! >> > >> >> -----Original Message----- >> >> From: Govind.Krishnamurthi@nokia.com >> >> [mailto:Govind.Krishnamurthi@nokia.com] >> >> >> >> Abstract: >> >> Handoff in IP mobility protocols involves moving a mobile node's >> >> Layer 3 routing reachability information from one access router to >> >> another, before or after the mobile node has established a Layer 2 >> >> connection with the radio access point that is covered by the new >> >> access router. In addition, other context information about the >> >> mobile node's packet session may be transferred from the old access >> >> router to the new one, in order to minimize the service disruption >> >> during the handoff process. While the exact details of how this is >> >> accomplished vary depending on the IP mobility and seamless handoff >> >> protocols, one common thread required for seamless handoffs is >> >> identifying the candidate access routers for the mobile node's >> >> handoff. When a collection of candidates has been identified, an >> >> algorithm is run to determine the target access router, and this >> >> router becomes the target of handoff at Layer 3. This document >> >> presents a problem statement describing issues involved in designing >> >> a candidate access router discovery protocol. The document does not >> >> discuss the algorithm by which the actual target router is >> >> identified, nor how the handoff to the target is achieved. >> > >> >> > >-- >Behcet From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 13 13:21:37 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09967 for ; Fri, 13 Jul 2001 13:21:36 -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 KAA20022; Fri, 13 Jul 2001 10:21: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 KAA11170; Fri, 13 Jul 2001 10:20:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6DHJD314820 for mobile-ip-dist; Fri, 13 Jul 2001 10:19:13 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6DHJAN14813 for ; Fri, 13 Jul 2001 10:19:10 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id KAA15138; Fri, 13 Jul 2001 10:19:21 -0700 (PDT) Message-Id: <200107131719.KAA15138@heliopolis.eng.sun.com> Date: Fri, 13 Jul 2001 10:19:21 -0700 (PDT) From: James Kempf Subject: Re: [mobile-ip] Re: [seamoby-context] Resend:New Draft:Issues in Candidate Access Router Discovery To: Govind.Krishnamurthi@nokia.com, mobile-ip@sunroof.eng.sun.com Cc: mobile-ip@sunroof.eng.sun.com, seamoby@cdma-2000.org, seamoby-context@cdma-2000.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: cTwaRwSufd3liw7gxohsGw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 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: Theo, While it looks like your proactive draft has lots of good stuff in it, since I've stopped doing international flights regularly, I don't have large blocks of time for sitting still. So it may be hard to go through the whole thing quickly, and I suspect that might be true for others as well. What I would like to suggest you may want to think about is to carve out a few nuggets, like, for example, the CAR discovery protocol, and put them into separate drafts, perhaps after IETF 51. Also, if you think you've got some good stuff on requirements for CAR discovery (what the draft that Govind et. al. wrote) is all about, then maybe we can get together at IETF and talk about folding them into the CAR discovery draft if they haven't already been covered, or even though the mailing list. The CAR discovery draft is just at 00 now, and that must go through WG last call and IESG last call before the requirements are agreed to, so there is plenty of time. jak >X-mProtect: Fri, 13 Jul 2001 10:08:21 -0700 Nokia Silicon Valley Messaging Protection >Date: Fri, 13 Jul 2001 10:08:20 -0700 >From: Theo Pagtzis >To: "Govind.Krishnamurthi" >CC: mobile-ip , seamoby , seamoby-context >Subject: [mobile-ip] Re: [seamoby-context] Resend:New Draft:Issues in Candidate Access Router Discovery > >Govind, > > I have already provided a detailed protocol on pessimistic and optimistic proactivity in >terms of router neighbour determination and candidacy. Please see >draft-pagtzis-mobileip-proactivev6-00.txt/.ps > >I have also gone a long way in specifying the notions of mobility and routing neighbourhood as well as >provide an algorithm for their determination. > >My proactive mobility scheme contains as part of it, exactly what you are describing as very briefly as >physical neighbourhood and its mapping to a routing neighbourhood. There are however much more issues that >are not elaborated in the targer AR determination. These are also covered in the draft on proactive mobility. > >Also what is the date of your submission? Here your draft says it is July 2001. But what day? > > >Theo > >UCL/ Mobile Systems > > >"Govind.Krishnamurthi" wrote: > >> I'm resending the draft to the mailing list as I did not see it appear >> in the archives. Sorry if you receive multiple copies. >> BRs, >> Govind. >> >> Abstract: >> Handoff in IP mobility protocols involves moving a mobile node's >> Layer 3 routing reachability information from one access router to >> another, before or after the mobile node has established a Layer 2 >> connection with the radio access point that is covered by the new >> access router. In addition, other context information about the >> mobile node's packet session may be transferred from the old access >> router to the new one, in order to minimize the service disruption >> during the handoff process. While the exact details of how this is >> accomplished vary depending on the IP mobility and seamless handoff >> protocols, one common thread required for seamless handoffs is >> identifying the candidate access routers for the mobile node's >> handoff. When a collection of candidates has been identified, an >> algorithm is run to determine the target access router, and this >> router becomes the target of handoff at Layer 3. This document >> presents a problem statement describing issues involved in designing >> a candidate access router discovery protocol. The document does not >> discuss the algorithm by which the actual target router is >> identified, nor how the handoff to the target is achieved. >> >> Comments are welcome. >> >> Best Regards, >> Govind. >> >> <> >> >> ------------------------------------------------------------------------ >> Name: draft-ietf-seamoby-CARdiscovery-issues-00.txt >> draft-ietf-seamoby-CARdiscovery-issues-00.txt Type: Plain Text (text/plain) >> Encoding: base64 >> Description: draft-ietf-seamoby-CARdiscovery-issues-00.txt > From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 13 13:24:21 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA10313 for ; Fri, 13 Jul 2001 13:24:20 -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 LAA10504; Fri, 13 Jul 2001 11:24: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 KAA11899; Fri, 13 Jul 2001 10:22:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6DHLx014901 for mobile-ip-dist; Fri, 13 Jul 2001 10:21:59 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6DHLtN14894 for ; Fri, 13 Jul 2001 10:21:55 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA11588 for ; Fri, 13 Jul 2001 10:22:07 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA00424 for ; Fri, 13 Jul 2001 10:22:06 -0700 (PDT) Received: from mira-sjcm-3.cisco.com (mira-sjcm-3.cisco.com [171.69.24.15]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f6DHM3K25194 for ; Fri, 13 Jul 2001 10:22:05 -0700 (PDT) Received: from GDOMMETY-W2K2.cisco.com (gdommety-dsl4.cisco.com [10.19.17.141]) by mira-sjcm-3.cisco.com (Mirapoint) with ESMTP id AAH06050; Fri, 13 Jul 2001 10:21:53 -0700 (PDT) Message-Id: <4.3.2.7.2.20010713101525.03475f08@mira-sjcm-3.cisco.com> X-Sender: gdommety@mira-sjcm-3.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 13 Jul 2001 10:24:18 -0700 To: mobile-ip@sunroof.eng.sun.com, "'mobile-ip@sunroof.eng.sun.com'" From: Gopal Dommety Subject: RE: [mobile-ip] 2002bis change to Authenticator Spec In-Reply-To: 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 05:13 PM 7/12/2001 -0400, Phil Roberts wrote: > > -----Original Message----- > > From: Gopal Dommety [mailto:gdommety@cisco.com] > > Sent: Thursday, July 12, 2001 4:41 PM > > To: mobile-ip@sunroof.eng.sun.com > > Subject: Re: [mobile-ip] 2002bis change to Authenticator Spec > > > > > > At 04:21 PM 7/12/2001 -0400, you wrote: > > >The IESG notes that MD5 as used in 2002 has known weaknesses and > > >there are better methods recommended now (e.g., HMAC). In order to > > >transition Mobile IP implementations to the stronger method, we > > >recommend that HMAC become mandatory, with the currently implemented > > >MD5 a SHOULD, with text noting that it should be implemented in cases > > >where backwards compatability is necessary. This will allow new and > > >updated implementations to interoperate with implementations of RFC > > >2002, but provides a clear path for moving away from MD5 as > > >implementations are upgraded to the revised specification. > > > > > > Why not have MD5 also a MUST? > >has known weaknesses. Recommending that both be implemented will take care of the future and the past. Sometime later when HMAC is implemented by every one, we can change the recommendation. -Gopal PS: on a lighter side, Security Algos are secure till some known weakness and it is a matter of time that a weakness is found. > > > > -Gopal > > > > > > >Another thing to note is that this will probably come up again when > > >we try to move MIPv4 to Draft Standard, the new functionality causing > > >a recycle at Proposed. > > > > > >Feedback requested, please. > > > > > >Here's the proposed new text: > > > > > >----------------------------- > > >3.5.1. Computing Authentication Extension Values > > > > > > The default authentication algorithm uses HMAC-MD5 [22] > > to compute > > > a 128-bit "message digest" of the registration message. The key > > > used in the HMAC computation is the 128-bit shared secret defined > > > by the mobility security association between the communicating > > > nodes. The data over which the HMAC is computed is defined as: > > > > > > - the UDP payload (that is, the Registration Request or > > > Registration Reply data), > > > > > > - all prior Extensions in their entirety, and > > > > > > - the Type, Length, and SPI of this Extension. > > > > > > Note that the Authenticator field itself and the UDP > > header are NOT > > > included in the computation of the default Authenticator value. > > > See Section 5.1 for information about support requirements for > > > message authentication codes, which are to be used with > > the various > > > authentication Extensions. > > > > > > The Security Parameter Index (SPI) within any of the > > authentication > > > Extensions defines the security context which is used to compute > > > the Authenticator value and which MUST be used by the receiver to > > > check that value. In particular, the SPI selects the > > authentication > > > algorithm and mode (Section 5.1) and secret (a shared key, or > > > appropriate public/private key pair) used in computing the > > > Authenticator. In order to ensure interoperability > > between different > > > implementations of the Mobile IP protocol, an > > implementation MUST be > > > able to associate any SPI value with any authentication algorithm > > > and mode which it implements. In addition, all implementations > > > of Mobile IP MUST implement the default authentication algorithm > > > (HMAC-MD5) defined above. > > > > > > > > > > > > > > >5.1. Message Authentication Codes > > > > > > Home agents and mobile nodes MUST be able to perform > > authentication. > > > The default algorithm is HMAC-MD5 [22], with a key size of 128 > > > bits. The foreign agent MUST also support > > authentication using HMAC-MD5 > > > and key sizes of 128 bits or greater, with manual key > > distribution. Keys > > > with arbitrary binary values MUST be supported. > > > > > > The "prefix+suffix" use of MD5 to protect data and a > > shared secret is > > >considered > > > vulnerable to attack by the cryptographic community. > > Where backward > > >compatibility > > > with existing Mobile IP implementations that use this > > mode is needed, > > > new implementations SHOULD include keyed MD5 [39] as one of the > > >additional > > > authentication algorithms for use when producing and > > verifying the > > > authentication data that is supplied with Mobile IP registration > > > messages, for instance in the extensions specified in > > sections 3.5.2, > > > 3.5.3, and 3.5.4. > > > > > > The previously specified operation uses keyed-MD5 [39] in > > > "prefix+suffix" mode to compute a 128-bit "message digest" of the > > > registration message. The default authenticator is a > > 128-bit value > > > computed as the MD5 checksum over the the following > > stream of bytes: > > > > > > - the shared secret defined by the mobility security > > association > > > between the nodes and by the SPI value specified in the > > > authentication Extension, followed by > > > > > > - the protected fields from the registration message, > > in the order > > > specified above, followed by > > > > > > - the shared secret again. > > > > > > More authentication algorithms, algorithm modes, key distribution > > >methods, > > > and key sizes MAY also be supported for all of these extensions. > > From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 13 13:27:33 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA10735 for ; Fri, 13 Jul 2001 13:27: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 LAA13065; Fri, 13 Jul 2001 11:27:41 -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 KAA12698; Fri, 13 Jul 2001 10:26:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6DHP7414957 for mobile-ip-dist; Fri, 13 Jul 2001 10:25:07 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6DHP4N14948 for ; Fri, 13 Jul 2001 10:25:04 -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 KAA29780 for ; Fri, 13 Jul 2001 10:25:15 -0700 (PDT) Received: from p-mail2.cnet.fr (p-mail2.rd.francetelecom.fr [193.49.124.32]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id LAA11003 for ; Fri, 13 Jul 2001 11:25:12 -0600 (MDT) Received: by p-voyageur.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19) id <3ZA2VV0Q>; Fri, 13 Jul 2001 19:25:12 +0200 Received: from francetelecom.com (p-dico.rd.francetelecom.fr [139.100.18.135]) by p-grive.rd.francetelecom.fr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3ZBB68DY; Fri, 13 Jul 2001 19:25:06 +0200 Message-ID: <3B4F2EAC.7EA01208@francetelecom.com> Date: Fri, 13 Jul 2001 19:23:56 +0200 From: Jean-Michel COMBES Organization: France =?iso-8859-1?Q?T=E9l=E9com?= R&D X-Mailer: Mozilla 4.75 [fr] (Windows NT 5.0; U) X-Accept-Language: fr MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] new draft References: <034BEFD03799D411A59F00508BDF754603008AE5@esealnt448.al.sw.ericsson.se> 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: X-MIME-Autoconverted: from 8bit to quoted-printable by patan.sun.com id LAA13065 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA10735 BTW, it would be practice to define a Binding Update Policy Database too. JMC. "Hesham Soliman (ERA)" a écrit : > > Such a BU sub-options management needs some modifications (ie. adding new fields > > : flow label, dest port, prot number, ...) in the Binding Cache List structure, > > doesn't it ? > > If so, I think it should be necessary to describe them in the draft. > > > => Yes I agree, we have to do that. I've put it in the appendix > for the next revision. The deadline came too fast :( > > Hesham -- 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 From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 13 13:29:39 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11016 for ; Fri, 13 Jul 2001 13:29: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 LAA14948; Fri, 13 Jul 2001 11:29:49 -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 KAA13391; Fri, 13 Jul 2001 10:28:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6DHRVx14995 for mobile-ip-dist; Fri, 13 Jul 2001 10:27:31 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6DHRSN14988 for ; Fri, 13 Jul 2001 10:27:28 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA13195 for ; Fri, 13 Jul 2001 10:27:39 -0700 (PDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id KAA03504 for ; Fri, 13 Jul 2001 10:27:37 -0700 (PDT) Received: (qmail 31149 invoked by uid 500); 13 Jul 2001 17:14:00 -0000 Date: Fri, 13 Jul 2001 10:14:00 -0700 From: Pat Calhoun To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Question about draft: Generalized Key Distribution Extensions for MiP Message-ID: <20010713101359.T5588@charizard.diameter.org> References: <200107122039.AMX00046@mira-sjcm-2.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200107122039.AMX00046@mira-sjcm-2.cisco.com>; from alpesh@cisco.com on Thu, Jul 12, 2001 at 01:39:22PM -0700 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 Thu, Jul 12, 2001 at 01:39:22PM -0700, Alpesh Patel wrote: > Hi, > > I am a late follower of this draft and our team had a question about why > reinvent the wheel about key distribution. I was wondering why not use > IKE for Key distribution and define a new Domain of Interpretation for > MobileIP? Good question. The issue is that the security model, at least in MIPv4, doesn't lead itself nicely to IKE. Consider the following example, which is typical of an IKE scenario: MN ------------> CN IKE SA Now, consider a MIPv4 scenario, where the gen key draft comes into play: MN ------------> FA ----------> HA MN-FA SA FA-HA SA ---------------------------> MN-HA SA So the main difference here is that a security association is created between all entities in the network. Certainly, the mobile could setup an IKE SA with the FA, and the FA with the HA. However, how can the MN setup an IKE SA with the HA, when the FA must process the protocol at the application layer. So, clearly some authentication is needed at the app (Mobile IP) layer. So, what this draft does, is allow a mobile node to get keying material that will be used to authenticate messages, using all three SAs above. Lastly, there are cases where a Mobile Node doesn't have a home address (nor a local address), and the MIP messages are used to allocate an address. So, IKE with a NULL IP address is not something that would work quite well. You would end up having to run IKE with NULL, secure MIP messages, get an address via MIP, and then run IKE again with the new address. of course, this assume that IKE would even work in the MIP message exchange, which I've already proven it doesn't. Hope this answers your question, PatC From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 13 13:35:34 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11930 for ; Fri, 13 Jul 2001 13:35:33 -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 KAA26809; Fri, 13 Jul 2001 10:35:47 -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 KAA14632; Fri, 13 Jul 2001 10:34:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6DHXK015072 for mobile-ip-dist; Fri, 13 Jul 2001 10:33:20 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6DHXHN15065 for ; Fri, 13 Jul 2001 10:33:17 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA14468 for ; Fri, 13 Jul 2001 10:33:28 -0700 (PDT) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA06505 for ; Fri, 13 Jul 2001 10:33:27 -0700 (PDT) Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21) id ; Fri, 13 Jul 2001 13:32:27 -0400 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] 2002bis change to Authenticator Spec Date: Fri, 13 Jul 2001 13:32:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) 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: > > Recommending that both be implemented will take care of the > future and the > past. Sometime later when HMAC is implemented by every one, > we can change the recommendation. > > -Gopal But isn't that what this is saying? MUST do HMAC, SHOULD do MD5 if there is a need for backward compatibility? > > PS: on a lighter side, Security Algos are secure till some > known weakness > and it is a matter of time that a weakness is found. > > > > > > > > -Gopal > > > > > > > > > >Another thing to note is that this will probably come up > again when > > > >we try to move MIPv4 to Draft Standard, the new > functionality causing > > > >a recycle at Proposed. > > > > > > > >Feedback requested, please. > > > > > > > >Here's the proposed new text: > > > > > > > >----------------------------- > > > >3.5.1. Computing Authentication Extension Values > > > > > > > > The default authentication algorithm uses HMAC-MD5 [22] > > > to compute > > > > a 128-bit "message digest" of the registration > message. The key > > > > used in the HMAC computation is the 128-bit shared > secret defined > > > > by the mobility security association between the > communicating > > > > nodes. The data over which the HMAC is computed is > defined as: > > > > > > > > - the UDP payload (that is, the Registration Request or > > > > Registration Reply data), > > > > > > > > - all prior Extensions in their entirety, and > > > > > > > > - the Type, Length, and SPI of this Extension. > > > > > > > > Note that the Authenticator field itself and the UDP > > > header are NOT > > > > included in the computation of the default > Authenticator value. > > > > See Section 5.1 for information about support > requirements for > > > > message authentication codes, which are to be used with > > > the various > > > > authentication Extensions. > > > > > > > > The Security Parameter Index (SPI) within any of the > > > authentication > > > > Extensions defines the security context which is > used to compute > > > > the Authenticator value and which MUST be used by > the receiver to > > > > check that value. In particular, the SPI selects the > > > authentication > > > > algorithm and mode (Section 5.1) and secret (a shared key, or > > > > appropriate public/private key pair) used in computing the > > > > Authenticator. In order to ensure interoperability > > > between different > > > > implementations of the Mobile IP protocol, an > > > implementation MUST be > > > > able to associate any SPI value with any > authentication algorithm > > > > and mode which it implements. In addition, all > implementations > > > > of Mobile IP MUST implement the default > authentication algorithm > > > > (HMAC-MD5) defined above. > > > > > > > > > > > > > > > > > > > >5.1. Message Authentication Codes > > > > > > > > Home agents and mobile nodes MUST be able to perform > > > authentication. > > > > The default algorithm is HMAC-MD5 [22], with a key > size of 128 > > > > bits. The foreign agent MUST also support > > > authentication using HMAC-MD5 > > > > and key sizes of 128 bits or greater, with manual key > > > distribution. Keys > > > > with arbitrary binary values MUST be supported. > > > > > > > > The "prefix+suffix" use of MD5 to protect data and a > > > shared secret is > > > >considered > > > > vulnerable to attack by the cryptographic community. > > > Where backward > > > >compatibility > > > > with existing Mobile IP implementations that use this > > > mode is needed, > > > > new implementations SHOULD include keyed MD5 [39] as > one of the > > > >additional > > > > authentication algorithms for use when producing and > > > verifying the > > > > authentication data that is supplied with Mobile IP > registration > > > > messages, for instance in the extensions specified in > > > sections 3.5.2, > > > > 3.5.3, and 3.5.4. > > > > > > > > The previously specified operation uses keyed-MD5 [39] in > > > > "prefix+suffix" mode to compute a 128-bit "message > digest" of the > > > > registration message. The default authenticator is a > > > 128-bit value > > > > computed as the MD5 checksum over the the following > > > stream of bytes: > > > > > > > > - the shared secret defined by the mobility security > > > association > > > > between the nodes and by the SPI value specified in the > > > > authentication Extension, followed by > > > > > > > > - the protected fields from the registration message, > > > in the order > > > > specified above, followed by > > > > > > > > - the shared secret again. > > > > > > > > More authentication algorithms, algorithm modes, key > distribution > > > >methods, > > > > and key sizes MAY also be supported for all of these > extensions. > > > > From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 13 13:39:43 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12556 for ; Fri, 13 Jul 2001 13:39:42 -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 KAA28514; Fri, 13 Jul 2001 10:39: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 KAA15655; Fri, 13 Jul 2001 10:38:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6DHb8w15110 for mobile-ip-dist; Fri, 13 Jul 2001 10:37:08 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6DHb4N15103 for ; Fri, 13 Jul 2001 10:37: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 KAA15530 for ; Fri, 13 Jul 2001 10:37:15 -0700 (PDT) Received: from mail.zrz.tu-berlin.de (mail.zrz.TU-Berlin.DE [130.149.4.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA20825 for ; Fri, 13 Jul 2001 11:37:13 -0600 (MDT) Received: from ftsu07.ee.tu-berlin.de ([130.149.49.87] helo=ftmail.ee.tu-berlin.de) by mail.zrz.tu-berlin.de with esmtp (exim-3.31) for id 15L6sK-00053g-00; Fri, 13 Jul 2001 19:37:12 +0200 Received: from ee.tu-berlin.de (fu@sinope.ee.TU-Berlin.DE [130.149.49.127]) by ftmail.ee.tu-berlin.de (8.11.3/8.11.3) with ESMTP id f6DHbBh32694 for ; Fri, 13 Jul 2001 19:37:11 +0200 Message-ID: <3B4F31C7.1432FEE5@ee.tu-berlin.de> Date: Fri, 13 Jul 2001 19:37:11 +0200 From: Xiaoming Fu Organization: Telecommunication Networks Group, TU-Berlin X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.14 i686) X-Accept-Language: en-US, de, zh-CN MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] New I-D on QoS-Conditionalized Binding Update in MIPv6 Content-Type: text/plain; charset=gb2312 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, We recently submitted a draft on "QoS-Conditionalized Binding Update in Mobile IPv6" Before the draft is announced you can find it in: http://www-tkn.ee.tu-berlin.de/~fu/draft-tkn-mobileip-qosbinding-mipv6-00.txt Comments are welcome. Regards, Xiaoming From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 13 14:23:54 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA18661 for ; Fri, 13 Jul 2001 14:23: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 MAA25085; Fri, 13 Jul 2001 12:24: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 LAA25683; Fri, 13 Jul 2001 11:22:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6DILRd15214 for mobile-ip-dist; Fri, 13 Jul 2001 11:21:27 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6DILNN15207 for ; Fri, 13 Jul 2001 11:21:24 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA13578 for ; Fri, 13 Jul 2001 11:21:32 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA28589; Fri, 13 Jul 2001 11:21: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 LAA28359; Fri, 13 Jul 2001 11:20:55 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6DIKtj19421; Fri, 13 Jul 2001 11:20:55 -0700 X-mProtect: Fri, 13 Jul 2001 11:20:55 -0700 Nokia Silicon Valley Messaging Protection Received: from tpagtzis.iprg.nokia.com (205.226.2.115, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdtk66c2; Fri, 13 Jul 2001 11:20:53 PDT Message-ID: <3B4F3C05.A30C0140@iprg.nokia.com> Date: Fri, 13 Jul 2001 11:20:53 -0700 From: Theo Pagtzis Organization: UCL/NOKIA X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.1-STABLE i386) X-Accept-Language: el, en MIME-Version: 1.0 To: James Kempf , Govind.Krishnamurthi@nokia.com CC: mobile-ip@sunroof.eng.sun.com, seamoby@cdma-2000.org, seamoby-context@cdma-2000.org Subject: Re: [mobile-ip] Re: [seamoby-context] Resend:New Draft:Issues in Candidate Access Router Discovery References: <200107131719.KAA15138@heliopolis.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 HI James, My draft spec document has also got a contents section for faster scanning of relevant sections. But nevermind. I would be glad to discuss with you guys about the issues on CAR discovery at the IETF in London. I would like to propose then whether it would be possible to contribute to your draft my sections on the particular aspect and participate in a joint design process of that aspect on CAR discovery as a co-author. What do you think? Theo UCL/ Mobile Systems James Kempf wrote: > Theo, > > While it looks like your proactive draft has lots of good stuff in it, > since I've stopped doing international flights regularly, I don't > have large blocks of time for sitting still. So it may be hard > to go through the whole thing quickly, and I suspect that might be > true for others as well. > > What I would like to suggest you may want to think about is to > carve out a few nuggets, like, for example, the CAR discovery protocol, > and put them into separate drafts, perhaps after IETF 51. > Also, if you think you've got some good stuff on requirements for CAR discovery > (what the draft that Govind et. al. wrote) is all about, then maybe we can get > together at IETF and talk about folding them into the CAR discovery > draft if they haven't already been covered, or even though the > mailing list. The CAR discovery draft is just at 00 now, and that must go > through WG last call and IESG last call before the requirements are agreed to, > so there is plenty of time. > > jak > > >X-mProtect: Fri, 13 Jul 2001 10:08:21 -0700 Nokia Silicon Valley Messaging > Protection > >Date: Fri, 13 Jul 2001 10:08:20 -0700 > >From: Theo Pagtzis > >To: "Govind.Krishnamurthi" > >CC: mobile-ip , seamoby , > seamoby-context > >Subject: [mobile-ip] Re: [seamoby-context] Resend:New Draft:Issues in Candidate > Access Router Discovery > > > >Govind, > > > > I have already provided a detailed protocol on pessimistic and optimistic > proactivity in > >terms of router neighbour determination and candidacy. Please see > >draft-pagtzis-mobileip-proactivev6-00.txt/.ps > > > >I have also gone a long way in specifying the notions of mobility and routing > neighbourhood as well as > >provide an algorithm for their determination. > > > >My proactive mobility scheme contains as part of it, exactly what you are > describing as very briefly as > >physical neighbourhood and its mapping to a routing neighbourhood. There are > however much more issues that > >are not elaborated in the targer AR determination. These are also covered in > the draft on proactive mobility. > > > >Also what is the date of your submission? Here your draft says it is July 2001. > But what day? > > > > > >Theo > > > >UCL/ Mobile Systems > > > > > >"Govind.Krishnamurthi" wrote: > > > >> I'm resending the draft to the mailing list as I did not see it appear > >> in the archives. Sorry if you receive multiple copies. > >> BRs, > >> Govind. > >> > >> Abstract: > >> Handoff in IP mobility protocols involves moving a mobile node's > >> Layer 3 routing reachability information from one access router to > >> another, before or after the mobile node has established a Layer 2 > >> connection with the radio access point that is covered by the new > >> access router. In addition, other context information about the > >> mobile node's packet session may be transferred from the old access > >> router to the new one, in order to minimize the service disruption > >> during the handoff process. While the exact details of how this is > >> accomplished vary depending on the IP mobility and seamless handoff > >> protocols, one common thread required for seamless handoffs is > >> identifying the candidate access routers for the mobile node's > >> handoff. When a collection of candidates has been identified, an > >> algorithm is run to determine the target access router, and this > >> router becomes the target of handoff at Layer 3. This document > >> presents a problem statement describing issues involved in designing > >> a candidate access router discovery protocol. The document does not > >> discuss the algorithm by which the actual target router is > >> identified, nor how the handoff to the target is achieved. > >> > >> Comments are welcome. > >> > >> Best Regards, > >> Govind. > >> > >> <> > >> > >> ------------------------------------------------------------------------ > >> Name: > draft-ietf-seamoby-CARdiscovery-issues-00.txt > >> draft-ietf-seamoby-CARdiscovery-issues-00.txt Type: Plain Text > (text/plain) > >> Encoding: base64 > >> Description: > draft-ietf-seamoby-CARdiscovery-issues-00.txt > > From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 13 16:23:48 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA05049 for ; Fri, 13 Jul 2001 16:23: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 OAA10882; Fri, 13 Jul 2001 14:23: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 NAA07372; Fri, 13 Jul 2001 13:22:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6DKKk515395 for mobile-ip-dist; Fri, 13 Jul 2001 13:20:46 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6DKKgN15388 for ; Fri, 13 Jul 2001 13:20:42 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA01204 for ; Fri, 13 Jul 2001 13:20:52 -0700 (PDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id NAA17083 for ; Fri, 13 Jul 2001 13:20:52 -0700 (PDT) Received: (qmail 6612 invoked by uid 500); 13 Jul 2001 20:09:58 -0000 Date: Fri, 13 Jul 2001 13:09:58 -0700 From: Pat Calhoun To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] 01 Version of BETH Draft Message-ID: <20010713130958.I32517@charizard.diameter.org> References: <200107122228.PAA10460@heliopolis.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200107122228.PAA10460@heliopolis.eng.sun.com>; from James.Kempf@Sun.COM on Thu, Jul 12, 2001 at 03:28:23PM -0700 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, the latest beth draft is available at http://www.diameter.org/draft-kempf-beth-ipv6-01.txt Enjoy, PatC On Thu, Jul 12, 2001 at 03:28:23PM -0700, James Kempf wrote: > Folks, > > Just posted the 01 Version of the BETH draft to the IETF Drafts editor. > Since the 00 deadline is tomorrow, it will probably take a while > to go through the queue. I've asked Pat to post it at diameter.org, > so it may be available tomorrow if Pat gets a chance to post it. > > Most changes are editorial. The only substantive ones are: > > 1) Reference to context transfer has been removed from the protocol > description. It is not necessary for the protocol, though having > it is a benefit. We do talk about how the protocol could benefit > from context transfer. > > 2) The handoff smoothing section was moved to an appendix since it > is ancilliary to the protocol. In the handoff smoothing section, > we derive a forumla that bounds the rate of the incoming data stream, > given the rate of the wireless link and the handover latency, in > order to avoid propagating the handover latency into the user > perceptible region. If the incoming data stream rate exceeds this > bound, the user is likely to hear an artifact (for audio streams). > > jak > > From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 13 16:29:28 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA05901 for ; Fri, 13 Jul 2001 16:29:27 -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 NAA08410; Fri, 13 Jul 2001 13:29:48 -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 NAA08789; Fri, 13 Jul 2001 13:28:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6DKRJE15465 for mobile-ip-dist; Fri, 13 Jul 2001 13:27:19 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6DKRFN15458 for ; Fri, 13 Jul 2001 13:27:15 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA16631 for ; Fri, 13 Jul 2001 13:27:26 -0700 (PDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id NAA29440 for ; Fri, 13 Jul 2001 13:27:24 -0700 (PDT) Received: (qmail 6652 invoked by uid 500); 13 Jul 2001 20:16:30 -0000 Date: Fri, 13 Jul 2001 13:16:30 -0700 From: Pat Calhoun To: Govind.Krishnamurthi@nokia.com Cc: mobile-ip@sunroof.eng.sun.com, seamoby@cdma-2000.org, seamoby-context@cdma-2000.org Subject: [mobile-ip] Re: [seamoby] Resend:New Draft:Issues in Candidate Access Router Discovery Message-ID: <20010713131630.J32517@charizard.diameter.org> Mail-Followup-To: Govind.Krishnamurthi@nokia.com, mobile-ip@sunroof.eng.sun.com, seamoby@cdma-2000.org, seamoby-context@cdma-2000.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from Govind.Krishnamurthi@nokia.com on Fri, Jul 13, 2001 at 09:48:04AM -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: On Fri, Jul 13, 2001 at 09:48:04AM -0500, Govind.Krishnamurthi@nokia.com wrote: > I'm resending the draft to the mailing list as I did not see it appear > in the archives. Sorry if you receive multiple copies. Just for future reference, it is better to make a URL available for folks that care, as opposed to the whole draft. However, I'd like to note to the WG that this draft is the first attempt at a Problem Statement. I would *highly* encourage folks to comment on this draft so that we can get it completed on time. Thanks, PatC From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 13 16:34:34 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA06743 for ; Fri, 13 Jul 2001 16:34:33 -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 OAA17649; Fri, 13 Jul 2001 14:34:58 -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 NAA10098; Fri, 13 Jul 2001 13:33:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6DKVk715530 for mobile-ip-dist; Fri, 13 Jul 2001 13:31:46 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6DKVgN15523 for ; Fri, 13 Jul 2001 13:31:42 -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 NAA17572 for ; Fri, 13 Jul 2001 13:31:53 -0700 (PDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id OAA28529 for ; Fri, 13 Jul 2001 14:33:04 -0600 (MDT) Received: (qmail 6846 invoked by uid 500); 13 Jul 2001 20:17:45 -0000 Date: Fri, 13 Jul 2001 13:17:45 -0700 From: Pat Calhoun To: Phillip Neumiller Cc: "'Govind.Krishnamurthi@nokia.com'" , mobile-ip@sunroof.eng.sun.com, seamoby@cdma-2000.org Subject: [mobile-ip] Re: [seamoby] Resend:New Draft:Issues in Candidate Access Router Discovery Message-ID: <20010713131745.K32517@charizard.diameter.org> Mail-Followup-To: Phillip Neumiller , "'Govind.Krishnamurthi@nokia.com'" , mobile-ip@sunroof.eng.sun.com, seamoby@cdma-2000.org References: <0DF9FBC42474A24CA50F7A27FB08E0484455A1@meshpdc.meshnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <0DF9FBC42474A24CA50F7A27FB08E0484455A1@meshpdc.meshnetworks.com>; from PNeumiller@MeshNetworks.com on Fri, Jul 13, 2001 at 11:36:46AM -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: On Fri, Jul 13, 2001 at 11:36:46AM -0400, Phillip Neumiller wrote: > Amazing. I am stunned. Great start! More useful comments > later... One comment right now is that I have a candidate > algorithm in mind (:-)), also I am again finding it difficult > to see how this will work with macro-diversity since you may > want to have legs across ARs in different ADs but more on that > later. > > This draft moves MIP from blind faith to "enlightenment" > a mobility renaissance is under way in the MIP WG!!! You enthusiasm is very encouraging. Thanks Phil, PatC From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 13 16:38:00 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA07211 for ; Fri, 13 Jul 2001 16:37:59 -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 OAA20248; Fri, 13 Jul 2001 14:38:14 -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 NAA18690; Fri, 13 Jul 2001 13:36:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6DKZxD15580 for mobile-ip-dist; Fri, 13 Jul 2001 13:35:59 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6DKZtN15573 for ; Fri, 13 Jul 2001 13:35:55 -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 NAA18573 for ; Fri, 13 Jul 2001 13:36:06 -0700 (PDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id OAA00463 for ; Fri, 13 Jul 2001 14:37:16 -0600 (MDT) Received: (qmail 7443 invoked by uid 500); 13 Jul 2001 20:21:58 -0000 Date: Fri, 13 Jul 2001 13:21:57 -0700 From: Pat Calhoun To: Theo Pagtzis Cc: James Kempf , Govind.Krishnamurthi@nokia.com, mobile-ip@sunroof.eng.sun.com, seamoby@cdma-2000.org, seamoby-context@cdma-2000.org Subject: Re: [seamoby] Re: [mobile-ip] Re: [seamoby-context] Resend:New Draft:Issues in Candidate Access Router Discovery Message-ID: <20010713132157.L32517@charizard.diameter.org> Mail-Followup-To: Theo Pagtzis , James Kempf , Govind.Krishnamurthi@nokia.com, mobile-ip@sunroof.eng.sun.com, seamoby@cdma-2000.org, seamoby-context@cdma-2000.org References: <200107131719.KAA15138@heliopolis.eng.sun.com> <3B4F3C05.A30C0140@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: <3B4F3C05.A30C0140@iprg.nokia.com>; from tpagtzis@IPRG.nokia.com on Fri, Jul 13, 2001 at 11:20:53AM -0700 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 Fri, Jul 13, 2001 at 11:20:53AM -0700, Theo Pagtzis wrote: > I would be glad to discuss with you guys about the issues on CAR discovery at the > IETF in London. > > I would like to propose then whether it would be possible to contribute to your > draft my sections on the particular aspect and participate in a joint design > process of that aspect on CAR discovery as a co-author. What do you think? I certainly encourage it PatC From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 13 16:50:43 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09112 for ; Fri, 13 Jul 2001 16:50:42 -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 JAA11492; Fri, 13 Jul 2001 09:00:50 -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 IAA05252; Fri, 13 Jul 2001 08:58:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6DFvQA14404 for mobile-ip-dist; Fri, 13 Jul 2001 08:57:26 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6DFvMN14397 for ; Fri, 13 Jul 2001 08:57:22 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA05063 for ; Fri, 13 Jul 2001 08:57:33 -0700 (PDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA20655 for ; Fri, 13 Jul 2001 08:57:32 -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.11.0/8.11.0/WIREfire-1.3) with SMTP id f6DFvVN19820 for ; Fri, 13 Jul 2001 17:57:31 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Fri Jul 13 17:57:30 2001 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 13 Jul 2001 17:51:33 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008AE1@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] new draft Date: Fri, 13 Jul 2001 17:57:25 +0200 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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Folks, Based on the comments on load balancing in HMIPv6 and the interest expressed by some, we've submitted a separate short draft on flow movement in MIPv6. The draft is generic and is not tied to HMIPv6 only. The load balancing section will be taken out of HMIPv6 and a new revision will be submitted next week. Until the draft is announced you can find it in: http://standards.ericsson.net/Hesham/draft-soliman-mobileip-flow-move-00.txt Comments are welcome. Cheers, Hesham From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 13 16:56:11 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09882 for ; Fri, 13 Jul 2001 16:56:11 -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 NAA18803; Fri, 13 Jul 2001 13:56: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 NAA21793; Fri, 13 Jul 2001 13:55:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6DKs3E15733 for mobile-ip-dist; Fri, 13 Jul 2001 13:54:03 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6DKrxN15726 for ; Fri, 13 Jul 2001 13:54:00 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA25945 for ; Fri, 13 Jul 2001 13:54:10 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA00070; Fri, 13 Jul 2001 13:54: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 NAA09637; Fri, 13 Jul 2001 13:53:38 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6DKrcb21128; Fri, 13 Jul 2001 13:53:38 -0700 X-mProtect: Fri, 13 Jul 2001 13:53:38 -0700 Nokia Silicon Valley Messaging Protection Received: from tpagtzis.iprg.nokia.com (205.226.2.115, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdHtrwZ1; Fri, 13 Jul 2001 13:53:36 PDT Message-ID: <3B4F5FD0.93EF9B73@iprg.nokia.com> Date: Fri, 13 Jul 2001 13:53:36 -0700 From: Theo Pagtzis Organization: UCL/NOKIA X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.1-STABLE i386) X-Accept-Language: el, en MIME-Version: 1.0 To: Pat Calhoun CC: James Kempf , Govind.Krishnamurthi@nokia.com, mobile-ip@sunroof.eng.sun.com, seamoby@cdma-2000.org, seamoby-context@cdma-2000.org Subject: Re: [seamoby] Re: [mobile-ip] Re: [seamoby-context] Resend:New Draft:Issues in Candidate Access Router Discovery References: <200107131719.KAA15138@heliopolis.eng.sun.com> <3B4F3C05.A30C0140@iprg.nokia.com> <20010713132157.L32517@charizard.diameter.org> 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 Thanks Pat ! This is definetely refreshing and more inspiring Theo UCL/ Mobile Systems Pat Calhoun wrote: > On Fri, Jul 13, 2001 at 11:20:53AM -0700, Theo Pagtzis wrote: > > I would be glad to discuss with you guys about the issues on CAR discovery at the > > IETF in London. > > > > I would like to propose then whether it would be possible to contribute to your > > draft my sections on the particular aspect and participate in a joint design > > process of that aspect on CAR discovery as a co-author. What do you think? > > I certainly encourage it > > PatC From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 13 17:08:26 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA11510 for ; Fri, 13 Jul 2001 17:08:24 -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 OAA23549; Fri, 13 Jul 2001 14:08: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 OAA24477; Fri, 13 Jul 2001 14:07:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6DL6D815813 for mobile-ip-dist; Fri, 13 Jul 2001 14:06:13 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.84.31] (may be forged)) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6DL6AN15806 for ; Fri, 13 Jul 2001 14:06:10 -0700 (PDT) Received: from antley (antley.Eng.Sun.COM [129.146.86.225]) by jurassic.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with SMTP id f6DL6Db191502; Fri, 13 Jul 2001 14:06:13 -0700 (PDT) Message-Id: <200107132106.f6DL6Db191502@jurassic.eng.sun.com> Date: Fri, 13 Jul 2001 14:00:05 -0700 (PDT) From: Carl Williams Subject: [mobile-ip] draft-ietf-mobileip-lmm-requirements-00.txt To: mobile-ip@sunroof.eng.sun.com Cc: carlw@jurassic.Eng.Sun.COM MIME-Version: 1.0 Content-Type: MULTIPART/mixed; BOUNDARY=Herd_of_Elephants_897_000 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 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: --Herd_of_Elephants_897_000 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: alWYfRHM/+qM6u6HRVVQHw== I have submitted the Localized Mobility Management (LMM) requirement document. I am sending it out to the working group so to stir debate before the London IETF meeting. If I missed someone in the acknowledgment section, let me know. I waded through all the MIP working group email debate - including what went on back in nov-dec timeframe to capture all the context for the requirements that Phil Roberts summarized in the list he presented. While I sought to give finer details (and context) to existing requirements, new requirements were also added. Thanks to all those who participated - please see acknowledgement section for all those who contributed. Please try to start some debate so we can have a nice discussion in London. Carl ------------- Begin Forwarded Message ------------- Date: Fri, 13 Jul 2001 13:38:32 -0700 (PDT) From: Carl Williams Subject: draft-ietf-mobileip-lmm-requirements-00.txt To: internet-drafts@ietf.org Cc: Raj.Patil@nokia.com, proberts@megisto.com, carlw@jurassic.eng.sun.com MIME-Version: 1.0 Attached is an individual Internet draft for submission to the mobileip working group. The draft is draft-ietf-mobileip-lmm-requirements-00.txt. Please post it to the Internet Drafts area. Thanks.... Carl Title: Localized Mobility Management Requirements Working Groups: mobileip Abstract: Mobile IP is required for hosts moving within the Internet topology. Mobile IP manages IP mobility resulting from the change in Care-of-Address when a host moves within the Internet topology. When a Mobile Node moves from one point of attachment to another, a mobility binding update to the respective home agent and/or correspondent node(s) occurs. Localized Mobility Management (LMM) refers to a method of handling mobility locally, restricting the resultant signaling to a specific area, and possibly reducing the amount of signaling. This document describes requirements which are designed to guide development of optional extensions to the Mobile IPv6 protocol in providing for Localized Mobility Management functionality. Authors: Carl Williams, Editor ------------- End Forwarded Message ------------- --Herd_of_Elephants_897_000 Content-Type: TEXT/plain; name="draft-ietf-mobileip-lmm-requirements-00.txt"; charset=us-ascii Content-Description: draft-ietf-mobileip-lmm-requirements-00.txt Content-MD5: 1RN4+T6RbxvLEB5GCImJ6Q== INTERNET-DRAFT Carl Williams, Editor Internet Engineering Task Force Sun Microsystems Issued: July 13, 2001 Expires: January 13, 2002 Localized Mobility Management Requirements Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as 'work in progress.' The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract Mobile IP is required for hosts moving within the Internet topology. Mobile IP manages IP mobility resulting from the change in Care-of-Address when a host moves within the Internet topology. When a Mobile Node moves from one point of attachment to another, a mobility binding update to the respective home agent and/or correspondent node(s) occurs. Localized Mobility Management (LMM) refers to a method of handling mobility locally, restricting the resultant signaling to a specific area, and possibly reducing the amount of signaling. This document describes requirements which are designed to guide development of optional extensions to the Mobile IPv6 protocol in providing for Localized Mobility Management functionality. Carl Williams, Editor Expires January 13, 2002 [Page 1] INTERNET DRAFT Localized Mobility Management Requirements July 2001 Table of Contents 1.0 Introduction .................................................... 2 2.0 Terminology ..................................................... 2 3.0 Requirements .................................................... 3 3.1 Intra-domain mobility ........................................ 3 3.2 Security ..................................................... 4 3.3 Scope of LMM effect .......................................... 4 3.4 Scalability and Performance .................................. 4 3.5 Mobility Management Support .................................. 5 3.6 Sparse routing element population requirement ................ 5 3.7 Interworking with hand-off mechanisms ........................ 5 3.8 Simple Network design requirement ............................ 6 3.9 Location Privacy requirement ................................. 6 3.10 Reliablity .................................................. 6 4.0 Acknowledgments ................................................. 6 5.0 References ...................................................... 6 6.0 Author's Addresses .............................................. 7 7.0 Full Copyright Statement ........................................ 7 1.0 Introduction The emergence of Mobile IPv6 as the dominant protocol for supporting mobile data networking provides a productive springboard from which to explore and develop wireless mobile networking. The overall goals of LMM are: - reducing the signaling induced by changes in the point of attachment due to the movement of a host; - reducing the usage of air-interface resources for mobility; - avoid changes to the mobile node, home agent or the correspondent node; - avoid creating single points of failure; - simplify the network design and provisioning for enabling LMM capability in a network; - allow progressive LMM deployment capabilities. Latency costs can be high due to mobility binding updates and registration processing. In addition, radio interface resources are scarce, when compared to wired interfaces, and thus expensive, which calls for special measures from IP mobility management protocols in providing a highly efficient data transport to and from a mobile device where the routable IP address of the node changes during movement to a new point of attachment [1]. Increasing the efficiency of the registration process of mobile hosts is an approach that addresses the goals of reducing latency costs and the conservation of radio resources. One class of solutions in this regard focuses on extensions to the IP layer mobility protocol in order to restrict the region of signaling, thus possibly reducing the amount of signaling. This functionality is commonly referred to as Localized Mobility Management (LMM). Carl Williams, Editor Expires January 13, 2002 [Page 2] INTERNET DRAFT Localized Mobility Management Requirements July 2001 Through LMM, the user can gain the benefit of smoother hand-offs as well as reducing the signaling initiated from the mobile node and thus minimizing radio resources usage. Inherently, this allows for increased scalability and reduces the need for additional route optimization. This document lays out requirements in order to guide development of LMM in order that the resulting solution will best preserve the the fundamental philosophies and architectural principles of the Internet in practice today. 2.0 Terminology See [2] for additional terminology. Administrative Domain A collection of networks under the same administrative control and grouped together for administrative purposes. [3] Local Mobility The movement of an IP device without requiring a change to its routable IP address seen by the CN or HA. Althoughits point of attachment may change during themove, the IP addresses used to reach the device(both its home and IP subnet routable IPaddress) do not change. Local Mobility Domain A Local Mobility Domain contains one or more IP subnets, networks, or Administrative Domains. Within the Local Mobility Domain, the globally visible routable IP address assigned to a MobileHost or Mobile Router serving a Mobile Networkdoes not change. Localized Mobility A method of handling mobility locally, in order Management (LMM) to restrict the signaling area,thus possibly reducing the amount of signaling. 3.0 LMM Requirements This section describes the requirements of a LMM solution for Mobile IPv6. Only Mobile IPv6 based requirements are described here. 3.1 Intra-domain mobility LMM is introduced to minimize the signaling trafficto the home agent and/or correspondent node(s) for intra-domain mobility. In the LMM infrastructure a correspondent node or home agent outside the administration domainMUST always be able to address the mobile host by the same IP address, sothat from the point of view of hosts outside the administration domain, the IP address of the mobile host remains fixed. It is not the intent or goal for LMM to enter the intra-subnet (intra AR) mobility problem space. See [SubnetMobPro] for more information on this specific problem space. Carl Williams, Editor Expires January 13, 2002 [Page 3] INTERNET DRAFT Localized Mobility Management Requirements July 2001 3.2 Security 3.2.1 LMM protocol MUST provide for "security provisioning" within the respective administration domain. The security of exchanging LMM specific information and signaling MUST be ensured. Security provisioning includes protecting the integrity, confidentiality, and authenticity of the transfer of LMM specific information within the administration domain. If applicable, replay protection MUST exist between the LMM agents. 3.2.2 LMM protocol MUST provide for the security provisioning to be disabled. In certain environments the security within the administration domain may not be necessary, or it may be preferred to minimize the LMM protocol overhead.This feature would be used at the network operator's own risk. 3.2.3 LMM protocol MUST NOT interfere with the security provisioning that exists between the home agent and the mobile host. 3.2.4 LMM protocol MUST NOT interfere with the security provisioning that exists between the correspondent node and the mobile host. 3.2.5 LMM protocol MUST NOT introduce new security holes or the possibility for DOS-style attacks. 3.3 Scope of LMM effect 3.3.1 The LMM framework MUST NOT add any modifications or extensions to the correspondent node(s) and home agent. 3.3.2 Non-LMM-aware routers, hosts, home agents, and mobile nodes MUST be able to interoperate with LMM-aware agents. 3.3.3 The LMM framework MUST NOT increase the number of messages between the mobile host and the respective correspondent node(s) and home agent. 3.3.4 Connectivity to the mobile host MUST always be maintained in the presence of failure of LMM agents (infrastructure). 3.4 Scalability and Performance 3.4.1 The LMM framework MUST be able to support a large number of mobile hosts. 3.4.2 The LMM framework MUST NOT interfere with the Mobile IPv6 performance of a mobile host communications with a correspondent node(s). 3.4.3 Scalable expansion of the network The LMM framework MUST allow scalable expansion of the network and provide for reasonable network configuration with regard to peering, interadministrative domain connectivity, and other interadministrative domain interoperability characteristics of interest to wireless ISPs. The LMM framework MUST NOT introduce any additional restrictions in how wireless ISPs configure their network, nor how they interconnect with other networks beyond those introduced by standard IP routing. Carl Williams, Editor Expires January 13, 2002 [Page 4] INTERNET DRAFT Localized Mobility Management Requirements July 2001 3.4.3 Header overhead Any additional header overhead caused by LMM MUST be reduced by compression and transfer of compressor state on movement SHOULD be possible so as not to introduce any perceived service disruption. Candidate LMM designs that require additional header overhead for tunnels MUST be reviewed by the ROHC working group to determine if the header compressor can be restarted from transferred compressor context when handover occurs without requiring any full header packet exchange on the new link. 3.4.4 Optimized signaling within the administrative domain By its very nature, LMM reintroduces triangle routing into Mobile IPv6 in that all traffic must go through the LMM agent. There is no way to avoid this. The LMM framework SHOULD be designed in such a way that as to reduce the length of the unwanted triangle leg. The LMM framework SHOULD support optimal placement of LMM agents to reduce or eliminate additional triangle routing introduced by LMM. 3.5 Mobility Management Support The following LMM requirements pertain to both inter-domain hand-off and between administrative domains as well. 3.5.1 The LMM framework MUST NOT increase the amount of latency or amount of packet loss that exists with the core Mobile IPv6 specification [6]. 3.5.2 The LMM framework MUST NOT increase the amount of service disruption that already exists with the core Mobile IPv6 specification. 3.5.3 The LMM framework MUST NOT increase the number of messages between the mobile host and the respective correspondent node(s) and home agent as is in the core Mobile IPv6 specification. 3.5.4 The LMM framework SHOULD support the auto-configuration capabilities for mobility agents/FAs, access routers. 3.6 Sparse routing element population requirement The LMM framework SHOULD be supported, at the very minimum, by a sparse (proper subset) routing element population within a single administration domain. 3.7 Interworking with hand-off mechanisms 3.7.1 The LMM framework MAY include methods for interworking with Mobile IPv6 fast hand-off solutions [7]. 3.7.2 The LMM framework MAY provide input to the hand-off process. Carl Williams, Editor Expires January 13, 2002 [Page 5] INTERNET DRAFT Localized Mobility Management Requirements July 2001 3.8 Simple Network design requirement LMM SHOULD simplify the network design and provisioning for enabling LMM capability in a network and allow progressive LMM deployment capabilities. 3.9 Location privacy support The LMM framework MUST allow for location privacy. 3.10 Reliablity 3.10.1 LMM framework MAY include recovery from failure of LMM agents. 3.10.2 LMM framework MAY include mechanisims for inclusion of the indication of Failure of LMM agents. 4.0 Acknowledgments Thank you to all who participated in the LMM requirement discussion on the Mobile IP working group alias. Those individuals are: Charlie Perkins (Nokia), Theo Pagtzis (Nokia), Muhammad Jaseemuddin (Nortel), Tom Weckstr (Helsinki University), Jim Bound (Compaq), Erik Nordmark (Sun), James Kempf (Sun), Gopal Dommety (Cisco), Glenn Morrow (Nortel), Arthur Ross (IEEE), Samita Chakrabarti (Sun), Hesham Soliman (Ericsson), Karim El-Malki (Ericsson), Phil Neumiller (Telocity), Behcet Sarikaya (Alcatel), Karann Chew (University of Surrey), Michael Thomas (Cisco), Pat Calhoun (Sun), Bill Gage (Nortel Networks), Vinod Choyi (Alcatel), John Loughney (Nokia), Wolfgang Schoenfeld (GMD Fokus), and David Martin (Nextel). Special thanks to Alper Yegin (Sun), John Loughney (Nokia) and Madjid Nakhjiri (Motorola) for providing input to the draft in its preliminary stage. In addition special thanks to the Mobile IP working group chairs for their input as well as capturing and organizing the initial set of requirements from the discussions, Phil Roberts (Magisto) and Basavaraj Patil (Nokia). 5.0 References [1] Westberg, L., Lindqvist M., Realtime Traffic over Cellular Access Networks; draft-westberg-realtime- cellular-04.txt; Work In Progress; December 2001 [2] Manner, J. et al; "Mobility Related Terminology"; draft-manner-seamoby-terms-00.txt; Work In Progress; January 12, 2001. [3] Yavatkar, R., Pendarakis, D., Guerin, R.; "A Framework for Policy-based Admission Control"; RFC 2753; January 2000. [4] Roberts, P., "Local Subnet Mobility Problem Statement"; draft-proberts-local-subnet-mobility-problem-01.txt; Work In Progress; May 2001. [5] Perkins, C., "IP Mobility Support". Internet Engineering Task Force, Request for Comments (RFC) 2002, October 1996. Carl Williams, Editor Expires January 13, 2002 [Page 6] INTERNET DRAFT Localized Mobility Management Requirements July 2001 [6] David B. Johnson, Charles Perkins, "Mobility Support in IPv6"; draft-ietf-mobileip-ipv6-14.txt; July 2001. [7] Tsirtsis, G. (Editor), "Fast Handovers for Mobile IPv6"; draft-ietf-mobileip-fast-mipv6-00.txt; a work in progress; February 2001. [8] Loughney, J. (Editor), "SeaMoby Micro Mobility Problem Statement"; draft-ietf-seamoby-mm-problem-01.txt; a work in progress; February 2001. 6.0 Authors' Addresses The working group can be contacted via the current chairs: Basavaraj Patil Phil Roberts Nokia Corporation Megisto Systems 6000 Connection Drive 20251 Century Blvd Irving, TX 75039 Suite 120 USA Germantown Maryland, 20874-1191 Phone: +1 972-894-6709 EMail: proberts@megisto.com EMail: Raj.Patil@nokia.com Fax : +1 972-894-5349 Questions about this memo can also be directed to: Carl Williams Sun Microsystems, Inc. 901 San Antonio Road Palo Alto, CA 94303 USA phone: +1 650 786 5186 fax: +1 650 786 5896 email: Carl.Williams@eng.sun.com 7.0 Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. Carl Williams, Editor Expires January 13, 2002 [Page 7] INTERNET DRAFT Localized Mobility Management Requirements July 2001 The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Carl Williams, Editor Expires January 13, 2002 [Page 8] --Herd_of_Elephants_897_000-- From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 13 17:13:06 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA12161 for ; Fri, 13 Jul 2001 17:13:06 -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 OAA25140; Fri, 13 Jul 2001 14:12: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 OAA25295; Fri, 13 Jul 2001 14:10:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6DLA1h15859 for mobile-ip-dist; Fri, 13 Jul 2001 14:10:01 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6DL9wN15852 for ; Fri, 13 Jul 2001 14:09: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 OAA29386 for ; Fri, 13 Jul 2001 14:10:09 -0700 (PDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA10486 for ; Fri, 13 Jul 2001 15:10:06 -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.11.0/8.11.0/WIREfire-1.3) with SMTP id f6DLA6N25613 for ; Fri, 13 Jul 2001 23:10:06 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Fri Jul 13 23:10:05 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Fri, 13 Jul 2001 23:10:05 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008AE9@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] bicasting draft Date: Fri, 13 Jul 2001 23:10:02 +0200 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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Folks, Please note the follwing new draft: http://standards.ericsson.net/Hesham/draft-elmalki-mobileip-bicasting-v6-00.txt The draft was submitted today and should be announced soon. The aim is to integrate it with the Fast Handoffs draft for v6. Comments ar welcome. Hesham From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 13 17:18:42 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA12922 for ; Fri, 13 Jul 2001 17:18:41 -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 OAA27684; Fri, 13 Jul 2001 14:19:06 -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 OAA19614; Fri, 13 Jul 2001 14:17:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6DLFcv15942 for mobile-ip-dist; Fri, 13 Jul 2001 14:15:38 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6DLFYN15935 for ; Fri, 13 Jul 2001 14:15:34 -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 OAA19310 for ; Fri, 13 Jul 2001 14:15:45 -0700 (PDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id PAA14330 for ; Fri, 13 Jul 2001 15:15:43 -0600 (MDT) Received: (qmail 11492 invoked by uid 500); 13 Jul 2001 21:00:52 -0000 Date: Fri, 13 Jul 2001 14:00:52 -0700 From: Pat Calhoun To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] 2002bis change to Authenticator Spec Message-ID: <20010713140052.R32517@charizard.diameter.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from PRoberts@MEGISTO.com on Fri, Jul 13, 2001 at 01:32:27PM -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: All, There is always a risk in shipping products based on an RFC that is Proposed Standard. Time and time again I've seen needed changes as a spec progresses towards full standards, and manufacturers are left up the proverbial creek (btw, I've been there, and wasn't happy about it either). In this particular instance, I happen to agree that a MUST for HMAC-MD5, and a SHOULD for MD5 is the correct approach. For products that are labelled as "RFC 2002" compliant, customers will know that they can only support MD5. These same customers buying products compliant with RFC nnnn (whatever RFC 2002bis ends up being), if they have an existing base, they'll make sure that it also supports native prefix/suffix MD5. The fact that it is a SHOULD, as opposed to a MUST, will lead designers towards an on/off switch, and this is really what's needed. If you are comfortable with prefix/suffix, then leave the switch turned on, but don't complain if someone steals the lightbulb. That said, if the WG feels differently (and we are allowed to ignore IESG concerns), I won't stand in the way of keeping things as they are. My 2 cents, PatC On Fri, Jul 13, 2001 at 01:32:27PM -0400, Phil Roberts wrote: > > > > Recommending that both be implemented will take care of the > > future and the > > past. Sometime later when HMAC is implemented by every one, > > we can change the recommendation. > > > > -Gopal > > But isn't that what this is saying? MUST do HMAC, SHOULD do MD5 if there > is a need for backward compatibility? > > > > > PS: on a lighter side, Security Algos are secure till some > > known weakness > > and it is a matter of time that a weakness is found. > > > > > > > > > > > > -Gopal > > > > > > > > > > > > >Another thing to note is that this will probably come up > > again when > > > > >we try to move MIPv4 to Draft Standard, the new > > functionality causing > > > > >a recycle at Proposed. > > > > > > > > > >Feedback requested, please. > > > > > > > > > >Here's the proposed new text: > > > > > > > > > >----------------------------- > > > > >3.5.1. Computing Authentication Extension Values > > > > > > > > > > The default authentication algorithm uses HMAC-MD5 [22] > > > > to compute > > > > > a 128-bit "message digest" of the registration > > message. The key > > > > > used in the HMAC computation is the 128-bit shared > > secret defined > > > > > by the mobility security association between the > > communicating > > > > > nodes. The data over which the HMAC is computed is > > defined as: > > > > > > > > > > - the UDP payload (that is, the Registration Request or > > > > > Registration Reply data), > > > > > > > > > > - all prior Extensions in their entirety, and > > > > > > > > > > - the Type, Length, and SPI of this Extension. > > > > > > > > > > Note that the Authenticator field itself and the UDP > > > > header are NOT > > > > > included in the computation of the default > > Authenticator value. > > > > > See Section 5.1 for information about support > > requirements for > > > > > message authentication codes, which are to be used with > > > > the various > > > > > authentication Extensions. > > > > > > > > > > The Security Parameter Index (SPI) within any of the > > > > authentication > > > > > Extensions defines the security context which is > > used to compute > > > > > the Authenticator value and which MUST be used by > > the receiver to > > > > > check that value. In particular, the SPI selects the > > > > authentication > > > > > algorithm and mode (Section 5.1) and secret (a shared key, or > > > > > appropriate public/private key pair) used in computing the > > > > > Authenticator. In order to ensure interoperability > > > > between different > > > > > implementations of the Mobile IP protocol, an > > > > implementation MUST be > > > > > able to associate any SPI value with any > > authentication algorithm > > > > > and mode which it implements. In addition, all > > implementations > > > > > of Mobile IP MUST implement the default > > authentication algorithm > > > > > (HMAC-MD5) defined above. > > > > > > > > > > > > > > > > > > > > > > > > >5.1. Message Authentication Codes > > > > > > > > > > Home agents and mobile nodes MUST be able to perform > > > > authentication. > > > > > The default algorithm is HMAC-MD5 [22], with a key > > size of 128 > > > > > bits. The foreign agent MUST also support > > > > authentication using HMAC-MD5 > > > > > and key sizes of 128 bits or greater, with manual key > > > > distribution. Keys > > > > > with arbitrary binary values MUST be supported. > > > > > > > > > > The "prefix+suffix" use of MD5 to protect data and a > > > > shared secret is > > > > >considered > > > > > vulnerable to attack by the cryptographic community. > > > > Where backward > > > > >compatibility > > > > > with existing Mobile IP implementations that use this > > > > mode is needed, > > > > > new implementations SHOULD include keyed MD5 [39] as > > one of the > > > > >additional > > > > > authentication algorithms for use when producing and > > > > verifying the > > > > > authentication data that is supplied with Mobile IP > > registration > > > > > messages, for instance in the extensions specified in > > > > sections 3.5.2, > > > > > 3.5.3, and 3.5.4. > > > > > > > > > > The previously specified operation uses keyed-MD5 [39] in > > > > > "prefix+suffix" mode to compute a 128-bit "message > > digest" of the > > > > > registration message. The default authenticator is a > > > > 128-bit value > > > > > computed as the MD5 checksum over the the following > > > > stream of bytes: > > > > > > > > > > - the shared secret defined by the mobility security > > > > association > > > > > between the nodes and by the SPI value specified in the > > > > > authentication Extension, followed by > > > > > > > > > > - the protected fields from the registration message, > > > > in the order > > > > > specified above, followed by > > > > > > > > > > - the shared secret again. > > > > > > > > > > More authentication algorithms, algorithm modes, key > > distribution > > > > >methods, > > > > > and key sizes MAY also be supported for all of these > > extensions. > > > > > > From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 13 17:39:33 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15657 for ; Fri, 13 Jul 2001 17:39: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 OAA05694; Fri, 13 Jul 2001 14:39:23 -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 OAA24643; Fri, 13 Jul 2001 14:37:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6DLaKR16081 for mobile-ip-dist; Fri, 13 Jul 2001 14:36:20 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6DLaGN16074 for ; Fri, 13 Jul 2001 14:36:16 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA05141 for ; Fri, 13 Jul 2001 14:36:27 -0700 (PDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA03609 for ; Fri, 13 Jul 2001 14:36:17 -0700 (PDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f6DLaFN27475 for ; Fri, 13 Jul 2001 23:36:15 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Fri Jul 13 23:36:14 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Fri, 13 Jul 2001 23:36:14 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008AEA@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Cc: carlw@jurassic.Eng.Sun.COM Subject: [mobile-ip] comments on draft-ietf-mobileip-lmm-requirements-00.txt Date: Fri, 13 Jul 2001 23:36:11 +0200 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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Carl, Thanks for putting this draft together. I have the following comments: - Ch 1: I don't thinkthat not changing the MN was actually a goal. If we can't change the MN, HA or CN then we can't do anything :) Or did you mean we can add to the MN but not change the existing behaviour ? I don't really get this line. - Ch 3.2.1: In the last line there seems to be an assumption that LMM agents are communicating with each other. This may not necessarily be true. - ch 3.4.1: Someone proposed better text for this chapter, I think it might have been James Kempf. I believe the proposal was that the LMM archiecture should scale linearly with the increase in the number of MNs. Or soething along these line. I think this is better than saying it should support a "large" number of hosts. - ch 3.4.4: I disagree with the first paragraph. There is certainly a way of avoiding this. Erik's Site prefixes draft provides us means of knowing whether a CN is in the same site or not. If it is then triangular routing can be avoided by using standard MIPv6. Granted this may cause an additional BU to be sent, but the problem can certainly be avoide. I do agree with the second pargraph though. - ch 3.5.4: FAs ? - ch 3.6: Could you elaborate on this please. I don't get it. - ch 3.7.1: I think this SHOULD be a SHOULD or MUST actually. Supporting FMIPv6 is very important and we shouldn't expect operators to have to choose one or the other. Both should coexist. Overall, I think the draft was well written. Thanks, Hesham From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 13 19:52:56 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA01723 for ; Fri, 13 Jul 2001 19:52:55 -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 QAA17463; Fri, 13 Jul 2001 16:53:11 -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 QAA21357; Fri, 13 Jul 2001 16:51:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6DNo5b16252 for mobile-ip-dist; Fri, 13 Jul 2001 16:50:05 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6DNo2N16245 for ; Fri, 13 Jul 2001 16:50:02 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA21122 for ; Fri, 13 Jul 2001 16:50:12 -0700 (PDT) From: Franck.Le@nokia.com Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA27379 for ; Fri, 13 Jul 2001 16:50:11 -0700 (PDT) Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f6DNodI10637 for ; Fri, 13 Jul 2001 18:50:49 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Fri, 13 Jul 2001 18:50:01 -0500 content-class: urn:content-classes:message Subject: [mobile-ip] Diameter Mobile IPv6 Application Date: Fri, 13 Jul 2001 18:50:01 -0500 Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B041F88AF@daeis07nok> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [mobile-ip] bicasting draft X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 Thread-Index: AcEL4LDIF689ZXfTEdWJUgAIx6TWpQAFQzgg To: Cc: , , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f6DNo2N16246 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, A new draft titled Diameter Mobile IPv6 Application has been submitted today to the AAA WG list. The draft specifies a new Application to Diameter for Mobile IPv6, allowing an IPv6 mobile node to receive service from foreign service providers thanks to the support of inter domain roaming by the AAA infrastructure. The draft describes a solution that allows the Diameter infrastructure to authenticate and authorize an IPv6 mobile node, distribute security keys to enable the provisioning of services to the IPv6 mobile node, and perform and optimize mobility procedures for the IPv6 mobile node. The draft defines also enhanced features that allow for the development of new business models for service providers Thank you, Franck From owner-mobile-ip@sunroof.eng.sun.com Sun Jul 15 16:19:03 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA24557 for ; Sun, 15 Jul 2001 16:19:03 -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 NAA16404; Sun, 15 Jul 2001 13:14: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 NAA29157; Sun, 15 Jul 2001 13:12:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6FKAdN18935 for mobile-ip-dist; Sun, 15 Jul 2001 13:10:39 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6FKAZN18928 for ; Sun, 15 Jul 2001 13:10:35 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA23362 for ; Sun, 15 Jul 2001 13:10:47 -0700 (PDT) Received: from zcars0mt. ([47.129.242.181]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id NAA16399 for ; Sun, 15 Jul 2001 13:10:46 -0700 (PDT) Received: by zcars0mt. (SMI-8.6/SMI-SVR4) id QAA12064; Sun, 15 Jul 2001 16:07:02 -0400 Date: Sun, 15 Jul 2001 16:07:02 -0400 Message-Id: <200107152007.QAA12064@zcars0mt.> To: mobile-ip@sunroof.eng.sun.com From: Behcet Sarikaya Subject: Re: [mobile-ip] RE: [seamoby] Resend:New Draft:Issues in Candidate Content-Type: multipart/alternative; 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: --------------2EF20710B1BF3CBE7F983F22 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Jim, Has this work been triggered by an email from Micheal Tanis? Since router discovery is of routing area, does your draft fall in seamoby 's charter? Just asking. James Kempf wrote: > Phil, > > Thanx for the positive comments. > > Regarding macrodiversity, I tend to look at it as an L2 issue. I know > that in the past you've expressed a view that it can be upleveled > to IP, but I'm not exactly clear what benefit that might have, especially > since packet sizes in IP are large and variable. > > If you look at it that way, it falls more into the purview of the > pwe3 working group. I've been wanting to tune in there and see whether > it might not be possible to get some work going for cellular RANs, > but have simply not had the time. > > Looking forward to seeing your protocol for CAR discovery. > > jak > > >Delivered-To: seamoby-list@charizard.diameter.org > >From: Phillip Neumiller > >To: "'Govind.Krishnamurthi@nokia.com'" , > mobile-ip@sunroof.eng.sun.com > >Cc: seamoby@cdma-2000.org > >Subject: RE: [seamoby] Resend:New Draft:Issues in Candidate Access Router > Discovery > >Date: Fri, 13 Jul 2001 11:36:46 -0400 > > > >Amazing. I am stunned. Great start! More useful comments > >later... One comment right now is that I have a candidate > >algorithm in mind (:-)), also I am again finding it difficult > >to see how this will work with macro-diversity since you may > >want to have legs across ARs in different ADs but more on that > >later. > > > >This draft moves MIP from blind faith to "enlightenment" > >a mobility renaissance is under way in the MIP WG!!! > > > >> -----Original Message----- > >> From: Govind.Krishnamurthi@nokia.com > >> [mailto:Govind.Krishnamurthi@nokia.com] > >> > >> Abstract: > >> Handoff in IP mobility protocols involves moving a mobile node's > >> Layer 3 routing reachability information from one access router to > >> another, before or after the mobile node has established a Layer 2 > >> connection with the radio access point that is covered by the new > >> access router. In addition, other context information about the > >> mobile node's packet session may be transferred from the old access > >> router to the new one, in order to minimize the service disruption > >> during the handoff process. While the exact details of how this is > >> accomplished vary depending on the IP mobility and seamless handoff > >> protocols, one common thread required for seamless handoffs is > >> identifying the candidate access routers for the mobile node's > >> handoff. When a collection of candidates has been identified, an > >> algorithm is run to determine the target access router, and this > >> router becomes the target of handoff at Layer 3. This document > >> presents a problem statement describing issues involved in designing > >> a candidate access router discovery protocol. The document does not > >> discuss the algorithm by which the actual target router is > >> identified, nor how the handoff to the target is achieved. > > > >> -- Behcet --------------2EF20710B1BF3CBE7F983F22 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Jim,
  Has this work been triggered by an email from Micheal Tanis?
Since router discovery is of routing area, does your draft fall in seamoby 's charter?

Just asking.

James Kempf wrote:

Phil,

Thanx for the positive comments.

Regarding macrodiversity, I tend to look at it as an L2 issue. I know
that in the past you've expressed a view that it can be upleveled
to IP, but I'm not exactly clear what benefit that might have, especially
since packet sizes in IP are large and variable.

If you look at it that way, it falls more into the purview of the
pwe3 working group. I've been wanting to tune in there and see whether
it might not be possible to get some work going for cellular RANs,
but have simply not had the time.

Looking forward to seeing your protocol for CAR discovery.

                jak

>Delivered-To: seamoby-list@charizard.diameter.org
>From: Phillip Neumiller <PNeumiller@MeshNetworks.com>
>To: "'Govind.Krishnamurthi@nokia.com'" <Govind.Krishnamurthi@nokia.com>,
mobile-ip@sunroof.eng.sun.com
>Cc: seamoby@cdma-2000.org
>Subject: RE: [seamoby] Resend:New Draft:Issues in Candidate Access Router
Discovery
>Date: Fri, 13 Jul 2001 11:36:46 -0400
>
>Amazing.  I am stunned.  Great start!  More useful comments
>later...  One comment right now is that I have a candidate
>algorithm in mind (:-)), also I am again finding it difficult
>to see how this will work with macro-diversity since you may
>want to have legs across ARs in different ADs but more on that
>later.
>
>This draft moves MIP from blind faith to "enlightenment"
>a mobility renaissance is under way in the MIP WG!!!
>
>> -----Original Message-----
>> From: Govind.Krishnamurthi@nokia.com
>> [mailto:Govind.Krishnamurthi@nokia.com]
>>
>> Abstract:
>> Handoff in IP mobility protocols involves moving a mobile node's
>> Layer 3 routing reachability information from one access router to
>> another, before or after the mobile node has established a Layer 2
>> connection with the radio access point that is covered by the new
>> access router. In addition, other context information about the
>> mobile node's packet session may be transferred from the old access
>> router to the new one, in order to minimize the service disruption
>> during the handoff process. While the exact details of how this is
>> accomplished vary depending on the IP mobility and seamless handoff
>> protocols, one common thread required for seamless handoffs is
>> identifying the candidate access routers for the mobile node's
>> handoff. When a collection of candidates has been identified, an
>> algorithm is run to determine the target access router, and this
>> router becomes the target of handoff at Layer 3. This document
>> presents a problem statement describing issues involved in designing
>> a candidate access router discovery protocol. The document does not
>> discuss the algorithm by which the actual target router is
>> identified, nor how the handoff to the target is achieved.
>
>>

--
Behcet --------------2EF20710B1BF3CBE7F983F22-- ------- From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 16 03:41:42 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA18559 for ; Mon, 16 Jul 2001 03:41:41 -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 BAA04663; Mon, 16 Jul 2001 01:41: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 AAA05233; Mon, 16 Jul 2001 00:40:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6G7ZEK19661 for mobile-ip-dist; Mon, 16 Jul 2001 00:35:14 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6G7ZBN19654 for ; Mon, 16 Jul 2001 00:35: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 AAA29168 for ; Mon, 16 Jul 2001 00:35:19 -0700 (PDT) From: john.loughney@nokia.com Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA01652 for ; Mon, 16 Jul 2001 01:35:16 -0600 (MDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f6G7ZmI01972 for ; Mon, 16 Jul 2001 10:35:48 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Mon, 16 Jul 2001 10:35:16 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MS40M95>; Mon, 16 Jul 2001 10:35:16 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF094063@esebe004.NOE.Nokia.com> To: mobile-ip@sunroof.eng.sun.com Cc: carlw@jurassic.Eng.Sun.COM Subject: RE: [mobile-ip] comments on draft-ietf-mobileip-lmm-requirements- 00.txt Date: Mon, 16 Jul 2001 10:35:12 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) 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: Hi Hesham, > - Ch 1: I don't thinkthat not changing the MN was actually a goal. > If we can't change the MN, HA or CN then we can't do anything :) > Or did you mean we can add to the MN but not change the existing > behaviour ? I don't really get this line. I suggested to Carl that he insert some goals into section 1 - I meant more that we minimize changes to the MN, HA & CN to a minimum (implementations of LMM enabled nodes shouldn't be radically changed). This should be especially true to the CN. The CN should not care if it is speaking to a vanila-MN or a LMM-enhanced MN (in my opinion). > - Ch 3.2.1: In the last line there seems to be an assumption that > LMM agents are communicating with each other. This may not > necessarily be true. If LMM agents are not communicating with each other, then we have de-facto replay protection! > - ch 3.7.1: I think this SHOULD be a SHOULD or MUST actually. > Supporting FMIPv6 is very important and we shouldn't expect > operators to have to choose one or the other. Both should > coexist. Since your last sentence uses '... should coexist', doesn't this argue the case for a SHOULD - or do you mean ' ... MUST co-exist.' best regards, John From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 16 07:00:27 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA10301 for ; Mon, 16 Jul 2001 07:00:26 -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 EAA09389; Mon, 16 Jul 2001 04:00:36 -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 EAA11714; Mon, 16 Jul 2001 04:00:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6GAx1U19874 for mobile-ip-dist; Mon, 16 Jul 2001 03:59:01 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6GAwuN19867 for ; Mon, 16 Jul 2001 03:58:57 -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 DAA22701 for ; Mon, 16 Jul 2001 03:59:08 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA29984 for ; Mon, 16 Jul 2001 04:59:05 -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 GAA09647; Mon, 16 Jul 2001 06:58:13 -0400 (EDT) Message-Id: <200107161058.GAA09647@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-kempf-beth-ipv6-01.txt Date: Mon, 16 Jul 2001 06:58:13 -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. Title : Bidirectional Edge Tunnel Handover for IPv6 Author(s) : J. Kempf Filename : draft-kempf-beth-ipv6-01.txt Pages : Date : 13-Jul-01 This document discusses an extension to the Fast Mobile IPv6 handover protocol described in draft-ietf-mobileip-fastmipv6-01.txt that reduces the amount of L3 latency in Mobile IPv6 handover to zero. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kempf-beth-ipv6-01.txt 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-kempf-beth-ipv6-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-kempf-beth-ipv6-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: <20010713123819.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-kempf-beth-ipv6-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-kempf-beth-ipv6-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010713123819.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 16 07:01:42 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA10795 for ; Mon, 16 Jul 2001 07:01: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 FAA01409; Mon, 16 Jul 2001 05:01:49 -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 EAA11862; Mon, 16 Jul 2001 04:01:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6GB0F119910 for mobile-ip-dist; Mon, 16 Jul 2001 04:00:15 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6GB0AN19903 for ; Mon, 16 Jul 2001 04:00:10 -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 EAA11677 for ; Mon, 16 Jul 2001 04:00:21 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA00486 for ; Mon, 16 Jul 2001 05:00:18 -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 GAA10001; Mon, 16 Jul 2001 06:59:26 -0400 (EDT) Message-Id: <200107161059.GAA10001@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-li-mobileip-lmm-framework-00.txt Date: Mon, 16 Jul 2001 06:59:26 -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. Title : Local Mobility Management Framework Author(s) : H. Li Filename : draft-li-mobileip-lmm-framework-00.txt Pages : 13 Date : 13-Jul-01 The mobile wireless access networks are converging towards IP-based architecture that enables interconnect of different layer 2 radio access systems. IP-based local (or micro) mobility management (LMM) solution is the key to unify the different layer 2 mobility management solutions in the new architecture. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-li-mobileip-lmm-framework-00.txt 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-li-mobileip-lmm-framework-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-li-mobileip-lmm-framework-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: <20010713124045.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-li-mobileip-lmm-framework-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-li-mobileip-lmm-framework-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010713124045.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 16 07:02:47 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA11214 for ; Mon, 16 Jul 2001 07:02:47 -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 EAA10223; Mon, 16 Jul 2001 04:02:50 -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 EAA12048; Mon, 16 Jul 2001 04:02:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6GB1Kp19962 for mobile-ip-dist; Mon, 16 Jul 2001 04:01:20 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6GB1FN19954 for ; Mon, 16 Jul 2001 04:01:15 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA11847 for ; Mon, 16 Jul 2001 04:01:27 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA13887 for ; Mon, 16 Jul 2001 04:01:26 -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 HAA10339; Mon, 16 Jul 2001 07:00:32 -0400 (EDT) Message-Id: <200107161100.HAA10339@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: mobile-ip@sunroof.eng.sun.com, seamoby@cdma-2000.org From: Internet-Drafts@ietf.org Subject: [mobile-ip] I-D ACTION:draft-manyfolks-l2-mobilereq-00.txt Date: Mon, 16 Jul 2001 07:00:32 -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. Title : Requirements for Layer 2 Protocols to Support Optimized Handover for IP Mobility Author(s) : J. Kempf et al. Filename : draft-manyfolks-l2-mobilereq-00.txt Pages : Date : 13-Jul-01 A critical factor in achieving good performance for IP mobility protocols is the design of L2 handover. Handover occurs when a Mobile Node moves from one radio Access Point to another. If the new radio Access Point is associated with a new subnet, a change in routing reachability may occur and require L3 protocol action on the part of the Mobile Node or Access Routers. If no change in subnet occurs, the Access Point may still need to take some action to inform the Access Router about a change in on-link reachability. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-manyfolks-l2-mobilereq-00.txt 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-manyfolks-l2-mobilereq-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-manyfolks-l2-mobilereq-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: <20010713124228.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-manyfolks-l2-mobilereq-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-manyfolks-l2-mobilereq-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010713124228.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 16 07:03:47 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA11514 for ; Mon, 16 Jul 2001 07:03:47 -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 EAA10574; Mon, 16 Jul 2001 04:03:54 -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 EAA12225; Mon, 16 Jul 2001 04:03:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6GB2Vi19999 for mobile-ip-dist; Mon, 16 Jul 2001 04:02:31 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6GB2QN19992 for ; Mon, 16 Jul 2001 04:02:26 -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 EAA12052 for ; Mon, 16 Jul 2001 04:02:37 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA02010 for ; Mon, 16 Jul 2001 05:02:35 -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 HAA10757; Mon, 16 Jul 2001 07:01:36 -0400 (EDT) Message-Id: <200107161101.HAA10757@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-team-mobileip-mipv6-sec-reqts-00.txt Date: Mon, 16 Jul 2001 07:01:36 -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. Title : Threat Models introduced by Mobile IPv6 and Requirements for Security in Mobile IPv6 Author(s) : P. Nikander et al. Filename : draft-team-mobileip-mipv6-sec-reqts-00.txt Pages : 26 Date : 13-Jul-01 The IESG returned the MIP v6 draft to the working group due to concerns about the security and scalability of binding updates and the associated IPSEC processing that is specified in the draft. Since that time discussions have continued to attempt to define what is really needed to make binding updates secure. In the course of discussing the requirements it became apparent that a threat model is needed in order to adequately specify the security requirements. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-team-mobileip-mipv6-sec-reqts-00.txt 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-team-mobileip-mipv6-sec-reqts-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-team-mobileip-mipv6-sec-reqts-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: <20010713124422.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-team-mobileip-mipv6-sec-reqts-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-team-mobileip-mipv6-sec-reqts-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010713124422.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 16 07:41:44 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA16374 for ; Mon, 16 Jul 2001 07:41:43 -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 FAA18487; Mon, 16 Jul 2001 05:41: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 EAA14791; Mon, 16 Jul 2001 04:41:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6GBeIw20243 for mobile-ip-dist; Mon, 16 Jul 2001 04:40:18 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6GBeEN20236 for ; Mon, 16 Jul 2001 04:40: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 EAA20025 for ; Mon, 16 Jul 2001 04:40:26 -0700 (PDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA17939 for ; Mon, 16 Jul 2001 05:40:23 -0600 (MDT) Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f6GBeOO15895 for ; Mon, 16 Jul 2001 13:40:24 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Mon Jul 16 13:40:23 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Mon, 16 Jul 2001 13:40:23 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008AEC@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Cc: carlw@jurassic.Eng.Sun.COM Subject: RE: [mobile-ip] comments on draft-ietf-mobileip-lmm-requirements- 00.txt Date: Mon, 16 Jul 2001 13:40:19 +0200 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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi John, > > - Ch 1: I don't thinkthat not changing the MN was actually a goal. > > If we can't change the MN, HA or CN then we can't do anything :) > > Or did you mean we can add to the MN but not change the existing > > behaviour ? I don't really get this line. > > I suggested to Carl that he insert some goals into section 1 - > I meant more that we minimize changes to the MN, HA & CN to a > minimum (implementations of LMM enabled nodes shouldn't be > radically changed). > => Maybe the wording needs to be clarified because it doesn't reflect that. I completely agree with minimising the changes and eliminating them for the CN and the HA if possible. > This should be especially true to the CN. > The CN should not care if it is speaking to a vanila-MN or a > LMM-enhanced MN (in my opinion). > => Sure. > > - Ch 3.2.1: In the last line there seems to be an assumption that > > LMM agents are communicating with each other. This may not > > necessarily be true. > > If LMM agents are not communicating with each other, then we > have de-facto replay protection! > => I'm just saying that this is an unnecessary assumption. > > > - ch 3.7.1: I think this SHOULD be a SHOULD or MUST actually. > > Supporting FMIPv6 is very important and we shouldn't expect > > operators to have to choose one or the other. Both should > > coexist. > > Since your last sentence uses '... should coexist', doesn't > this argue the case for a SHOULD - or do you mean ' ... MUST > co-exist.' > => The current requirement says it's a MAY. I think it should be a MUST. Sorry for the confusing statement. Regards, Hesham From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 16 08:13:44 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA21598 for ; Mon, 16 Jul 2001 08:13: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 GAA02237; Mon, 16 Jul 2001 06:13: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 FAA16731; Mon, 16 Jul 2001 05:12:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6GCAxp20295 for mobile-ip-dist; Mon, 16 Jul 2001 05:10:59 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6GCAtN20288 for ; Mon, 16 Jul 2001 05:10:55 -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 FAA21987 for ; Mon, 16 Jul 2001 05:11:07 -0700 (PDT) Received: from postfix.informatik.uni-bonn.de (postfix.informatik.uni-bonn.de [131.220.131.28]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA08728 for ; Mon, 16 Jul 2001 06:12:22 -0600 (MDT) Received: from cs.uni-bonn.de (beirut.informatik.uni-bonn.de [131.220.6.161]) by postfix.informatik.uni-bonn.de (Postfix) with ESMTP id CD78970C69 for ; Mon, 16 Jul 2001 14:11:04 +0200 (MEST) (envelope-from hansmann@cs.uni-bonn.de) (envelope-to mobile-ip@sunroof.eng.sun.com) (1) (internal use: ta=1, tu=1, te=0, am=-, au=NULL) Message-ID: <3B52DAD4.8B7AA985@cs.uni-bonn.de> Date: Mon, 16 Jul 2001 14:15:16 +0200 From: Wolfgang Hansmann X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] new draft References: <034BEFD03799D411A59F00508BDF754603008AE1@esealnt448.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 [draft-soliman-mobileip-flow-move-00.txt] Browsing the draft over and over again an issue pops up I do not get behind. IMHO the protocol fields specified in the Flow movement suboption are not sufficient to describe flow redirection. - Suppose we have a flow sent by a CN and directed to a MN. - Always keep in mind that a flow is uniquely described either by (src_addr, src_port, dst_addr, dst_port, protocol) or by (src_addr, flowlabel), if flowlabel is nonzero. According to the draft the suboption can sent either to a CN, a MAP or a HA to redirect a flow to a particular CoA. Case #1: BU with Flow movement suboption sent to a CN In a PM Hesham told me the "Destination address" field contains the MN's CoA. However, this information is already contained in either the IP header source address fields or the alternate CoA option of the BU. So this field seems to be redundant in this case. If the "P" flag is set, then we only have (dst_port, protocol, dst_addr, src_addr) to describe a flow. This is not enough to describe a flow sent as the src_port is missing. (Suppose the MN offers a service on a dedicated TCP port x. Two individual applications running on the CN establish a connection to the MN's TCP port x. In this case, the MN cannot redirect one of these flows to a different CoA) Case #2: BU with Flow movement suboption sent to a MAP If the "P" flag is set the MAP has no infortmation on src_port and src_address of a flow. If the "F" flag is set, then the MAP has no information on the src_addr of the flow. (Suppose the MN offers again a service on a dedicated TCP port x. Two individual applications running on different CNs establish a connection to the MN's TCP port x. Yet again, the MN cannot redirect one of these flows to a different CoA) Case #3: BU with Flow movement suboption sent to a HA should be somewhat similar to case #2 (?) Hope somebody could enlighten me, Wolfgang From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 16 08:38:37 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA26623 for ; Mon, 16 Jul 2001 08:38:36 -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 GAA14446; Mon, 16 Jul 2001 06:38: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 FAA26485; Mon, 16 Jul 2001 05:37:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6GCZsb20361 for mobile-ip-dist; Mon, 16 Jul 2001 05:35:54 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6GCZoN20354 for ; Mon, 16 Jul 2001 05:35:50 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA18656 for ; Mon, 16 Jul 2001 05:36:03 -0700 (PDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA09327 for ; Mon, 16 Jul 2001 05:36:02 -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.11.0/8.11.0/WIREfire-1.3) with SMTP id f6GCa1N25234 for ; Mon, 16 Jul 2001 14:36:01 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Mon Jul 16 14:36:00 2001 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 16 Jul 2001 14:30:00 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008AEF@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] new draft Date: Mon, 16 Jul 2001 14:35:55 +0200 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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > [draft-soliman-mobileip-flow-move-00.txt] > > Browsing the draft over and over again an issue pops up I do not get > behind. IMHO the protocol fields specified in the Flow movement > suboption are not sufficient to describe flow redirection. > > - Suppose we have a flow sent by a CN and directed to a MN. > > - Always keep in mind that a flow is uniquely described either by > > (src_addr, src_port, dst_addr, dst_port, protocol) or by > (src_addr, flowlabel), if flowlabel is nonzero. > > According to the draft the suboption can sent either to a CN, a MAP > or a HA to redirect a flow to a particular CoA. > > Case #1: BU with Flow movement suboption sent to a CN > > In a PM Hesham told me the "Destination address" field contains the > MN's CoA. However, this information is already contained in either the > IP header source address fields or the alternate CoA option of the > BU. So this field seems to be redundant in this case. > => The Destination address, is the CoA that the MN is requesting the C/HA/MAP to send the flow to. > If the "P" flag is set, then we only have (dst_port, protocol, > dst_addr, src_addr) to describe a flow. This is not enough to > describe a flow sent as the src_port is missing. > > (Suppose the MN offers a service on a dedicated TCP port x. Two > individual applications running on the CN establish a connection to > the MN's TCP port x. In this case, the MN cannot redirect one of > these flows to a different CoA) > > => Right, this is a case we didn't actually consider. Or consideration was for the case where you want an application to run on one interface for all CNs. But I can see that this case (you mention above) maybe important as well. So if we add a filed for the src address and allow for an option where the MN says "forward all flows to this dest address regardless of what the source is". guess this is more applicable to case 2 below, because if the BU is sent to the CN there is only one source. Or do you want to split the traffic from the CN as well ? I think this is unnecessary. > Case #2: BU with Flow movement suboption sent to a MAP > > If the "P" flag is set the MAP has no infortmation on > src_port and src_address of a flow. If the "F" flag is set, then > the MAP has no information on the src_addr of the flow. > > (Suppose the MN offers again a service on a dedicated TCP port x. > Two individual applications running on different CNs establish a > connection to the MN's TCP port x. Yet again, the MN cannot redirect > one of these flows to a different CoA) > => Got it. I'll add a src address field. This should cover all cases right ? I don't think we really need a src port number. Just trying to save bits. > Case #3: BU with Flow movement suboption sent to a HA > > should be somewhat similar to case #2 (?) > Thanks, Hesham From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 16 08:47:21 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA28767 for ; Mon, 16 Jul 2001 08:47:20 -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 GAA19589; Mon, 16 Jul 2001 06:47: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 FAA27188; Mon, 16 Jul 2001 05:46:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6GCiqW20415 for mobile-ip-dist; Mon, 16 Jul 2001 05:44:52 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6GCinN20408 for ; Mon, 16 Jul 2001 05:44:49 -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 FAA19309 for ; Mon, 16 Jul 2001 05:45:01 -0700 (PDT) Received: from RRMAIL01.RADIOROUTER_NT ([63.103.94.23]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA18012 for ; Mon, 16 Jul 2001 06:44:59 -0600 (MDT) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id <317T3Z60>; Mon, 16 Jul 2001 08:44:54 -0400 Message-ID: <8C92E23A3E87FB479988285F9E22BE46054673@ftmail> From: George Tsirtsis To: mobile-ip@sunroof.eng.sun.com, seamoby@cdma-2000.org Subject: [mobile-ip] Comments on: I-D ACTION:draft-manyfolks-l2-mobilereq-00.txt Date: Mon, 16 Jul 2001 08:43: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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: First of all to say again that this is useful work...sorry for the large number of comments but I hope you will find them constructive. 1. In section 3.1 you explain what an L2 Trigger is. " An L2 trigger is an abstraction of a notification from L2 (potentially including parameter information) that a certain event has happened or is about to happen. " I would continue to clarify with something like that: "...The L2 Trigger is delivered to the IP layer so that IP protocols aware of this trigger can act accordingly. The purpose of this specification is to standardize a set of triggers with their meaning and parameters they carry. How the triggers are created is outside the scope of this document and should be defined on a per L2 Protocols bases." 2. Why is Section 4 in this draft? Why do we examine triggers for L2 Handoffs...I think this is out of scope? Section 5 describes use of triggers with L3 Handoffs which is in scope and all we need... 3. In the table in Section 5 I have a different view on the concept of "Recipient" of the various Triggers described. I think the "Recipient" is the *IP Layer* in either the AR or the MN. Whether the trigger comes via an AP or not is not relevant IMO. The consideration of the AP, however, is sometime useful in the spec (e.g.: some times you need the AP's L2 addr if one is used). Still the AP itself is never the recipient of the trigger...i.e.: the AP does not act on trigger reception, apart from forwarding it to the AR as normal. 4. I suggest the table in section 5 to be expanded and each Trigger to be described in a bit more detailed...the sort, table descriptions, are a bit nebulous...BTW, what is the purpose of "L2 Handover Start" Trigger?? 5. Section 6.1.: " Although this timing requirement is loosely defined, it is desirable to initiate reactive CT sometime before (or about the same time as) the L2 handoff initiation. " Please define "L2 Handoff" in the spec...it keeps confusing me...to my mind we are only talking about L2 Handoffs here...so, what do you mean above? similar things appear throughout the doc... 6. Section 6.2 defines CT related triggers, why are these different from the ones in Section 5?? Surely the Source/Dest Triggers defined in section 5 can (optionally?) include the information required for the triggers defined in 6.2. Also why do you have CT triggers going to the MN? and why both reactive and proactive triggers go to both old and new ARs? 7. Section 7: " While the primary purpose of L2 triggers described in this draft is to aid L2 mobility optimization, L2 triggers can also benefit networks without Mobile IP or other IP mobility protocol support. " ...to aid L2 mobility optimization???? you mean L3 mobility optimization? or the term confuses me again? Thanks and again good work! George From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 16 09:18:52 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA06148 for ; Mon, 16 Jul 2001 09:18:51 -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 GAA19384; Mon, 16 Jul 2001 06:18: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 GAA00777; Mon, 16 Jul 2001 06:18:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6GDH1l20490 for mobile-ip-dist; Mon, 16 Jul 2001 06:17:01 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6GDGwN20483 for ; Mon, 16 Jul 2001 06:16:58 -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 GAA22434 for ; Mon, 16 Jul 2001 06:17:10 -0700 (PDT) Received: from postfix.informatik.uni-bonn.de (postfix.informatik.uni-bonn.de [131.220.131.28]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA07237 for ; Mon, 16 Jul 2001 07:18:25 -0600 (MDT) Received: from cs.uni-bonn.de (beirut.informatik.uni-bonn.de [131.220.6.161]) by postfix.informatik.uni-bonn.de (Postfix) with ESMTP id 6F7BC70C8A for ; Mon, 16 Jul 2001 15:17:08 +0200 (MEST) (envelope-from hansmann@cs.uni-bonn.de) (envelope-to mobile-ip@sunroof.eng.sun.com) (1) (internal use: ta=1, tu=1, te=0, am=-, au=NULL) Message-ID: <3B52EA4F.CED1BBAA@cs.uni-bonn.de> Date: Mon, 16 Jul 2001 15:21:19 +0200 From: Wolfgang Hansmann X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] new draft References: <034BEFD03799D411A59F00508BDF754603008AEF@esealnt448.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: > > > [draft-soliman-mobileip-flow-move-00.txt] > > [...] > > In a PM Hesham told me the "Destination address" field contains the > > MN's CoA. However, this information is already contained in either the > > IP header source address fields or the alternate CoA option of the > > BU. So this field seems to be redundant in this case. > > > => The Destination address, is the CoA that the MN is requesting > the C/HA/MAP to send the flow to. I forgot the fact that several flow move suboptions can be contained in a single BU. OK - this field's necessary. [...] > > (Suppose the MN offers a service on a dedicated TCP port x. Two > > individual applications running on the CN establish a connection to > > the MN's TCP port x. In this case, the MN cannot redirect one of > > these flows to a different CoA) > > > => Right, this is a case we didn't actually consider. Or consideration > was for the case where you want an application to run on > one interface for all CNs. > But I can see that this case (you mention above) maybe important > as well. So if we add a filed for the src address and allow for > an option where the MN says "forward all flows to this dest > address regardless of what the source is". > guess this is more applicable to case 2 below, because > if the BU is sent to the CN there is only one source. Or > do you want to split the traffic from the CN as well ? > I think this is unnecessary. IMHO it should work for all flows, regardless if they're sent by a single CN or different CNs. Remember: it's the "Flow movement suboption" and not the "Flow movement suboption applicable to all flows except those originated at the same CN" :-) > > Case #2: BU with Flow movement suboption sent to a MAP [...] > > (Suppose the MN offers again a service on a dedicated TCP port x. > > Two individual applications running on different CNs establish a > > connection to the MN's TCP port x. Yet again, the MN cannot redirect > > one of these flows to a different CoA) > > > => Got it. I'll add a src address field. This should cover all > cases right ? I don't think we really need a src port number. > Just trying to save bits. Well, that's only 16 additional tiny bits. If you really want to save header space, then you should consider to specify 2 sub-options. One for flows identified by (src/dst addr, src/dst port and protocol) and one for flows identified by (src_addr, flowlabel). Remember - if the "P" flag is set you have "flowlabel + reserved" = 29 bits of idle header space. Otherwise If the "F" flag is set then you have 24 idle bits. Wolfgang From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 16 09:31:58 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA08205 for ; Mon, 16 Jul 2001 09:31:56 -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 GAA24329; Mon, 16 Jul 2001 06:32: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 GAA01885; Mon, 16 Jul 2001 06:31:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6GDTSj20540 for mobile-ip-dist; Mon, 16 Jul 2001 06:29:28 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6GDTON20533 for ; Mon, 16 Jul 2001 06:29:24 -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 GAA28641 for ; Mon, 16 Jul 2001 06:29:37 -0700 (PDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA15517 for ; Mon, 16 Jul 2001 07:29:34 -0600 (MDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f6GDTZN29379 for ; Mon, 16 Jul 2001 15:29:35 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Mon Jul 16 15:29:30 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Mon, 16 Jul 2001 15:29:34 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008AF0@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] new draft Date: Mon, 16 Jul 2001 15:29:24 +0200 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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > > (Suppose the MN offers a service on a dedicated TCP port x. Two > > > individual applications running on the CN establish a connection to > > > the MN's TCP port x. In this case, the MN cannot redirect one of > > > these flows to a different CoA) > > > > > => Right, this is a case we didn't actually consider. Or consideration > > was for the case where you want an application to run on > > one interface for all CNs. > > But I can see that this case (you mention above) maybe important > > as well. So if we add a filed for the src address and allow for > > an option where the MN says "forward all flows to this dest > > address regardless of what the source is". > > guess this is more applicable to case 2 below, because > > if the BU is sent to the CN there is only one source. Or > > do you want to split the traffic from the CN as well ? > > I think this is unnecessary. > > IMHO it should work for all flows, regardless if they're sent by a > single CN or different CNs. > > Remember: it's the "Flow movement suboption" and not the "Flow > movement suboption applicable to all flows except those originated > at the same CN" :-) > => It will work for all flows but what I was saying (and said it with 200 spelling errors and typos !) is that if the MN is sending the BU to a node other than the CN (HA or MAP) then in many cases you might not care who your client is so you just request that all packets to port X (where you are a server) should be forwarded to CoA_1. This would save some work in the MAP/HA trying to identify what the src address is when it doesn't really matter for the MN. So maybe we could say something like "if the src addr is FFFF .... (or some reserved value) all packets destined to port number X can be forwarded to CoA_2 without checking the src". Is this OK ? > > => Got it. I'll add a src address field. This should cover all > > cases right ? I don't think we really need a src port number. > > Just trying to save bits. > > Well, that's only 16 additional tiny bits. > => :). It maybe 16 X 4 or 5. > If you really want to save > header space, then you should consider to specify 2 sub-options. One > for flows identified by (src/dst addr, src/dst port and protocol) > and one for flows identified by (src_addr, flowlabel). > => Yes that was also planned for the next revision actually, thanks for bringing it up. Thanks, Hesham From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 16 12:58:51 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA22059 for ; Mon, 16 Jul 2001 12:58:51 -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 JAA02999; Mon, 16 Jul 2001 09:58:39 -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 JAA14413; Mon, 16 Jul 2001 09:58:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6GGuac20924 for mobile-ip-dist; Mon, 16 Jul 2001 09:56:36 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6GGuWN20917 for ; Mon, 16 Jul 2001 09:56:32 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id JAA23654; Mon, 16 Jul 2001 09:56:35 -0700 (PDT) Message-Id: <200107161656.JAA23654@heliopolis.eng.sun.com> Date: Mon, 16 Jul 2001 09:56:36 -0700 (PDT) From: James Kempf Subject: [mobile-ip] Mobile Operators REquirements (MORE) BOF To: seamoby@diameter.org, mobile-ip@sunroof.eng.sun.com, urp@research.telcordia.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: mRjSOzCDMAelux9uxHYtLw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 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: Folks, Apologies for the wide posting. Recently, there was a draft posted (draft-reynolds-mobile-isp-requirements-00.txt) that discusses requirements for wireless ISPs (WISPs) for IP protocols related to or impacted by mobility. There has been some discussion on the mailing list (more@psg.com, usual majordomo subscription procedure) about the requirements. We are now in the process of planning for a BOF at IETF 51 in London. If anyone is interested in speaking at the BOF, please send me email. jak From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 16 13:34:32 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA01089 for ; Mon, 16 Jul 2001 13:34:31 -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 KAA21306; Mon, 16 Jul 2001 10:34:48 -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 KAA24167; Mon, 16 Jul 2001 10:34:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6GHVx321080 for mobile-ip-dist; Mon, 16 Jul 2001 10:31:59 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6GHVtN21073 for ; Mon, 16 Jul 2001 10:31:55 -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 KAA23590 for ; Mon, 16 Jul 2001 10:32:08 -0700 (PDT) Received: from p-mail1.cnet.fr (p-mail1.rd.francetelecom.fr [193.49.124.31]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id LAA02042 for ; Mon, 16 Jul 2001 11:32:06 -0600 (MDT) Received: by p-biset.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19) id <3ZABCPR4>; Mon, 16 Jul 2001 19:31:56 +0200 Received: from francetelecom.com (p-dico.rd.francetelecom.fr [139.100.18.135]) by p-grive.rd.francetelecom.fr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3ZBB69XL; Mon, 16 Jul 2001 19:31:51 +0200 Message-ID: <3B5324BD.5E006D45@francetelecom.com> Date: Mon, 16 Jul 2001 19:30:37 +0200 From: Jean-Michel COMBES Organization: France =?iso-8859-1?Q?T=E9l=E9com?= R&D X-Mailer: Mozilla 4.75 [fr] (Windows NT 5.0; U) X-Accept-Language: fr MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] I-D ACTION:draft-team-mobileip-mipv6-sec-reqts-00.txt References: <200107161101.HAA10757@ietf.org> 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 folks, At first : very interesting draft and very good job. Bravo !!! My question : is it the promised draft on requirements for protocols candidate to secure binding mecanisms ? 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 From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 16 14:22:21 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10577 for ; Mon, 16 Jul 2001 14:22: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 LAA15216; Mon, 16 Jul 2001 11:22:08 -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 LAA20524; Mon, 16 Jul 2001 11:21:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6GIJmB21226 for mobile-ip-dist; Mon, 16 Jul 2001 11:19:48 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6GIJiN21219 for ; Mon, 16 Jul 2001 11:19:44 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id LAA27902; Mon, 16 Jul 2001 11:19:55 -0700 (PDT) Message-Id: <200107161819.LAA27902@heliopolis.eng.sun.com> Date: Mon, 16 Jul 2001 11:19:56 -0700 (PDT) From: James Kempf Subject: Re: [mobile-ip] Comments on: I-D ACTION:draft-manyfolks-l2-mobilereq-00.txt To: mobile-ip@sunroof.eng.sun.com, seamoby@cdma-2000.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: ahEMQ88TqPBxAFnLjGpqXg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 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: George, Thanx for you comments. I'll fold them in on the next revision, which will be after IETF 51. Specific responses below. jak >1. In section 3.1 you explain what an L2 Trigger is. >" An L2 trigger is an abstraction of a notification from L2 > (potentially including parameter information) that a certain event > has happened or is about to happen. " >I would continue to clarify with something like that: >"...The L2 Trigger is delivered to the IP layer so that IP protocols aware >of this trigger can act accordingly. The purpose of this specification is to >standardize a set of triggers with their meaning and parameters they carry. >How the triggers are created is outside the scope of this document and >should be defined on a per L2 Protocols bases." > OK. >2. Why is Section 4 in this draft? Why do we examine triggers for L2 >Handoffs...I think this is out of scope? Section 5 describes use of triggers >with L3 Handoffs which is in scope and all we need... > If the AR is not informed that the MN has changed APs, the AR's mapping of L2 address to IP address may be out of date when the MN moves. The AR must either perform proxy ARP (IPv4) or Neighbor Discovery (IPv6) in order to refresh the mapping. With an L2 trigger and an associated update protocol, the AP could specfically tell the AR what the new mapping is. If all the APs have a single radio technology, then one can reasonably argue that this is radio technology specific (even if the protocol to update the AR's mapping is based on IP); however, in the future, it is possible that subnets with mixed technology APs may become more common. So, while the draft does not advocate a particular approach to solving this problem, it does lay out the requirements for allowing it to be solved, should some working group decide they wanted to take on the task. >3. In the table in Section 5 I have a different view on the concept of >"Recipient" of the various Triggers described. I think the "Recipient" is >the *IP Layer* in either the AR or the MN. Whether the trigger comes via an >AP or not is not relevant IMO. The consideration of the AP, however, is >sometime useful in the spec (e.g.: some times you need the AP's L2 addr if >one is used). Still the AP itself is never the recipient of the >trigger...i.e.: the AP does not act on trigger reception, apart from >forwarding it to the AR as normal. > I'm not entirely sure I understand your comment, but let me see. Basically, the idea in the draft is that the AP is not a recipient of the trigger, however, it may be the source. The recipient that is identified in the draft is an IP entity (i.e. an IP host or an IP router, the only entities that there are in IP networks). APs are neither, since they are transparent by definition. So I think we are agreeing on that point. The AP *may* have an IP address if it is engaged in, say, IAPP like traffic to propogate L2 trigger information. At that point, it is acting like an IP host. I agree that, on a particular IP entity identified as a target, the IP stack is the recepient of the trigger. Does this correspond to what you are saying? >4. I suggest the table in section 5 to be expanded and each Trigger to be >described in a bit more detailed...the sort, table descriptions, are a bit >nebulous... OK, I'll look into it. If you have any proposed wording, please send it along. >BTW, what is the purpose of "L2 Handover Start" Trigger?? > See draft-kempf-beth-ipv6-01.txt. It is used to optimize handover smoothing. >5. Section 6.1.: >" Although this timing requirement is > loosely defined, it is desirable to initiate reactive CT sometime > before (or about the same time as) the L2 handoff initiation. " >Please define "L2 Handoff" in the spec...it keeps confusing me...to my mind >we are only talking about L2 Handoffs here...so, what do you mean above? >similar things appear throughout the doc... > OK. > >6. Section 6.2 defines CT related triggers, why are these different from the >ones in Section 5?? Surely the Source/Dest Triggers defined in section 5 can >(optionally?) include the information required for the triggers defined in >6.2. Also why do you have CT triggers going to the MN? and why both reactive >and proactive triggers go to both old and new ARs? > We had some discussion on this among the authors. It is true that there is overlap, we wanted to lay out the requirements separately. The reason is that there is a strong feeling among the CT design team participants that CT should not be tied to a mobility protocol. While I think it is probably worthwhile to lay out the requirements separately, perhaps something should be said about overlap, and maybe put a section in that describes how to satisfy them with a single set of triggers. Does this sound like a good idea? >7. Section 7: >" While the primary purpose of L2 triggers described in this draft is > to aid L2 mobility optimization, L2 triggers can also benefit > networks without Mobile IP or other IP mobility protocol support. " >...to aid L2 mobility optimization???? you mean L3 mobility optimization? or >the term confuses me again? > OK, we probably need to sharpen up the definitions, maybe add one for L3 mobility. The idea in this section was some L2 triggers (like those in Section 4, for example) could be used in nonmobile networks or networks with the nomadic model. > >Thanks and again good work! Thank you for the comments! If you have any text you'd like to see in the document (particularly on the table in Section 5) please send it along. jak From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 16 14:22:36 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10674 for ; Mon, 16 Jul 2001 14:22:35 -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 LAA15586; Mon, 16 Jul 2001 11:22: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 LAA20649; Mon, 16 Jul 2001 11:22:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6GIL0L21240 for mobile-ip-dist; Mon, 16 Jul 2001 11:21:00 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6GIKtN21232 for ; Mon, 16 Jul 2001 11:20:55 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA05686 for ; Mon, 16 Jul 2001 11:21:06 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA20456; Mon, 16 Jul 2001 11:21:06 -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 LAA11672; Mon, 16 Jul 2001 11:21:06 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6GIL5G16879; Mon, 16 Jul 2001 11:21:05 -0700 X-mProtect: Mon, 16 Jul 2001 11:21:05 -0700 Nokia Silicon Valley Messaging Protection Received: from tpagtzis.iprg.nokia.com (205.226.2.115, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdwjMNBJ; Mon, 16 Jul 2001 11:21:03 PDT Message-ID: <3B53308F.5F8C1EB@iprg.nokia.com> Date: Mon, 16 Jul 2001 11:21:03 -0700 From: Theo Pagtzis Organization: UCL/NOKIA X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.1-STABLE i386) X-Accept-Language: el, en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com, James.Kempf@Sun.COM Subject: Re: [mobile-ip] Mobile Operators REquirements (MORE) BOF References: <200107161656.JAA23654@heliopolis.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 Hi James, what would be the talk about? That is, what would be expected by a speaker in such a BoF? Thanks Theodore James Kempf wrote: > Folks, > > Apologies for the wide posting. > > Recently, there was a draft posted > (draft-reynolds-mobile-isp-requirements-00.txt) that discusses requirements > for wireless ISPs (WISPs) for IP protocols related to or impacted > by mobility. There has been some discussion on the mailing list > (more@psg.com, usual majordomo subscription procedure) about the > requirements. We are now in the process of planning for a BOF at IETF 51 > in London. If anyone is interested in speaking at the BOF, please send > me email. > > jak From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 16 14:26:55 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA11747 for ; Mon, 16 Jul 2001 14:26:54 -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 LAA17916; Mon, 16 Jul 2001 11:27:00 -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 LAA21819; Mon, 16 Jul 2001 11:26:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6GIP7s21317 for mobile-ip-dist; Mon, 16 Jul 2001 11:25:07 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6GIP0N21310 for ; Mon, 16 Jul 2001 11:25: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 LAA06505 for ; Mon, 16 Jul 2001 11:25:11 -0700 (PDT) Received: from zcars0m9.ca.nortel.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA01659 for ; Mon, 16 Jul 2001 12:26:23 -0600 (MDT) Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f6GIOD918148 for ; Mon, 16 Jul 2001 14:24:14 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.ca.nortel.com; Mon, 16 Jul 2001 14:24:07 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <3HJ26H6F>; Mon, 16 Jul 2001 14:24:09 -0400 Message-ID: From: "Muhammad Jaseemuddin" To: mobile-ip@sunroof.eng.sun.com, seamoby@diameter.org Subject: [mobile-ip] CFP: Next Generation Internet at ICC 2002 Date: Mon, 16 Jul 2001 14:24:03 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10E24.7DC29440" X-Orig: 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_01C10E24.7DC29440 Content-Type: text/plain CALL FOR PAPERS Next Generation Internet Symposium IN CONJUNCTION WITH ICC 2002 April 28-May 2, 2002 New York, NY USA As part of ICC 2002, a symposium on the Next Generation Internet will be held. Participation in this symposium is open to all registrants of ICC 2002 (i.e. a separate registration is not required). Papers submitted for consideration to the symposium should focus on topics related to the Next Generation Internet (i.e. addressing issues and areas that will not be deployed in the public Internet for at least 3-5 years). Examples of topics of interest include: * NGI Performance * NGI Architecture * QoS - Fact or Fiction * Streaming Media * Home Networking-based Internet * Voice over IP Services * Internet Service Management * Internet Appliances * Next Generation Optical * NGI Protocols Internet * NGI Operations & Management * NGI Applications and * Monitoring and measurements Services for next-generation networks * NGI modeling and * Middleboxes (in-the-net services) simulation tools * Network-friendly applications * Interplanetary issues Instructions: The paper submission schedule and process is the same as for the general ICC 2002 conference (see http://www.icc2002.com/InfoForAuthors.html). Be sure to indicate the Next Generation Internet (NGI) symposium as the target for your paper on the cover page and also list the relevant hot topic(s). See the ICC 2002 Call for Papers for detailed submission Instructions (i.e., schedule, paper-length, etc.). Business Application Sessions (i.e. panel discussions) proposals are also welcome. For these, please submit session proposals to Stan Moyer and include a brief description of the session, along with bios of the session organizer/moderator and the proposed speakers. Further information can be obtained from: Stan Moyer Michael Devetsikiotis General Co-Chair General Co-Chair Telcordia Technologies North Carolina State University stanm@research.telcordia.com mdevets@eos.ncsu.edu Sponsored by the following IEEE Communications Society Technical Committees: * Communications Systems * Computer Communications Integration & Modeling * Communications Software * Personal Communications Technical Program Committee: Symeon Papavassiliou, New Jersey Institute of Technology Nelson Fonseca, State University of Campinas, Brazil Pascal Lorenz, University of Haute-Alsace, France Mohammad Ilyas, Florida Atlantic University Algirdas Pakstas, University of North London Ray Sundararaman, Lucent Amitabh Mishra, Virginia Polytech Joe Touch, USC Information Sciences Institute Tim Moors, Polytechnic University Bassam Hashem, Nortel Networks Alagan Anpalagan, University of Toronto S.-H. Gary Chan, Hong Kong University of Science and Technology Sung Jun Lee, HP Labs Elizabeth Royer, UC Santa Barbara Muhammad Jaseemuddin, Nortel Networks Ted Faber, USC Information Sciences Institute Eric Nahum, IBM Watson Research Vishal Misra, University of Massachusetts Behcet Sarikaya, Alcatel USA David Harle, University of Strathclyde, Scotland Jogesh Muppala, Hong Kong University of Science & Technology l For more information, see: http://www.comsoc.org/socstr/techcom/commsoft/confs/ngi_cfp.htm ------_=_NextPart_001_01C10E24.7DC29440 Content-Type: text/html Content-Transfer-Encoding: quoted-printable CFP: Next Generation Internet at ICC 2002

           &= nbsp;        CALL FOR PAPERS
           Next = Generation Internet Symposium

IN CONJUNCTION WITH ICC = 2002
April 28-May 2, 2002 New York, = NY USA

As part of ICC 2002, a symposium = on the Next Generation Internet
will be held. Participation in = this symposium is open to all
registrants of ICC 2002 (i.e. a = separate registration is not
required).

Papers submitted for = consideration to the symposium should focus on
topics related to the Next = Generation Internet (i.e. addressing
issues and areas that will not = be deployed in the public Internet
for at least 3-5 years). = Examples of topics of interest include:
  * NGI = Performance          &= nbsp;         * NGI = Architecture
  * QoS - Fact or = Fiction           = ;   * Streaming Media
  * Home Networking-based = Internet     * Voice over IP
    = Services          &nbs= p;           &nbs= p;    * Internet Service
           &= nbsp;           &= nbsp;           &= nbsp;     Management
  * Internet = Appliances          &n= bsp;     * Next Generation Optical
  * NGI = Protocols          &nb= sp;           &nb= sp; Internet
  * NGI Operations & = Management        * NGI Applications = and
  * Monitoring and = measurements          = Services
    for = next-generation networks       * NGI = modeling and
  * Middleboxes = (in-the-net services)    simulation tools
  * Network-friendly = applications      * Interplanetary = issues

Instructions: The paper = submission schedule and process is the same
as for the general ICC 2002 = conference (see
http://www.icc2002.com/InfoForAuthors.html<= /U>). Be sure to indicate = the
Next Generation Internet (NGI) = symposium as the target for your
paper on the cover page and = also list the relevant hot topic(s).
See the ICC 2002 Call for = Papers for detailed submission
Instructions (i.e., schedule, = paper-length, etc.).

Business Application Sessions = (i.e. panel discussions) proposals are
also welcome. For these, please = submit session proposals to Stan
Moyer and include a brief = description of the session, along with
bios of the session = organizer/moderator and the proposed speakers.
           &= nbsp;           &= nbsp;           &= nbsp;           &= nbsp;
Further information can be = obtained from:
  Stan = Moyer           &= nbsp;           = Michael Devetsikiotis
  General = Co-Chair          &nbs= p;      General Co-Chair
  Telcordia = Technologies          = North Carolina State University
  = stanm@research.telcordia.com     = mdevets@eos.ncsu.edu

Sponsored by the following IEEE = Communications Society Technical
Committees:
 * Communications = Systems    * Computer Communications
   Integration & = Modeling    * Communications Software
 * Personal = Communications

Technical Program = Committee:

     Symeon = Papavassiliou, New Jersey Institute of Technology
     Nelson = Fonseca, State University of Campinas, Brazil
     Pascal = Lorenz, University of Haute-Alsace, France
     = Mohammad Ilyas, Florida Atlantic University
     = Algirdas Pakstas, University of North London
     Ray = Sundararaman, Lucent
     = Amitabh Mishra, Virginia Polytech
     Joe = Touch, USC Information Sciences Institute
     Tim = Moors, Polytechnic University
     Bassam = Hashem, Nortel Networks
     Alagan = Anpalagan, University of Toronto
     S.-H. = Gary Chan, Hong Kong University of Science and Technology
     Sung = Jun Lee, HP Labs
     = Elizabeth Royer, UC Santa Barbara
     = Muhammad Jaseemuddin, Nortel Networks
     Ted = Faber, USC Information Sciences Institute
     Eric = Nahum, IBM Watson Research
     Vishal = Misra, University of Massachusetts
     Behcet = Sarikaya, Alcatel USA
     David = Harle, University of Strathclyde, Scotland
     Jogesh = Muppala, Hong Kong University of Science & Technology
           &= nbsp;           &= nbsp;            = l
For more information, = see:
http://www.comsoc.org/socstr/techcom/commsoft/confs/ng= i_cfp.htm

------_=_NextPart_001_01C10E24.7DC29440-- From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 16 14:29:19 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12167 for ; Mon, 16 Jul 2001 14:29:18 -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 LAA19218; Mon, 16 Jul 2001 11:29: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 LAA22539; Mon, 16 Jul 2001 11:29:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6GISHi21382 for mobile-ip-dist; Mon, 16 Jul 2001 11:28:17 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6GISEN21375 for ; Mon, 16 Jul 2001 11:28:14 -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 LAA09307 for ; Mon, 16 Jul 2001 11:28:25 -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 MAA19834 for ; Mon, 16 Jul 2001 12:28:22 -0600 (MDT) Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21) id ; Mon, 16 Jul 2001 14:27:18 -0400 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] I-D ACTION:draft-team-mobileip-mipv6-sec-reqts-00 .txt Date: Mon, 16 Jul 2001 14:27:17 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) 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: The short answer is yes. The long answer is that more review was desired before this was published. Stay tuned. > -----Original Message----- > From: Jean-Michel COMBES [mailto:jeanmichel.combes@francetelecom.com] > Sent: Monday, July 16, 2001 1:31 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] I-D > ACTION:draft-team-mobileip-mipv6-sec-reqts-00.txt > > > Hi folks, > > At first : > very interesting draft and very good job. Bravo !!! > > My question : is it the promised draft on requirements for > protocols candidate to > secure binding mecanisms ? > > 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 > From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 16 14:43:22 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14553 for ; Mon, 16 Jul 2001 14:43: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 LAA26280; Mon, 16 Jul 2001 11:43:33 -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 LAA10230; Mon, 16 Jul 2001 11:43:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6GIfnA21471 for mobile-ip-dist; Mon, 16 Jul 2001 11:41:49 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6GIfkN21464 for ; Mon, 16 Jul 2001 11:41:46 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id LAA29315; Mon, 16 Jul 2001 11:41:57 -0700 (PDT) Message-Id: <200107161841.LAA29315@heliopolis.eng.sun.com> Date: Mon, 16 Jul 2001 11:41:58 -0700 (PDT) From: James Kempf Subject: Re: [mobile-ip] Mobile Operators REquirements (MORE) BOF To: mobile-ip@sunroof.eng.sun.com, James.Kempf@sun.com, tpagtzis@iprg.nokia.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: njlGexvteqnXoACOw0cqfg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 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: Hi Theo, The idea is to present requirements on IP protocols for mobility and the wireless Internet, from the wireless ISP perspective. What wireless ISPs would like to see, basically. Please have a look at draft-reynolds-mobile-isp-requirements-00.txt for what has been proposed. If you have any additional requirements or disagree with any in the draft, that would be something to bring to the BOF. jak >X-mProtect: Mon, 16 Jul 2001 11:21:05 -0700 Nokia Silicon Valley Messaging Protection >Date: Mon, 16 Jul 2001 11:21:03 -0700 >From: Theo Pagtzis >To: mobile-ip@sunroof.eng.sun.com, James.Kempf@sun.com >Subject: Re: [mobile-ip] Mobile Operators REquirements (MORE) BOF > >Hi James, > > > what would be the talk about? That is, what would be expected by a speaker >in such a BoF? > > >Thanks > > >Theodore > >James Kempf wrote: > >> Folks, >> >> Apologies for the wide posting. >> >> Recently, there was a draft posted >> (draft-reynolds-mobile-isp-requirements-00.txt) that discusses requirements >> for wireless ISPs (WISPs) for IP protocols related to or impacted >> by mobility. There has been some discussion on the mailing list >> (more@psg.com, usual majordomo subscription procedure) about the >> requirements. We are now in the process of planning for a BOF at IETF 51 >> in London. If anyone is interested in speaking at the BOF, please send >> me email. >> >> jak > From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 16 15:49:46 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA27081 for ; Mon, 16 Jul 2001 15:49:44 -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 NAA20473; Mon, 16 Jul 2001 13:49:20 -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 MAA25795; Mon, 16 Jul 2001 12:48:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6GJklc21569 for mobile-ip-dist; Mon, 16 Jul 2001 12:46:47 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6GJkiN21562 for ; Mon, 16 Jul 2001 12:46:44 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA27188 for ; Mon, 16 Jul 2001 12:46:56 -0700 (PDT) Received: from netmail2.alcatel.com (netmail2.alcatel.com [128.251.168.51]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA29921; Mon, 16 Jul 2001 12:46:55 -0700 (PDT) Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6]) by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id OAA19600; Mon, 16 Jul 2001 14:46:55 -0500 (CDT) Received: from usa.alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f6GJksx08330; Mon, 16 Jul 2001 14:46:54 -0500 (CDT) Message-ID: <3B5335D7.A3AAA7FD@usa.alcatel.com> Date: Mon, 16 Jul 2001 14:43:35 -0400 From: Behcet Sarikaya X-Mailer: Mozilla 4.76 [en]C-CCK-MCD BDPjm-Sony3 (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf , "mobile-ip@sunroof.eng.sun.com" Subject: Re: [mobile-ip] RE: [seamoby] Resend:New Draft:Issues in Candidate References: <200107161550.IAA20239@heliopolis.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 Curiously the mail I had sent on Friday was regenerated by Sun's mobileip mailing list server on Sunday while on that day I had not logged in at all! A WG that did not want to do almost anything all of a sudden gets interested in doing everything. Well, I do not know, this dynamic rechartering and the relationship with Tanis' email, etc. Let us Phil R. and Basavaraj to comment. James Kempf wrote: > Hi Behcet, > > Please check the seamoby charter page. It clearly defines AR discovery > as in the charter. > > jak > > >Date: Sun, 15 Jul 2001 16:07:02 -0400 > >To: mobile-ip@sunroof.eng.sun.com > >From: Behcet Sarikaya > >Subject: Re: [mobile-ip] RE: [seamoby] Resend:New Draft:Issues in Candidate > > > >--------------2EF20710B1BF3CBE7F983F22 > >Content-Type: text/plain; charset=us-ascii > >Content-Transfer-Encoding: 7bit > > > >Hi Jim, > > Has this work been triggered by an email from Micheal Tanis? > >Since router discovery is of routing area, does your draft fall in seamoby 's > >charter? > > > >Just asking. > > - Behcet From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 16 18:23:20 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA22630 for ; Mon, 16 Jul 2001 18:23:19 -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 NAA03482; Mon, 16 Jul 2001 13:03: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 NAA28468; Mon, 16 Jul 2001 13:02:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6GK12n21625 for mobile-ip-dist; Mon, 16 Jul 2001 13:01:02 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6GK0wN21618 for ; Mon, 16 Jul 2001 13:00:58 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA28106 for ; Mon, 16 Jul 2001 13:01:10 -0700 (PDT) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA05976 for ; Mon, 16 Jul 2001 13:01:09 -0700 (PDT) Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21) id ; Mon, 16 Jul 2001 16:00:03 -0400 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" , James Kempf Subject: RE: [mobile-ip] RE: [seamoby] Resend:New Draft:Issues in Candidat e Date: Mon, 16 Jul 2001 16:00:03 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) 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: Excuse me for not understanding, but what are you talking about? > -----Original Message----- > From: Behcet Sarikaya [mailto:behcet.sarikaya@usa.alcatel.com] > Sent: Monday, July 16, 2001 2:44 PM > To: James Kempf; mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] RE: [seamoby] Resend:New Draft:Issues in > Candidate > > > Curiously the mail I had sent on Friday was regenerated by > Sun's mobileip mailing > list server on Sunday while on that day I had not logged in at all! > A WG that did not want to do almost anything all of a sudden > gets interested in > doing everything. > Well, I do not know, this dynamic rechartering and the > relationship with Tanis' > email, etc. > > Let us Phil R. and Basavaraj to comment. > > James Kempf wrote: > > > Hi Behcet, > > > > Please check the seamoby charter page. It clearly defines > AR discovery > > as in the charter. > > > > jak > > > > >Date: Sun, 15 Jul 2001 16:07:02 -0400 > > >To: mobile-ip@sunroof.eng.sun.com > > >From: Behcet Sarikaya > > >Subject: Re: [mobile-ip] RE: [seamoby] Resend:New > Draft:Issues in Candidate > > > > > >--------------2EF20710B1BF3CBE7F983F22 > > >Content-Type: text/plain; charset=us-ascii > > >Content-Transfer-Encoding: 7bit > > > > > >Hi Jim, > > > Has this work been triggered by an email from Micheal Tanis? > > >Since router discovery is of routing area, does your draft > fall in seamoby 's > > >charter? > > > > > >Just asking. > > > > > - > Behcet > From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 16 21:06:03 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA24854 for ; Mon, 16 Jul 2001 21:06: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 TAA12854; Mon, 16 Jul 2001 19:06:10 -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 SAA03488; Mon, 16 Jul 2001 18:05:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6H14Ex22313 for mobile-ip-dist; Mon, 16 Jul 2001 18:04:14 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.88.31]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6H14AN22306 for ; Mon, 16 Jul 2001 18:04:10 -0700 (PDT) Received: from istanbul.Eng.Sun.COM (istanbul.Eng.Sun.COM [129.146.86.247]) by jurassic.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with SMTP id f6H14Ib894290; Mon, 16 Jul 2001 18:04:18 -0700 (PDT) Message-Id: <200107170104.f6H14Ib894290@jurassic.eng.sun.com> Date: Mon, 16 Jul 2001 18:04:23 -0700 (PDT) From: Alper Yegin Subject: Re: [mobile-ip] draft-ietf-mobileip-ipv6-14.txt To: mobile-ip@sunroof.eng.sun.com, charliep@iprg.nokia.com MIME-Version: 1.0 Content-Type: MULTIPART/mixed; BOUNDARY=Caravan_of_Camels_730_000 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4_37 SunOS 5.8.1 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: --Caravan_of_Camels_730_000 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: G3uHCN4s1dqOpvzUeHXptA== Hi Charlie, As you remember, I had given a presentation on the Mobile IP spec discussion we had at Connectathon 2001 at IETF50. And after the IETF meeting, I had sent the attached e-mail to this alias. Both presentation and the e-mail list the Mobile IPv6 spec issues we identifed during the Connectathon discussions. Looking at the version 14 of the draft, I'm not able to see if any of this feedback made into the spec. Was there some technical reasons these are not incorporated into the draft? Thanks Charlie, alper > X-Unix-From: charliep@iprg.nokia.com Sun Jul 1 00:08:37 2001 > X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f > X-Delivered-For: > X-mProtect: Sun, 1 Jul 2001 00:06:10 -0700 Nokia Silicon Valley Messaging Protection > X-Accept-Language: en > MIME-Version: 1.0 > To: Mobile IP Working Group > Subject: [mobile-ip] draft-ietf-mobileip-ipv6-14.txt > Content-Transfer-Encoding: 7bit > List-Archive: > List-Owner: > List-Subscribe: > List-Unsubscribe: > > Hello folks, > > I believe that most of the current issues with Mobile IPv6 are > resolved at least to the point of some local equilibrium -- > except, of course, that we still do not know how to evaluate > security design decisions. Thus, I have supplied a newly > revised text to be distributed. It is also available at the > following URL: > http://people.nokia.net/charliep/txt/mobilev6/mobilev6.txt > > The new text is improved (thanks to Ken and T.J. and Mattias) > from the drafty version publicized a couple of weeks ago. > No major comments about the reduced reliance on AH were received, > and so I thought that the newly specified structure for the > Binding Update option was acceptable. If not, I'll happily > make whatever changes are required, including going back to > a design which relies on AH. > > There is one unsatisfied citation -- namely, the citation for > the as yet unidentifiable key distribution draft. The Mobile IPv6 > draft is completely neutral on this subject; there is only the > (currently false) assumption that some key distribution draft > does exist. > > Other changes include the new Mobile Prefix Advertisement > message for distributing prefix information to roaming mobile > nodes whenever necessary, and a scheduling algorithm for that. > Please consult the "Changes" section of the appendix for a more > complete list. > > Comments are welcome as always; please send editorial comments to > me directly, and design questions, improvements, and observations > to the list. > > Regards, > Charlie P. alper --Caravan_of_Camels_730_000 Content-Type: MESSAGE/rfc822; name=Mailbox Content-Description: Mailbox X-Unix-From: Alper.Yegin@eng.sun.com Fri Apr 6 18:21:46 2001 Return-Path: Received: from engmail3.Eng.Sun.COM (engmail3.Eng.Sun.COM [129.144.170.5]) by jurassic.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f371LiCp179357; Fri, 6 Apr 2001 18:21:44 -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 SAA13906; Fri, 6 Apr 2001 18:21:35 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f371FBK9002255 for ; Fri, 6 Apr 2001 18:15:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f371FBFo002254 for mobile-ip-dist; Fri, 6 Apr 2001 18:15: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 jurassic.eng.sun.com (jurassic [129.146.87.31] (may be forged)) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f371F2K9002247 for ; Fri, 6 Apr 2001 18:15:02 -0700 (PDT) Received: from istanbul.Eng.Sun.COM (istanbul.Eng.Sun.COM [129.146.86.247]) by jurassic.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with SMTP id f371F1Cq178579; Fri, 6 Apr 2001 18:15:02 -0700 (PDT) Message-Id: <200104070115.f371F1Cq178579@jurassic.eng.sun.com> Date: Fri, 6 Apr 2001 18:12:30 -0700 (PDT) From: Alper Yegin Subject: [mobile-ip] Mobile IPv6 spec issues from Connectathon 2001 To: dbj@cs.rice.edu, charliep@iprg.nokia.com Cc: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: sq6axuflJNFK1ou9PzqaKQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4_37 SunOS 5.8.1 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: Content-Length: 4253 Status: RO This message didn't show up on the mailing list. Resending... ------------- Begin Forwarded Message ------------- For the second year Connectathon covered testing both Mobile IPv4 and Mobile IPv6 protocols. During the event, Mobile IP participants got together to discuss specification related issues. We came up with a number of them, which was outlined in the Connectathon presentation given by Carl Williams and myself at IETF 50. Here's a recapture of Mobile IPv6 spec issues, for those who weren't at the IETF meeting (in case they have comments), and for the Mobile IPv6 draft authors to incorporate these into the next revision of the draft. Cheers, Alper Yegin [1] Movement detection (section 10.4) ... Instead, a mobile node SHOULD consider receipt of any IPv6 packets from its current default router as an indication that it is still reachable from the router. Both packets from the router's IP address and (IPv6) packets from its link-layer address (e.g., those forwarded but not originated by the router) SHOULD be considered. Draft suggests that receiving packets from a node with same link-layer address and IP address as current default router means that mobile node is still attached to the same link. BUT, different interfaces of the same router can have the same MAC address, therefore same link-local address but advertise different prefixes. In this case, mobile node would fail to detect movement if it only looks at the source MAC and IP address of packets. Therefore draft should not suggest a match on source MAC address and IP address is sufficient. [2] Sending binding acknowledgement for failed binding updates (section 5.2) Rather, the care-of address used by this node in sending the packet containing the Binding Acknowledgement MUST be copied from the care-of address received in the rejected Binding Update; ... Draft says receiving node MUST send a binding acknowledgement for failed binding updates. It also says the care-of address MUST be copied from the failed binding update. BUT in the case care-of address is an invalid address such as multicast or unspecified address, such an address should not be used as the care-of address in binding acknowledgement. Draft can be updated to say: - If we have received this binding update as a home agent, we MUST not send a binding acknowledgement - If we have received this binding update as a correspondent node, we MUST send the binding acknowledgement to home address (or not send at all?) [3] Home agent address discovery request message (section 5.6) Home Agent Address Discovery Request Message includes the Home Address field. This information is used by the receiving home agent to return the list of home agents matching the prefix of the mobile node. This request packet is sent to "Mobile IPv6 Home-Agents" anycast address for its own home subnet prefix. The receiving home agent can figure out the prefix of the mobile node just by looking at the destination address of the request packet. Therefore Home Address field in the request message is not needed in the draft. [4] ICMPs can delete binding cache (section 8.8) If the correspondent node receives persistent ICMP Destination Unreachable messages after sending packets to a mobile node based on an entry in its Binding Cache, the correspondent node SHOULD delete this Binding Cache entry. The only way binding cache entries can be deleted is through binding updates and persistent ICMP unreachables. The former is required to be authenticated, but not the latter. The draft should have a proper warning about this, as unauthenticated ICMP messages can be used for DoS attacks. [5] Deregistering a care-of address (section 8.5) The draft says that binding acknowledgement MUST be sent using a routing header in the same way as any other packet sent to a mobile node using a care-of address. BUT, what should be the care-of address used in the case this was a deregistration? Draft should specify that it MUST be the care-of address used in the triggering binding update. (similarly, draft already specifies that for failed binding updates case). ------------- End Forwarded Message ------------- --Caravan_of_Camels_730_000-- From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 17 02:14:10 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA29281 for ; Tue, 17 Jul 2001 02:14:10 -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 AAA07661; Tue, 17 Jul 2001 00:14:20 -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 XAA12683; Mon, 16 Jul 2001 23:13:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6H6Caw22604 for mobile-ip-dist; Mon, 16 Jul 2001 23:12:36 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6H6CXN22597 for ; Mon, 16 Jul 2001 23:12: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 XAA27336 for ; Mon, 16 Jul 2001 23:12:45 -0700 (PDT) Received: from ns2.iaf.fi (ns2.iaf.fi [195.94.103.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA09302 for ; Tue, 17 Jul 2001 00:14:00 -0600 (MDT) Received: from proxyfw.netseal.com (gw.netseal.com [195.94.100.110]) by ns2.iaf.fi (8.11.2/8.11.2) with ESMTP id f6H68A427267 for ; Tue, 17 Jul 2001 09:08:11 +0300 Received: from (Undisclosed Firewall protected host) by Baudia Firewall with SMTP id IAA02651 for ; Tue, 17 Jul 2001 08:31:35 +0300] Message-ID: <002c01c10e87$e09353d0$3f02a8c0@garibaldi> From: "Sami Vaarala" To: Subject: [mobile-ip] draft-vaarala-mobileip-nat-traversal-00.txt -- NAT traversal using the Mobile IP port Date: Tue, 17 Jul 2001 09:15:29 +0300 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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, We just posted a draft for Mobile IP NAT traversal that is based on reusing the Mobile IP signalling ports for data encapsulation. We wanted to get this in for the next IETF to spark some discussion on the subject. The draft can be found in: http://www.ietf.org/internet-drafts/draft-vaarala-mobileip-nat-traversal-00. txt The draft differs from the draft by Levkowetz et al in the following: - There is no separate UDP encapsulation port. Using a separate port for data encapsulation has the following problems: 1. It adds latency, since HA-to-MN traffic can only start flowing once the NAT mapping for the data encapsulation port has been established. 2. Should the first keepalive message be lost, and should the MN have no data to send, the binding will be successful, but data cannot move until the NAT keepalive interval elapses and a new keepalive (hopefully successful) is sent. Another way to recover is by the MN sending some data to the HA. 3. Even though RREQ/RREP succeeds, there is no guarantee that the data port actually works. Thus, there has to be some expensive (in time) trial-and-error method for finding a port that can be used. Another alternative is manual configuration of acceptable ports for given access points. Using the same port for both data and MIP traffic solves these problems. In particular, success of RREQ/RREP equates to success of data encapsulation, at least in practice. Loss of either RREQ/RREP is handled using the ordinary retransmission scheme of Mobile IP. - The protocol allows the client to request tunnelling regardless of presence of NAT devices. This is useful when dealing with firewalls (even in absence of NAT). The draft attempts to avoid extra tunnelling overhead by exchanging Mobile IP vs. IPv4 message markers. The current version has two methods, either the range 0x45...0x4f is reserved for tunnelling, or a single Mobile IP message type marker is used (with one octet overhead). Another alternative would be to "shift" the range 0x45...0x4f to a free range (eg 0x75...0x7f), and the communicating parties would negotiate which ranges are free at each end. Comments on the draft are most welcome, -Sami -- Sami Vaarala Senior Software Architect NetSeal Technologies From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 17 03:50:48 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA18798 for ; Tue, 17 Jul 2001 03:50:47 -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 AAA17052; Tue, 17 Jul 2001 00:51:06 -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 AAA10890; Tue, 17 Jul 2001 00:50:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6H7mrw22824 for mobile-ip-dist; Tue, 17 Jul 2001 00:48:53 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6H7mnN22817 for ; Tue, 17 Jul 2001 00:48:49 -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 AAA09085 for ; Tue, 17 Jul 2001 00:48:47 -0700 (PDT) Received: from bugs.comnets.uni-bremen.de (sam.comnets.uni-bremen.de [134.102.186.10]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA21763 for ; Tue, 17 Jul 2001 01:48:45 -0600 (MDT) Received: from comnets.uni-bremen.de ([134.102.155.20]) by bugs.comnets.uni-bremen.de (8.10.2/8.10.2/SuSE Linux 8.10.0-0.3) with ESMTP id f6H7mjo30355; Tue, 17 Jul 2001 09:48:45 +0200 X-Authentication-Warning: bugs.comnets.uni-bremen.de: Host [134.102.155.20] claimed to be comnets.uni-bremen.de Message-ID: <3B53EDDD.4050603@comnets.uni-bremen.de> Date: Tue, 17 Jul 2001 09:48:45 +0200 From: "Niko A. Fikouras" User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.6-2mdk i686; en-US; rv:0.9.1) Gecko/20010607 Netscape6/6.1b1 X-Accept-Language: en-us MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com, cg@comnets.uni-bremen.de, Lott Matthias , "'ZIRWAS WOLFGANG'" Subject: [mobile-ip] (new) draft-nomad-mobileip-filters-00.txt 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 Hi all, we wish to announce the submission of a new internet-draft with title: "Filters for Mobile IP Bindings (NOMAD)" The purpose of this document is to enable mobile nodes to associate a list of filters with a binding during its establishement (registration, binding update). In this manner, a mobile node with multiple points of attachment may receive different flows through different points of attachment. A URL for the internet-draft is: http://www.ietf.org/internet-drafts/draft-nomad-mobileip-filters-00.txt Any comment will be appreciated. Best Regards, niko From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 17 05:37:36 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA01231 for ; Tue, 17 Jul 2001 05:37: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 DAA16608; Tue, 17 Jul 2001 03:37:39 -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 CAA17514; Tue, 17 Jul 2001 02:37:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6H9Zos22994 for mobile-ip-dist; Tue, 17 Jul 2001 02:35:50 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6H9ZlN22987 for ; Tue, 17 Jul 2001 02:35: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 CAA00482 for ; Tue, 17 Jul 2001 02:36:00 -0700 (PDT) Received: from RRMAIL01.RADIOROUTER_NT ([63.103.94.23]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA15841 for ; Tue, 17 Jul 2001 03:35:59 -0600 (MDT) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id <317T36GB>; Tue, 17 Jul 2001 05:35:59 -0400 Message-ID: <8C92E23A3E87FB479988285F9E22BE4605467D@ftmail> From: George Tsirtsis To: mobile-ip@sunroof.eng.sun.com, seamoby@cdma-2000.org Subject: RE: [seamoby] Re: [mobile-ip] Comments on: I-D ACTION:draft-many folks-l2-mobilereq-00.txt Date: Tue, 17 Jul 2001 05:34:26 -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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: -----Original Message----- From: James Kempf [mailto:James.Kempf@Sun.COM] Sent: Monday, July 16, 2001 7:20 PM To: mobile-ip@sunroof.eng.sun.com; seamoby@cdma-2000.org Subject: [seamoby] Re: [mobile-ip] Comments on: I-D ACTION:draft-manyfolks-l2-mobilereq-00.txt George, Thanx for you comments. I'll fold them in on the next revision, which will be after IETF 51. Specific responses below. ... >2. Why is Section 4 in this draft? Why do we examine triggers for L2 >Handoffs...I think this is out of scope? Section 5 describes use of triggers >with L3 Handoffs which is in scope and all we need... > If the AR is not informed that the MN has changed APs, the AR's mapping of L2 address to IP address may be out of date when the MN moves. The AR must either perform proxy ARP (IPv4) or Neighbor Discovery (IPv6) in order to refresh the mapping. With an L2 trigger and an associated update protocol, the AP could specfically tell the AR what the new mapping is. If all the APs have a single radio technology, then one can reasonably argue that this is radio technology specific (even if the protocol to update the AR's mapping is based on IP); however, in the future, it is possible that subnets with mixed technology APs may become more common. So, while the draft does not advocate a particular approach to solving this problem, it does lay out the requirements for allowing it to be solved, should some working group decide they wanted to take on the task. GT> OK, I see...It would be nice to state that somewhere though....i.e.: the AP to AR protocol for this update is likely to be proprietary to the AP's technology...and yes I know that some APs (as well as wavelan hubs) also speak IP in which case this could be an IP protocol...oh well...the world is not simple anymore :-) >3. In the table in Section 5 I have a different view on the concept of >"Recipient" of the various Triggers described. I think the "Recipient" is >the *IP Layer* in either the AR or the MN. Whether the trigger comes via an >AP or not is not relevant IMO. The consideration of the AP, however, is >sometime useful in the spec (e.g.: some times you need the AP's L2 addr if >one is used). Still the AP itself is never the recipient of the >trigger...i.e.: the AP does not act on trigger reception, apart from >forwarding it to the AR as normal. > I'm not entirely sure I understand your comment, but let me see. Basically, the idea in the draft is that the AP is not a recipient of the trigger, however, it may be the source. The recipient that is identified in the draft is an IP entity (i.e. an IP host or an IP router, the only entities that there are in IP networks). APs are neither, since they are transparent by definition. So I think we are agreeing on that point. GT> We do indeed, I just said that because in Table 2 you have AP/AR as Recipient of Link UP/DOWN triggers The AP *may* have an IP address if it is engaged in, say, IAPP like traffic to propogate L2 trigger information. At that point, it is acting like an IP host. I agree that, on a particular IP entity identified as a target, the IP stack is the recepient of the trigger. Does this correspond to what you are saying? GT> Hmmm...you see that is what I do not like about this...I would much better prefer not to refer to APs in this way...The L2 triggers always go to an IP router or a host as you said...if one wants to implement an IP host in an AP then as far as this mechanism goes this is an IP host (not an AP!). The reason I am fussy about this is that any IETF mechanism/protocol should be designed for the clear architectural case so it is correct...then it can be implemented in whatever way fits the specific scenario. The other way never works quit so well...So, lets just define the API and let people implement it the way they need...you can even give the AP case as an example... >4. I suggest the table in section 5 to be expanded and each Trigger to be >described in a bit more detailed...the sort, table descriptions, are a bit >nebulous... OK, I'll look into it. If you have any proposed wording, please send it along. GT> OK, will think about it and we can discuss in London. > >6. Section 6.2 defines CT related triggers, why are these different from the >ones in Section 5?? Surely the Source/Dest Triggers defined in section 5 can >(optionally?) include the information required for the triggers defined in >6.2. Also why do you have CT triggers going to the MN? and why both reactive >and proactive triggers go to both old and new ARs? > We had some discussion on this among the authors. It is true that there is overlap, we wanted to lay out the requirements separately. The reason is that there is a strong feeling among the CT design team participants that CT should not be tied to a mobility protocol. While I think it is probably worthwhile to lay out the requirements separately, perhaps something should be said about overlap, and maybe put a section in that describes how to satisfy them with a single set of triggers. Does this sound like a good idea? GT> I fully agree that CT should not be tight to one single mobility protocol but I also think the API described in this spec should not be either...these are *generic* triggers "I am coming from there"...or "I am going there"...some of them not even mobility specific i.e.: "link up", "link down"....These have nothing to do with any particular mobility protocol and some of them can be used by non mobility protocols...So, I think we should start the opposite way...assume they are the same triggers until you find a strong reason why CT needs its own specific triggers. Otherwise protocol X will also come later on and demand its own specific triggers => no good.... ... > >Thanks and again good work! Thank you for the comments! If you have any text you'd like to see in the document (particularly on the table in Section 5) please send it along. GT> OK, we can discuss in London... Thanks George P.S.: BTW, I am a bit confused with the seamoby list...you use the seamoby@cdma-2000.org address...but when I go to though this is seamoby@diameter.org...is this an alias of the same list? From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 17 06:04:53 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA04217 for ; Tue, 17 Jul 2001 06:04:52 -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 EAA28503; Tue, 17 Jul 2001 04:05: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 DAA19427; Tue, 17 Jul 2001 03:04:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6HA3dT23059 for mobile-ip-dist; Tue, 17 Jul 2001 03:03:39 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6HA3ZN23052 for ; Tue, 17 Jul 2001 03:03:36 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA21679 for ; Tue, 17 Jul 2001 03:03:46 -0700 (PDT) Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA25884 for ; Tue, 17 Jul 2001 03:03:45 -0700 (PDT) Received: from Gioconda (c40.local.ipunplugged.com [192.168.4.239]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with ESMTP id MAA12924 for ; Tue, 17 Jul 2001 12:05:36 +0200 From: "Henrik Levkowetz" To: Subject: RE: [mobile-ip] draft-vaarala-mobileip-nat-traversal-00.txt -- NAT traversal using the Mobile IP port Date: Tue, 17 Jul 2001 12:03:43 +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: <002c01c10e87$e09353d0$3f02a8c0@garibaldi> Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 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 Sami, I've just read your draft, with great interest, and find that apart from the choice of tunnelling through the well-known port 434 instead of an arbitrary port, our drafts match very well. My intention was actually to submit a draft for a general UDP tunnelling mechanism for Mobile IP, providing for tunnelling through port 434, but time caught up with me and I did not make it to the -00 draft cut-off date. The advantages of your method, which you list below, are quite correctly represented, as far as I can see. However, the drawback to your method, which made us choose not to multiplex through 434 in a vendor-specific solution, is that you effectively subsume the use of a (dynamically assignable) mobile-ip message number which has not been assigned for that use by IANA, in order to effect the data tunnelling through port 434. We did not feel that we could do this -- and for that reason, in part, we intended to write and propose a non-vendor specific solution where a new mobile-ip message is defined to carry the data traffic tunnelled through port 434. I wonder if there are more people interested in defining a non- vendor specific solution for NAT traversal for Mobile IP v4? As for some other particulars described in your draft, I liked the provision for a dynamic keepalive-interval. We had discussed the use of a flag similar to your 'U' flag, too, although we left it out of the vendor-specific solution. Best regards, Henrik Levkowetz Sami Vaarala wrote: > > > Hi, > > We just posted a draft for Mobile IP NAT traversal that is based > on reusing the Mobile IP signalling ports for data encapsulation. > We wanted to get this in for the next IETF to spark some discussion > on the subject. The draft can be found in: > > http://www.ietf.org/internet-drafts/draft-vaarala-mobileip-nat-traversal-00. > txt > > The draft differs from the draft by Levkowetz et al in the following: > > - There is no separate UDP encapsulation port. Using a separate > port for data encapsulation has the following problems: > > 1. It adds latency, since HA-to-MN traffic can only > start flowing once the NAT mapping for the data encapsulation > port has been established. > > 2. Should the first keepalive message be lost, and should the > MN have no data to send, the binding will be successful, > but data cannot move until the NAT keepalive interval elapses > and a new keepalive (hopefully successful) is sent. Another > way to recover is by the MN sending some data to the HA. > > 3. Even though RREQ/RREP succeeds, there is no guarantee that the > data port actually works. Thus, there has to be some expensive > (in time) trial-and-error method for finding a port that can be > used. Another alternative is manual configuration of acceptable > ports for given access points. > > Using the same port for both data and MIP traffic solves these > problems. In particular, success of RREQ/RREP equates to success of > data encapsulation, at least in practice. Loss of either RREQ/RREP > is handled using the ordinary retransmission scheme of Mobile IP. > > - The protocol allows the client to request tunnelling regardless of > presence of NAT devices. This is useful when dealing with firewalls > (even in absence of NAT). > > The draft attempts to avoid extra tunnelling overhead by exchanging > Mobile IP vs. IPv4 message markers. The current version has two > methods, either the range 0x45...0x4f is reserved for tunnelling, or > a single Mobile IP message type marker is used (with one octet > overhead). Another alternative would be to "shift" the range 0x45...0x4f > to a free range (eg 0x75...0x7f), and the communicating parties would > negotiate which ranges are free at each end. > > Comments on the draft are most welcome, > > -Sami > > -- > Sami Vaarala > Senior Software Architect > NetSeal Technologies > From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 17 06:12:58 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA05103 for ; Tue, 17 Jul 2001 06:12:57 -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 EAA02513; Tue, 17 Jul 2001 04:13:11 -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 DAA20146; Tue, 17 Jul 2001 03:13:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6HABxg23110 for mobile-ip-dist; Tue, 17 Jul 2001 03:11:59 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6HABtN23103 for ; Tue, 17 Jul 2001 03:11:55 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA17370 for ; Tue, 17 Jul 2001 03:12:06 -0700 (PDT) Received: from milou.inria.fr (milou.inria.fr [138.96.88.50]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA28090 for ; Tue, 17 Jul 2001 03:12:05 -0700 (PDT) Received: from localhost by milou.inria.fr (8.11.1/8.10.0) with ESMTP id f6HAC4Z17691 for ; Tue, 17 Jul 2001 12:12:04 +0200 Date: Tue, 17 Jul 2001 12:12:04 +0200 (MEST) From: Hossam Afifi To: Subject: [mobile-ip] draft IGPRS 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: Hello draft-ietf-hossam-igprs-00.txt was submitted as an individual contribution (C.Perkins, H. Flinck, H. Afifi). It describes how Mobile IPv6 can be implemented ontop of the UMTS (CDMA) micro-mobility. It requires that Mobile IPv6 be tightly coupled with the lower radio resource control layers and that Mobile IPv6 security be also tightly coupled to the general 3GPP security mechanisms (authentication). Any comments will be welcomed From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 17 06:16:37 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA05501 for ; Tue, 17 Jul 2001 06:16:36 -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 DAA28279; Tue, 17 Jul 2001 03:16:34 -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 DAA03328; Tue, 17 Jul 2001 03:16:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6HAEfU23177 for mobile-ip-dist; Tue, 17 Jul 2001 03:14:41 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6HAEcN23170 for ; Tue, 17 Jul 2001 03:14:38 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA17522 for ; Tue, 17 Jul 2001 03:14:49 -0700 (PDT) Received: from milou.inria.fr (milou.inria.fr [138.96.88.50]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA28772 for ; Tue, 17 Jul 2001 03:14:48 -0700 (PDT) Received: from localhost by milou.inria.fr (8.11.1/8.10.0) with ESMTP id f6HAElM17807; Tue, 17 Jul 2001 12:14:47 +0200 Date: Tue, 17 Jul 2001 12:14:47 +0200 (MEST) From: Hossam Afifi To: Subject: [mobile-ip] IGPRS 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 forgot to give the url: http://www-sop.inria.fr/planete/afifi/igprs.txt From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 17 06:22:12 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA06078 for ; Tue, 17 Jul 2001 06:22:12 -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 DAA29588; Tue, 17 Jul 2001 03:22: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 DAA03841; Tue, 17 Jul 2001 03:22:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6HALU723254 for mobile-ip-dist; Tue, 17 Jul 2001 03:21:30 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6HALRN23247 for ; Tue, 17 Jul 2001 03:21:27 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA03791 for ; Tue, 17 Jul 2001 03:21:38 -0700 (PDT) From: john.loughney@nokia.com Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA07204 for ; Tue, 17 Jul 2001 03:21:36 -0700 (PDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f6HAOXG17161 for ; Tue, 17 Jul 2001 13:24:33 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 17 Jul 2001 13:21:35 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MSVAM4M>; Tue, 17 Jul 2001 13:21:35 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF094073@esebe004.NOE.Nokia.com> To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] IGPRS Date: Tue, 17 Jul 2001 13:21:34 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) 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: Hi, > http://www-sop.inria.fr/planete/afifi/igprs.txt Would it be possible to fix the figures? They do not align. thanks, John From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 17 06:29:40 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA06919 for ; Tue, 17 Jul 2001 06:29: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 EAA09857; Tue, 17 Jul 2001 04:29:49 -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 DAA04315; Tue, 17 Jul 2001 03:29:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6HASSA23304 for mobile-ip-dist; Tue, 17 Jul 2001 03:28:28 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6HASPN23297 for ; Tue, 17 Jul 2001 03:28:25 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA18597 for ; Tue, 17 Jul 2001 03:28:36 -0700 (PDT) From: john.loughney@nokia.com Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA09162 for ; Tue, 17 Jul 2001 03:28:35 -0700 (PDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f6HAT5I07801 for ; Tue, 17 Jul 2001 13:29:05 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Tue, 17 Jul 2001 13:28:30 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MSVAM66>; Tue, 17 Jul 2001 13:28:30 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF094076@esebe004.NOE.Nokia.com> To: mobile-ip@sunroof.eng.sun.com Cc: carlw@jurassic.Eng.Sun.COM Subject: RE: [mobile-ip] comments on draft-ietf-mobileip-lmm-requirements- 00.txt Date: Tue, 17 Jul 2001 13:28:25 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) 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: Hi Hesham, > > I suggested to Carl that he insert some goals into section 1 - > > I meant more that we minimize changes to the MN, HA & CN to a > > minimum (implementations of LMM enabled nodes shouldn't be > > radically changed). > > > => Maybe the wording needs to be clarified because it > doesn't reflect that. I completely agree with minimising > the changes and eliminating them for the CN and the > HA if possible. Sure, what would you suggest? > > If LMM agents are not communicating with each other, then we > > have de-facto replay protection! > > > => I'm just saying that this is an unnecessary assumption. But, if it doesn't place a useless burden on an implementation, does it matter? > > Since your last sentence uses '... should coexist', doesn't > > this argue the case for a SHOULD - or do you mean ' ... MUST > > co-exist.' > > > => The current requirement says it's a MAY. I think it should > be a MUST. Sorry for the confusing statement. I agree. Fast Handovers & LMM MUST be able to interoperate. John From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 17 06:52:37 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA10269 for ; Tue, 17 Jul 2001 06:52:36 -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 DAA06483; Tue, 17 Jul 2001 03:52:36 -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 DAA06012; Tue, 17 Jul 2001 03:52:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6HAorg23407 for mobile-ip-dist; Tue, 17 Jul 2001 03:50:53 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6HAonN23397 for ; Tue, 17 Jul 2001 03:50:49 -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 DAA20167 for ; Tue, 17 Jul 2001 03:51:00 -0700 (PDT) Received: from ns2.iaf.fi (ns2.iaf.fi [195.94.103.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA18030 for ; Tue, 17 Jul 2001 04:50:57 -0600 (MDT) Received: from proxyfw.netseal.com (gw.netseal.com [195.94.100.110]) by ns2.iaf.fi (8.11.2/8.11.2) with ESMTP id f6HAkW411781 for ; Tue, 17 Jul 2001 13:46:32 +0300 Received: from (Undisclosed Firewall protected host) by Baudia Firewall with SMTP id NAA03152 for ; Tue, 17 Jul 2001 13:09:56 +0300] Message-ID: <008401c10eae$c3990b90$3f02a8c0@garibaldi> From: "Sami Vaarala" To: References: Subject: Re: [mobile-ip] draft-vaarala-mobileip-nat-traversal-00.txt -- NAT traversal using the Mobile IP port Date: Tue, 17 Jul 2001 13:53:50 +0300 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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Henrik, From: "Henrik Levkowetz" > Sami, > >[...] > The advantages of your method, which you list below, are quite > correctly represented, as far as I can see. However, the drawback to > your method, which made us choose not to multiplex through 434 in a > vendor-specific solution, is that you effectively subsume the use of a > (dynamically assignable) mobile-ip message number which has not been > assigned for that use by IANA, in order to effect the data tunnelling > through port 434. We did not feel that we could do this -- and for > that reason, in part, we intended to write and propose a non-vendor > specific solution where a new mobile-ip message is defined to carry > the data traffic tunnelled through port 434. I agree that it is not very "polite" to carry data traffic using a dynamically assigned message type. We decided that this approach would be OK mainly because: * it is dynamical, and each host determines which message type(s) it can use for such purposes (thus eliminating conflicts between existing or new IANA types) * no-one except MN and HA process such messages (eg no FAs are in the route) * the data encapsulation is never used, unless both parties agree that they support the mechanism (and the negotiation process is authenticated using Mobile IP authentication) Furthermore, we strongly feel that a range of Mobile IP message types should be used (instead of a separate marker octet) to multiplex traffic, in order to avoid overhead (and also loss of packet alignment) caused by extra marker octet(s). Another approach with regards to standardization would be to define a separate, standard UDP tunnelling port that would be well known and thus hopefully likely to be passed thru along with 434 (at the cost of added latency). With regards to the -00 draft, an idea to add more flexibility to the marker negotiation would be to remove the "non-optimized tunnelling" in our draft, and instead negotiate which ranges of markers are available at each end. This would avoid the fixed 0x45...0x4f range in optimized tunnelling, and at the same time remove the need for two separate methods of tunnelling. An even more flexible mechanism would be to specify the 11 marker octets mapping to 0x45...0x4f, and not requiring that the markers be continuously allocated from the Mobile IP message type space. As an aside, how do people feel about TCP-based traversal? With regards to keepalives, such tunnelling could be more efficient, but is it worth the extra trouble? For one, the standard RREQ/RREP mechanism cannot be used to negotiate the traversal, as with UDP-based traversal, eg in case UDP is not passed to the home agent at all, but TCP is. > I wonder if there are more people interested in defining a non- > vendor specific solution for NAT traversal for Mobile IP v4? This is an interesting question; we feel that Mobile IP NAT traversal is increasingly important, and should not be too difficult to standardize (eg in comparison to IPsec NAT traversal). Hopefully there will be enough discussion before and during IETF 51. Best regards, -Sami From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 17 06:53:17 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA10471 for ; Tue, 17 Jul 2001 06:53:17 -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 DAA06615; Tue, 17 Jul 2001 03:52:51 -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 DAA06034; Tue, 17 Jul 2001 03:52:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6HApJY23416 for mobile-ip-dist; Tue, 17 Jul 2001 03:51:19 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6HApDN23409 for ; Tue, 17 Jul 2001 03:51:14 -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 DAA20193 for ; Tue, 17 Jul 2001 03:51:25 -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 EAA24091 for ; Tue, 17 Jul 2001 04:52:40 -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 GAA09676; Tue, 17 Jul 2001 06:50:29 -0400 (EDT) Message-Id: <200107171050.GAA09676@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-nomad-mobileip-filters-00.txt Date: Tue, 17 Jul 2001 06:50:29 -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. Title : Filters for Mobile IP Bindings (NOMAD) Author(s) : N. Fikouras et al. Filename : draft-nomad-mobileip-filters-00.txt Pages : 15 Date : 16-Jul-01 In Mobile IP, a mobile node that maintains simultaneous bindings will receive at each registered care-of address a duplicate copy of every datagram from every active flow. However, a mobile node with multiple points of attachment may wish to receive different flows at each one. The purpose of this document is to enable mobile nodes to associate a list of filters with a binding during its establishment (registration, binding update). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-nomad-mobileip-filters-00.txt 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-nomad-mobileip-filters-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-nomad-mobileip-filters-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: <20010716153259.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-nomad-mobileip-filters-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-nomad-mobileip-filters-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010716153259.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 17 06:53:57 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA10699 for ; Tue, 17 Jul 2001 06:53:56 -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 EAA19764; Tue, 17 Jul 2001 04:54: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 DAA06223; Tue, 17 Jul 2001 03:53:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6HAr0x23463 for mobile-ip-dist; Tue, 17 Jul 2001 03:53:00 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6HAquN23456 for ; Tue, 17 Jul 2001 03:52:56 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA22545 for ; Tue, 17 Jul 2001 03:53:08 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA08126 for ; Tue, 17 Jul 2001 03:53:07 -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 GAA10132; Tue, 17 Jul 2001 06:52:12 -0400 (EDT) Message-Id: <200107171052.GAA10132@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-soliman-mobileip-flow-move-00.txt Date: Tue, 17 Jul 2001 06:52:12 -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. Title : Per-flow movement in MIPv6 Author(s) : H. Soliman, K. Malki, C. Castelluccia Filename : draft-soliman-mobileip-flow-move-00.txt Pages : 6 Date : 16-Jul-01 The aim of this draft is to introduce a new extension to MIPv6 to allow hosts to direct inbound flows individually to certain preferred interfaces. This extension to MIPv6 allows hosts to take full advantage of the diverse access technologies that they may be connected to and direct their traffic according to internal policies specified by the users or applications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-soliman-mobileip-flow-move-00.txt 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-soliman-mobileip-flow-move-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-soliman-mobileip-flow-move-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: <20010716153532.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-soliman-mobileip-flow-move-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-soliman-mobileip-flow-move-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010716153532.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 17 08:45:52 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA25439 for ; Tue, 17 Jul 2001 08:45:51 -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 DAA27259; Tue, 17 Jul 2001 03:12:53 -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 DAA20095; Tue, 17 Jul 2001 03:12:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6HABad23101 for mobile-ip-dist; Tue, 17 Jul 2001 03:11:36 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6HABWN23094 for ; Tue, 17 Jul 2001 03:11:32 -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 DAA22310 for ; Tue, 17 Jul 2001 03:11:42 -0700 (PDT) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA01671 for ; Tue, 17 Jul 2001 04:11:39 -0600 (MDT) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate2.mot.com (motgate2 2.1) with ESMTP id DAA22361 for ; Tue, 17 Jul 2001 03:11:36 -0700 (MST)] Received: [from m-il06-r1.mot.com (m-il06-r1.mot.com [129.188.137.193]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id DAA23548 for ; Tue, 17 Jul 2001 03:11:36 -0700 (MST)] Received: from [140.101.173.9] by m-il06-r1.mot.com with ESMTP for mobile-ip@sunroof.eng.sun.com; Tue, 17 Jul 2001 05:11:35 -0500 Received: (from root@localhost) by zorglub.crm.mot.com (8.8.8/8.8.8/crm-1.6) id MAA10481 for mobile-ip@sunroof.eng.sun.com.DELIVER; Tue, 17 Jul 2001 12:11:33 +0200 (METDST) Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by zorglub.crm.mot.com (8.8.8/8.8.8/crm-1.6) with ESMTP id MAA10450 for ; Tue, 17 Jul 2001 12:11:32 +0200 (METDST) To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Question on draft-team-mobileip-mipv6-sec-reqts-00.txt From: Alexandru Petrescu Date: 17 Jul 2001 12:11:30 +0200 Message-Id: Lines: 18 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.0.103 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, I'm no security expert and I have this humble question. The requirements presented are so directly related to cryptography. The word "authorized" is used extensively. I was wondering if it is possible to include requirements that are more "functional" in nature and that would allow solutions that do not rely necessarily on crypto. For example, the wireless broadcast would allow the MN to overhear when a BU with its Home Address were sent by an attacker. Another example is that the AR's usually trust each other and thus might easily exclude an unauthorized AR. Just wondering, Alex From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 17 09:54:10 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA08194 for ; Tue, 17 Jul 2001 09:54:09 -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 GAA02139; Tue, 17 Jul 2001 06:54: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 GAA08641; Tue, 17 Jul 2001 06:54:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6HDprH23893 for mobile-ip-dist; Tue, 17 Jul 2001 06:51:53 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6HDpnN23886 for ; Tue, 17 Jul 2001 06:51:49 -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 GAA08136 for ; Tue, 17 Jul 2001 06:52:02 -0700 (PDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA22950 for ; Tue, 17 Jul 2001 07:51:59 -0600 (MDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f6HDq0N28826 for ; Tue, 17 Jul 2001 15:52:00 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Tue Jul 17 15:51:56 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Tue, 17 Jul 2001 15:51:59 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008AFC@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Cc: carlw@jurassic.Eng.Sun.COM Subject: RE: [mobile-ip] comments on draft-ietf-mobileip-lmm-requirements- 00.txt Date: Tue, 17 Jul 2001 15:51:48 +0200 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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi John, > > > I suggested to Carl that he insert some goals into section 1 - > > > I meant more that we minimize changes to the MN, HA & CN to a > > > minimum (implementations of LMM enabled nodes shouldn't be > > > radically changed). > > > > > => Maybe the wording needs to be clarified because it > > doesn't reflect that. I completely agree with minimising > > the changes and eliminating them for the CN and the > > HA if possible. > > Sure, what would you suggest? > => One of the main goals of LMM is to minimise the impacts on IPv6 and MIPv6 in general. As such, the protocol extensions should aim at limiting the changes to the MN. Something like that, it's not a major issue really, just the previous wording seemed like it was suggesting that no changes should be made to the MN. > > > If LMM agents are not communicating with each other, then we > > > have de-facto replay protection! > > > > > => I'm just saying that this is an unnecessary assumption. > > But, if it doesn't place a useless burden on an implementation, > does it matter? > => It doesn't matter, it's just irrelevant in a requirements document to discuss what the solution will look like. Hesham From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 17 10:00:42 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09843 for ; Tue, 17 Jul 2001 10:00:41 -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 IAA29309; Tue, 17 Jul 2001 08:00: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 HAA10537; Tue, 17 Jul 2001 07:00:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6HDx7t23955 for mobile-ip-dist; Tue, 17 Jul 2001 06:59:07 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6HDx4N23948 for ; Tue, 17 Jul 2001 06:59: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 GAA10503 for ; Tue, 17 Jul 2001 06:59:15 -0700 (PDT) Received: from mailgw.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 IAA17726 for ; Tue, 17 Jul 2001 08:00:30 -0600 (MDT) Received: from Gioconda (c2.local.ipunplugged.com [192.168.4.201]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with ESMTP id QAA16692 for ; Tue, 17 Jul 2001 16:01:02 +0200 From: "Henrik Levkowetz" To: Subject: RE: [mobile-ip] draft-vaarala-mobileip-nat-traversal-00.txt -- NAT traversal using the Mobile IP port Date: Tue, 17 Jul 2001 15:59:09 +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: <008401c10eae$c3990b90$3f02a8c0@garibaldi> Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 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 Sami, On the dynamically assigned message type: Although we have chosen not to use such to tunnel trough 434, I to some extent agree with what you write on this, however: If you deploy a number of HA's & clients worldwide, using this solution, and some of the MIP message numbers which are now unassigned become assigned for standardised messages, you are in a situation where all of your HA's and clients will need to be reconfigured to not use those message numbers -- and if your company is successful in selling this solution, that could be a lot of HA's and clients! There's always a chance then, that some customer would miss or ignore the reconfiguration. I don't think you should assume that only your own clients will be used with your HA's, or only your own HA's will be used to support your clients -- and if other vendors' products with new message types were to conflict with your tunneling solution because a reconfiguration had been missed, it would be quite unfortunate. In theory, you should still never get a conflict if you take care to treat these message types as tunneling only after negotiation, and as unrecognised messages otherwise, but it's balancing a little too close to the edge for my liking... :-) (Remember Murphy.) It would also be unfortunate if the IANA felt that due to the existence in the marketplace of a solution which had subsumed the use of message types 0x45..0x4f, those could not be used for new Mobile IP messages types, and had to be barred. On TCP-based traversal: I think that there would be added complexity and overhead, without proportionately added benefit. If the protocol being carried in the tunnel also was TCP, I think you might get complex interactions between the two levels of TCP timers, resends and whatnot? We chose to go with UDP because IP-in-UDP behaviour is very close to IP-in-IP or bare IP. I'm sure you have made the same reflexions. On standardised NAT-traversal: Yes. And I'm slightly surprised at the scarcity of comments, so far. Of course, this subject isn't as sexy as MIPv6 or Fast Handover :-) Best regards, Henrik Sami Vaarala wrote: > > Henrik, > > From: "Henrik Levkowetz" > > Sami, > > > >[...] > > The advantages of your method, which you list below, are quite > > correctly represented, as far as I can see. However, the drawback to > > your method, which made us choose not to multiplex through 434 in a > > vendor-specific solution, is that you effectively subsume the use of a > > (dynamically assignable) mobile-ip message number which has not been > > assigned for that use by IANA, in order to effect the data tunnelling > > through port 434. We did not feel that we could do this -- and for > > that reason, in part, we intended to write and propose a non-vendor > > specific solution where a new mobile-ip message is defined to carry > > the data traffic tunnelled through port 434. > > I agree that it is not very "polite" to carry data traffic using a > dynamically > assigned message type. We decided that this approach would be OK mainly > because: > * it is dynamical, and each host determines which message type(s) it can > use for such purposes (thus eliminating conflicts between existing or new > IANA types) > * no-one except MN and HA process such messages (eg no FAs are in the route) > * the data encapsulation is never used, unless both parties agree that they > support the mechanism (and the negotiation process is authenticated > using Mobile IP authentication) > > Furthermore, we strongly feel that a range of Mobile IP message types should > be used (instead of a separate marker octet) to multiplex traffic, in order > to avoid overhead (and also loss of packet alignment) caused by extra marker > octet(s). Another approach with regards to standardization would be to > define a separate, standard UDP tunnelling port that would be well known > and thus hopefully likely to be passed thru along with 434 (at the cost of > added latency). > > With regards to the -00 draft, an idea to add more flexibility to the > marker negotiation would be to remove the "non-optimized tunnelling" > in our draft, and instead negotiate which ranges of markers are available > at each end. This would avoid the fixed 0x45...0x4f range in optimized > tunnelling, and at the same time remove the need for two separate methods > of tunnelling. > > An even more flexible mechanism would be to specify the 11 marker octets > mapping to 0x45...0x4f, and not requiring that the markers be continuously > allocated from the Mobile IP message type space. > > As an aside, how do people feel about TCP-based traversal? With regards > to keepalives, such tunnelling could be more efficient, but is it worth > the extra trouble? For one, the standard RREQ/RREP mechanism cannot be > used to negotiate the traversal, as with UDP-based traversal, eg in case > UDP is not passed to the home agent at all, but TCP is. > > > I wonder if there are more people interested in defining a non- > > vendor specific solution for NAT traversal for Mobile IP v4? > > This is an interesting question; we feel that Mobile IP NAT traversal > is increasingly important, and should not be too difficult to standardize > (eg in comparison to IPsec NAT traversal). Hopefully there will be enough > discussion before and during IETF 51. > > Best regards, > > -Sami > From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 17 11:30:58 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA00590 for ; Tue, 17 Jul 2001 11:30:58 -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 IAA18694; Tue, 17 Jul 2001 08:31:03 -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 IAA01549; Tue, 17 Jul 2001 08:30:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6HFSY124169 for mobile-ip-dist; Tue, 17 Jul 2001 08:28:34 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6HFSVN24162 for ; Tue, 17 Jul 2001 08:28:31 -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 IAA27982 for ; Tue, 17 Jul 2001 08:28:42 -0700 (PDT) Received: from zcars0m9.ca.nortel.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA10026 for ; Tue, 17 Jul 2001 09:28:40 -0600 (MDT) Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f6HFSN908930 for ; Tue, 17 Jul 2001 11:28:23 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.ca.nortel.com; Tue, 17 Jul 2001 11:28:29 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <3HJ26WBD>; Tue, 17 Jul 2001 11:28:30 -0400 Message-ID: From: "Hongyi Li" To: carlw@jurassic.Eng.Sun.COM Cc: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] draft-ietf-mobileip-lmm-requirements-00.txt Date: Tue, 17 Jul 2001 11:28:23 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10ED5.1DE64E20" X-Orig: 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_01C10ED5.1DE64E20 Content-Type: text/plain; charset="iso-8859-1" Hi Carl, Thanks for editing the LMM requirements document. I have some comments on this document: > 3.4.4 Optimized signaling within the administrative domain > By its very nature, LMM reintroduces triangle routing into Mobile IPv6 > in that all traffic must go through the LMM agent. There is no way > to avoid this. The LMM framework SHOULD be designed in such a way > that as to reduce the length of the unwanted triangle leg. I would suggest to change this paragraph as following: "By its very nature, LMM MAY reintroduce triangle routing into Mobile IPv6 in that all traffic must go through the LMM agent. The LMM framework SHOULD be designed in such a way that as to reduce the length of the unwanted triangle leg." The reason for the change is that a network provider can avoid re-introducing triangle routing by designing its LMM domain with a single gateway and deploying one LMM agent per domain at the gateway. This is only one example to avoid triangular routing. There might be other ways. > 3.6 Sparse routing element population requirement > > The LMM framework SHOULD be supported, at the very minimum, by a sparse > (proper subset) routing element population within a single > administration domain. Could you plaese explain what is the Sparse Routing Element and what is the reason behind this requirement. Thanks. Regards Hongyi > -----Original Message----- > From: Carl Williams [mailto:Carl.Williams@eng.sun.com] > Sent: Friday, July 13, 2001 5:00 PM > To: mobile-ip@sunroof.eng.sun.com > Cc: carlw@jurassic.eng.sun.com > Subject: [mobile-ip] draft-ietf-mobileip-lmm-requirements-00.txt > > > > I have submitted the Localized Mobility Management (LMM) > requirement document. I am sending it out to the working > group so to stir debate before the London IETF meeting. > > If I missed someone in the acknowledgment section, let me know. > I waded through all the MIP working group email debate - including > what went on back in nov-dec timeframe to capture all the context > for the requirements that Phil Roberts summarized in the list > he presented. > While I sought to give finer details (and context) to > existing requirements, > new requirements were also added. > > Thanks to all those who participated - please see acknowledgement > section for all those who contributed. Please try to start some > debate so we can have a nice discussion in London. > > Carl > > > ------------- Begin Forwarded Message ------------- > > Date: Fri, 13 Jul 2001 13:38:32 -0700 (PDT) > From: Carl Williams > Subject: draft-ietf-mobileip-lmm-requirements-00.txt > To: internet-drafts@ietf.org > Cc: Raj.Patil@nokia.com, proberts@megisto.com, > carlw@jurassic.eng.sun.com > MIME-Version: 1.0 > > > > > Attached is an individual Internet draft for submission to the > mobileip working group. The draft is > draft-ietf-mobileip-lmm-requirements-00.txt. > Please post it to the Internet Drafts area. Thanks.... > > > Carl > > > Title: Localized Mobility Management Requirements > > Working Groups: mobileip > > Abstract: > > > Mobile IP is required for hosts moving within the Internet > topology. > Mobile IP manages IP mobility resulting from the change in > Care-of-Address when a host moves within the Internet topology. > When a Mobile Node moves from one point of attachment to another, > a mobility binding update to the respective home agent and/or > correspondent node(s) occurs. Localized Mobility Management (LMM) > refers to a method of handling mobility locally, restricting the > resultant signaling to a specific area, and possibly reducing the > amount of signaling. This document describes requirements which are > designed to guide development of optional extensions to > the Mobile IPv6 > protocol in providing for Localized Mobility Management > functionality. > > > Authors: > > Carl Williams, Editor > > ------------- End Forwarded Message ------------- > > ------_=_NextPart_001_01C10ED5.1DE64E20 Content-Type: text/html; charset="iso-8859-1" RE: [mobile-ip] draft-ietf-mobileip-lmm-requirements-00.txt

Hi Carl,
  Thanks for editing the LMM requirements document. I have some comments on this
document:


> 3.4.4 Optimized signaling within the administrative domain
> By its very nature, LMM reintroduces triangle routing into Mobile IPv6
> in that all traffic must go through the LMM agent. There is no way
> to avoid this. The LMM framework SHOULD be designed in such a way
> that as to reduce the length of the unwanted triangle leg.

I would suggest to change this paragraph as following:

"By its very nature, LMM MAY reintroduce triangle routing into Mobile IPv6
in that all traffic must go through the LMM agent. The LMM framework
SHOULD be designed in such a way that as to reduce the length of the
unwanted triangle leg."

The reason for the change is that a network provider can avoid re-introducing
triangle routing by designing its LMM domain with a single gateway and deploying
one LMM agent per domain at the gateway. This is only one example to avoid
triangular routing. There might be other ways.

> 3.6 Sparse routing element population requirement
>
> The LMM framework SHOULD be supported, at the very minimum, by a sparse
> (proper subset) routing element population within a single
> administration domain.

Could you plaese explain what is the Sparse Routing Element and what is the
reason behind this requirement. Thanks.

Regards

Hongyi




> -----Original Message-----
> From: Carl Williams [mailto:Carl.Williams@eng.sun.com]
> Sent: Friday, July 13, 2001 5:00 PM
> To: mobile-ip@sunroof.eng.sun.com
> Cc: carlw@jurassic.eng.sun.com
> Subject: [mobile-ip] draft-ietf-mobileip-lmm-requirements-00.txt
>
>
>
> I have submitted the Localized Mobility Management (LMM)
> requirement document.  I am sending it out to the working
> group so to stir debate before the London IETF meeting.
>
> If I missed someone in the acknowledgment section, let me know.
> I waded through all the MIP working group email debate - including
> what went on back in nov-dec timeframe to capture all the context
> for the requirements that Phil Roberts summarized in the list
> he presented.
> While I sought to give finer details (and context) to
> existing requirements,
> new requirements were also added.
>
> Thanks to all those who participated - please see acknowledgement
> section for all those who contributed.  Please try to start some
> debate so we can have a nice discussion in London.
>
> Carl
>
>
> ------------- Begin Forwarded Message -------------
>
> Date: Fri, 13 Jul 2001 13:38:32 -0700 (PDT)
> From: Carl Williams <Carl.Williams@eng.sun.com>
> Subject: draft-ietf-mobileip-lmm-requirements-00.txt
> To: internet-drafts@ietf.org
> Cc: Raj.Patil@nokia.com, proberts@megisto.com,
> carlw@jurassic.eng.sun.com
> MIME-Version: 1.0
>
>
>
>
> Attached is an individual Internet draft for submission to the
> mobileip working group.  The draft is
> draft-ietf-mobileip-lmm-requirements-00.txt.
> Please post it to the Internet Drafts area. Thanks....
>
>
> Carl
>
>
> Title:  Localized Mobility Management Requirements
>
> Working Groups: mobileip
>
> Abstract:
>
>
>    Mobile IP is required for hosts moving within the Internet
> topology.
>    Mobile IP manages IP mobility resulting from the change in
>    Care-of-Address when a host moves within the Internet topology.
>    When a Mobile Node moves from one point of attachment to another,
>    a mobility binding update to the respective home agent and/or
>    correspondent node(s) occurs. Localized Mobility Management (LMM)
>    refers to a method of handling mobility locally, restricting the
>    resultant signaling to a specific area, and possibly reducing the
>    amount of signaling. This document describes requirements which are
>    designed to guide development of optional extensions to
> the Mobile IPv6
>    protocol in providing for Localized Mobility Management
> functionality.
>
>   
> Authors: 
>
>   Carl Williams, Editor
>
> ------------- End Forwarded Message -------------
>
>

------_=_NextPart_001_01C10ED5.1DE64E20-- From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 17 13:25:03 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA25909 for ; Tue, 17 Jul 2001 13:25:01 -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 LAA27759; Tue, 17 Jul 2001 11:25: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 KAA24110; Tue, 17 Jul 2001 10:24:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6HHN9324525 for mobile-ip-dist; Tue, 17 Jul 2001 10:23:09 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6HHN5N24518 for ; Tue, 17 Jul 2001 10:23:06 -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 KAA26741 for ; Tue, 17 Jul 2001 10:23:18 -0700 (PDT) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA29955 for ; Tue, 17 Jul 2001 11:24:29 -0600 (MDT) Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21) id ; Tue, 17 Jul 2001 13:22:06 -0400 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Question on draft-team-mobileip-mipv6-sec-reqts-0 0.txt Date: Tue, 17 Jul 2001 13:22:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) 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: Hi, > The requirements presented are so directly related to cryptography. > The word "authorized" is used extensively. I was wondering if it is > possible to include requirements that are more "functional" in nature > and that would allow solutions that do not rely necessarily on crypto. > > For example, the wireless broadcast would allow the MN to overhear > when a BU with its Home Address were sent by an attacker. I'm not sure exactly what you're asking here. This sounds like something that belongs in the threat model, and in fact I believe there is something like it in sec 6.2. Could you explain what the functional requirement is that you'd like to add? > > Another example is that the AR's usually trust each other and thus > might easily exclude an unauthorized AR. Do you mean exclude an unauthorized BU? And I'm not sure how ARs with trust relationships impact messages received by visiting MNs. Phil > > Just wondering, > > Alex > From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 17 14:05:15 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA05874 for ; Tue, 17 Jul 2001 14:05:14 -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 MAA03714; Tue, 17 Jul 2001 12:05: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 LAA01892; Tue, 17 Jul 2001 11:05:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6HI41s24791 for mobile-ip-dist; Tue, 17 Jul 2001 11:04:01 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6HI3wN24784 for ; Tue, 17 Jul 2001 11:03:58 -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 LAA04059 for ; Tue, 17 Jul 2001 11:04:09 -0700 (PDT) From: Basavaraj.Patil@nokia.com Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA02263 for ; Tue, 17 Jul 2001 12:04:07 -0600 (MDT) Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f6HI4Ai25928 for ; Tue, 17 Jul 2001 13:04:10 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 17 Jul 2001 13:04:07 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.1600); Tue, 17 Jul 2001 13:04:06 -0500 content-class: urn:content-classes:message Subject: RE: [mobile-ip] I-D ACTION:draft-team-mobileip-mipv6-sec-reqts-00.txt Date: Tue, 17 Jul 2001 13:04:06 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF44086032@daebe007.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [mobile-ip] I-D ACTION:draft-team-mobileip-mipv6-sec-reqts-00.txt X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 Thread-Index: AcEOHcTKXuLW1HoPEdWpVgBQi2kYTQAzQqRw To: X-OriginalArrivalTime: 17 Jul 2001 18:04:07.0104 (UTC) FILETIME=[DF16E400:01C10EEA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f6HI3wN24785 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 > > Hi folks, > > At first : > very interesting draft and very good job. Bravo !!! > > My question : is it the promised draft on requirements for > protocols candidate to > secure binding mecanisms ? > Yes, this is the proimised draft. It will be converted to a WG document in the near future. > Regards. > JMC. > -Basavaraj > -- > > 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 > From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 17 14:27:54 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10391 for ; Tue, 17 Jul 2001 14:27:53 -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 MAA24889; Tue, 17 Jul 2001 12:28: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 LAA08134; Tue, 17 Jul 2001 11:27:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6HIQTu24876 for mobile-ip-dist; Tue, 17 Jul 2001 11:26:29 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6HIQQN24869 for ; Tue, 17 Jul 2001 11:26:26 -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 LAA14069 for ; Tue, 17 Jul 2001 11:26:37 -0700 (PDT) From: Basavaraj.Patil@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 MAA10011 for ; Tue, 17 Jul 2001 12:27:46 -0600 (MDT) Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f6HIPoi01271 for ; Tue, 17 Jul 2001 13:26:03 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Tue, 17 Jul 2001 13:25:48 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.1600); Tue, 17 Jul 2001 13:25:48 -0500 content-class: urn:content-classes:message Subject: RE: [mobile-ip] Question on draft-team-mobileip-mipv6-sec-reqts-00.txt Date: Tue, 17 Jul 2001 13:25:48 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF440967C9@daebe007.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [mobile-ip] Question on draft-team-mobileip-mipv6-sec-reqts-00.txt X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 Thread-Index: AcEOqRHIBJ/4/XqXEdWpVgBQi2kYTQAIcvSg To: Cc: X-OriginalArrivalTime: 17 Jul 2001 18:25:48.0433 (UTC) FILETIME=[E6BDF010:01C10EED] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f6HIQQN24870 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, > Hi, > > I'm no security expert and I have this humble question. > > The requirements presented are so directly related to cryptography. > The word "authorized" is used extensively. I was wondering if it is > possible to include requirements that are more "functional" in nature > and that would allow solutions that do not rely necessarily on crypto. > It would be interesting to see solutions that do not rely on any crypto to solve the MIPv6 security problem. > For example, the wireless broadcast would allow the MN to overhear > when a BU with its Home Address were sent by an attacker. > True. But is a legitimate MN even monitoring for such data on the wireless links? Probably not. And an attacker does not have to send a BU (with the MNs home address) over the wireless link. The document aims to capture various scenarios and threat models and this is one possibility. > Another example is that the AR's usually trust each other and thus > might easily exclude an unauthorized AR. > I am not sure I get the point here. Are you refering to a specific scenario in the document when you make this observation? > Just wondering, > > Alex > -Basavaraj From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 17 14:37:48 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12406 for ; Tue, 17 Jul 2001 14:37:47 -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 LAA27304; Tue, 17 Jul 2001 11:38: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 LAA21609; Tue, 17 Jul 2001 11:37:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6HIa5D24925 for mobile-ip-dist; Tue, 17 Jul 2001 11:36:05 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6HIa1N24918 for ; Tue, 17 Jul 2001 11:36: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 LAA10675 for ; Tue, 17 Jul 2001 11:36:13 -0700 (PDT) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA16476 for ; Tue, 17 Jul 2001 12:37:28 -0600 (MDT) Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21) id ; Tue, 17 Jul 2001 14:35:04 -0400 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] proposed agenda Date: Tue, 17 Jul 2001 14:35:03 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) 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: Hi folks, here's a new version of the agenda. Although the history of the working group has been to allow presentations of as many drafts as possible, this meeting represents a departure from tradition. Essentially we're going to use the time only for discussing those things which seem to indicate a need for face-to-face discussion time. We would prefer to discuss and resolve most of the working group issues on the mailing list. If you believe there is an issue that needs to be discussed that is not covered by the agenda, please post to the mailing list describing what it is and why. If you have a draft with an interesting idea that the working group should consider for standardization or documentation, please attempt to generate a discussion on the mailing list. Phil and Raj Agenda Phil 5 minutes Update on WG docs Phil 10 minutes This slot is for last minute updates. Here is the current status of docs that are in last call or submitted to Abha. draft-ietf-mobileip-mier-07.txt (submitted) draft-ietf-mobileip-gnaie-04.txt (submitted) draft-ietf-mobileip-3g wireless-ext-06.txt (being updated based on IESG feedback) draft-ietf-mobileip-rfc2002-bis-06.txt (being updated based on IESG feedback) draft-ietf-mobileip-gen-key-00.txt (wg last call expires Friday 7/20 hopefully submitted) draft-ietf-mobileip-aaa-key-07.txt (to be submitted Friday 7/20) draft-ietf-mobileip-qos-requirements-00.txt (wg last call expires 7/25) draft-ietf-mobileip-reg-tunnel-04.txt (being updated) draft-ietf-mobileip-optim-10.txt (past wg last call, sitting on it until MIP v6 issues resolved) Moving MIPv4 to draft standard Charlie 10 minutes Mobile IP v6 security update ? draft-team-mobileip-mipv6-sec-reqts-00.txt 15 minutes Mobile IP v6 other changes in -14 Charlie 5 minutes draft-ietf-mobileip-ipv6-14.txt v4 Low Latency Handover Karim 5 minutes draft-ietf-mobileip-lowlatency-handoffs-v4-01.txt Is there anyone who can share implementation experiences? Is this doc ready for last call? v6 Fast Handover draft-ietf-mobileip-fast-mipv6-01.txt BETH addition? James 10 minutes draft-kempf-beth-ipv6-01.txt Implementation experience report Rajeev Koodli 10 minutes Mobile Network Support Thierry Ernst 15 minutes Mobile IP Component Redundancy Gopal 10 minutes LMM Requirements Carl Williams 15 minutes (draft-ietf-mobileip-lmm-requirements-00.txt) Issues from the list Raj 15 minutes From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 17 16:12:10 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA03636 for ; Tue, 17 Jul 2001 16:12: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 MAA12014; Tue, 17 Jul 2001 12:48: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 LAA24745; Tue, 17 Jul 2001 11:48:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6HIl0Z24982 for mobile-ip-dist; Tue, 17 Jul 2001 11:47:00 -0700 (PDT) Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6HIkmN24972 for ; Tue, 17 Jul 2001 11:46:49 -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 OAA12513 for ; Tue, 17 Jul 2001 14:46:58 -0400 (EDT) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id OAA00026 for mobile-ip@sunroof.eng.sun.com; Tue, 17 Jul 2001 14:47:21 -0400 (EDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6HHNpN24527; Tue, 17 Jul 2001 10:23:51 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA23464; Tue, 17 Jul 2001 10:22:32 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA13214; Tue, 17 Jul 2001 10:22:26 -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 NAA23758; Tue, 17 Jul 2001 13:16:53 -0400 (EDT) Message-Id: <200107171716.NAA23758@ietf.org> From: The IESG To: AAA Working Group , ACAP Working Group , ADSLMIB Working Group , AFT Working Group , AGENTX Working Group , APEX Working Group , ATOMMIB Working Group , AVT Working Group , BEEP Working Group , BGMP Working Group , BMWG Working Group , BRIDGE Working Group , CALSCH Working Group , CAT Working Group , CCAMP Working Group , CNRP Working Group , DELTAV Working Group , DHC Working Group , DIFFSERV Working Group , DISMAN Working Group , DNSEXT Working Group , DNSOP Working Group , ECM Working Group , EDIINT Working Group , ENTMIB Working Group , ENUM Working Group , EOS Working Group , FAX Working Group , FRNETMIB Working Group , FTPEXT Working Group , GEOPRIV Working Group , GRIP Working Group , GSMP Working Group , HUBMIB Working Group , IDMR Working Group , IDN Working Group , IDR Working Group , IDWG Working Group , IFMIB Working Group , IMAPEXT Working Group , IMPP Working Group , IPCDN Working Group , IPFC Working Group , IPNGWG Working Group , IPO Working Group , IPORPR Working Group , IPP Working Group , IPPM Working Group , IPS Working Group , IPSEC Working Group , IPSP Working Group , IPSRA Working Group , IPTEL Working Group , ISIS Working Group , ISSLL Working Group , ITRACE Working Group , KINK Working Group , KRB-WG Working Group , L2TPEXT Working Group , LDAPBIS Working Group , LDAPEXT Working Group , LDUP Working Group , MALLOC Working Group , MANET Working Group , MBONED Working Group , MEGACO Working Group , MIDCOM Working Group , MMUSIC Working Group , MOBILEIP Working Group , MPLS Working Group , MSDP Working Group , MSEC Working Group , MSGTRK Working Group , MULTI6 Working Group , NASREQ Working Group , NAT Working Group , NFSV4 Working Group , NGTRANS Working Group , NNTPEXT Working Group , OPENPGP Working Group , OSPF Working Group , OTP Working Group , PILC Working Group , PIM Working Group , PKIX Working Group , POISSON Working Group , POLICY Working Group , PPPEXT Working Group , PPVPN Working Group , PROVREG Working Group , PWE3 Working Group , RAP Working Group , RESCAP Working Group , RIP Working Group , RMONMIB Working Group , RMT Working Group , ROHC Working Group , RSERPOOL Working Group , RUN Working Group , SACRED Working Group , SEAMOBY Working Group , SECSH Working Group , SIGTRAN Working Group , SIMPLE Working Group , SIP Working Group , SMIME Working Group , SMING Working Group , SNMPCONF Working Group , SNMPV3 Working Group , SPIRITS Working Group , SSM Working Group , STIME Working Group , SYSLOG Working Group , TEWG Working Group , TLS Working Group , TN3270E Working Group , TRADE Working Group , TSVWG Working Group , UDLR Working Group , URN Working Group , USEFOR Working Group , USWG Working Group , VPIM Working Group , VRRP Working Group , WEBDAV Working Group , WEBI Working Group , WTS Working Group , XMLDSIG Working Group , ZEROCONF Working Group cc: iesg@ietf.org Subject: [mobile-ip] Note Well Date: Tue, 17 Jul 2001 13:16:53 -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: Greetings, This is the revised text of the NOTE WELL statement. ------------------------------------------------------ NOTE WELL All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to: - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 17 18:28:04 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA28430 for ; Tue, 17 Jul 2001 18:28:03 -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 PAA10232; Tue, 17 Jul 2001 15:28:36 -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 PAA15146; Tue, 17 Jul 2001 15:28:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6HMRDe25467 for mobile-ip-dist; Tue, 17 Jul 2001 15:27:13 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6HMR9N25460 for ; Tue, 17 Jul 2001 15:27:09 -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 PAA14915 for ; Tue, 17 Jul 2001 15:27:21 -0700 (PDT) Received: from zrc2s03g.us.nortel.com (zrc2s03g.nortelnetworks.com [47.103.122.66]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA02287 for ; Tue, 17 Jul 2001 16:28:38 -0600 (MDT) Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id RAA18425 for ; Tue, 17 Jul 2001 17:29:05 -0500 (CDT) Received: from zrchb200.us.nortel.com by smtprch1.nortel.com; Tue, 17 Jul 2001 17:23:21 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id <30ZQHD2B>; Tue, 17 Jul 2001 17:23:18 -0500 Message-ID: <85AA7486A2C1D411BCA20000F8073E4302D89C8D@crchy271.us.nortel.com> From: "Glenn Morrow" To: ohnishi.hiroyuki@lab.ntt.co.jp, takagi.yasushi@lab.ntt.co.jp Cc: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] re:draft-ohnishi-mobileip-mbg-00.txt Date: Tue, 17 Jul 2001 17:23:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10F0F.14634260" 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_01C10F0F.14634260 Content-Type: text/plain; charset="iso-8859-1" Hiroyuki and Yasushi, In reference to your draft: http://www.ietf.org/internet-drafts/draft-ohnishi-mobileip-mbg-00.txt I have a few questions and comments: Would the MGBs be similar or perhaps even the same border routers between autonomous systems of 2 ISPs such as two cellular ISPs? What signaling protocol are you looking at to distribute the fact that the address ranges are mobile address from the HA to the MGBs: BGP, OSPF, IS-IS or do you feel that this can be done with simple configuration? It seems to me that the conveyance of this information would also constitute an IP roaming agreement. An automatic, routing protocol-based way of setting these up would be of benefit IMO. Furthurmore, I believe some similar work should be done to identify geographical adjacency for handoff purposes. Question to the chairs and/or ADs: Would this work fall under MIP WG or routing WGs? Are you planning any follow-up work on this? The expect that the antagonists to this draft may complain about the number of per-node routes and what this will do to the routing table size. Last time I checked route lookups were pretty fast in most of the newer products - even with fairly large routing tables; nevertheless, I expect there to be some contention on this. Has there been any analysis on this? Some positive comments I have on this is that it does indeed seem to be a very realistic deployment method for route optimization. I have not heard of any plans to support route optimization on IPv4 hosts by any of the major OS vendors. It makes sense to me to distribute the fact that certain addresses are mobile to portions of the network. I honestly believe that there are other reasons such as location privacy to maintain the mobile bindings in routers as well. I believe that such functions are better left in purpose built machines that handle handle fast lookups on relatively large route tables. Some analysis on this aspect would also be useful? Another thing I would like to bring up to folks on the list is that even in IPv6, there is no MUST that CN hosts support the binding functions of MIPv6. With this in mind, I expect there will be nodes out there that don't do it. So even in IPv6, the ubiquity of route optimization is still in question. This gives credence to the reasoning for the solution in IPv6 as well. Another thing I would like to point out that the signaling methodology seems quite similar, as far as the MGP querying the HA for the binding, to some the initial work on the GES, 8+8 concepts. You seem to be doing the query without having to changing the IP header or mess with the addressing schemas - a bonus IMHO. The fact that you are using the mobile IP HA instead of something like DNS is also a good idea IMO due to speed and an already overloaded DNS. It also seems to me that this would allow IPv4 ISPs to offer the service without having to fork-lift all of their clients' host operating systems. A money saving and realistic idea. On the analysis questions - are there any papers available which explore these topics you could point us to? Thanks, Glenn ------_=_NextPart_001_01C10F0F.14634260 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable re:draft-ohnishi-mobileip-mbg-00.txt

Hiroyuki and Yasushi,

In reference to your draft:

http://www.ietf.org/internet-drafts/draft-ohnishi-mobi= leip-mbg-00.txt

I have a few questions and comments:

Would the MGBs be similar or perhaps even the same = border routers between autonomous systems of 2 ISPs such as two = cellular ISPs?

What signaling protocol are you looking at to = distribute the fact that the address ranges are mobile address from the = HA to the MGBs: BGP, OSPF, IS-IS or do you feel that this can be done = with simple configuration?

It seems to me that the conveyance of this = information would also constitute an IP roaming agreement. An = automatic, routing protocol-based way of setting these up would be of = benefit IMO. Furthurmore, I believe some similar work should be done to = identify geographical adjacency for handoff purposes.

Question to the chairs and/or ADs:

Would this work fall under MIP WG or routing = WGs?

Are you planning any follow-up work on this?

The expect that the antagonists to this draft may = complain about the  number of per-node routes and what this will = do to the routing table size. Last time I checked route lookups were = pretty fast in most of the newer products - even with fairly large = routing tables; nevertheless, I expect there to be some contention on = this. Has there been any analysis on this?

Some positive comments I have on this is that it does = indeed seem to be a very realistic deployment method for route = optimization. I have not heard of any plans to support route = optimization on IPv4 hosts by any of the major OS vendors. It makes = sense to me to distribute the fact that certain addresses are mobile to = portions of the network. I honestly believe that there are other = reasons such as location privacy to maintain the mobile bindings in = routers as well. I believe that such functions are better left in = purpose built machines that handle handle fast lookups on relatively = large route tables. Some analysis on this aspect would also be useful? =

Another thing I would like to bring up to folks on = the list is that even in IPv6, there is no MUST that CN hosts support = the binding functions of MIPv6. With this in mind, I expect there will = be nodes out there that don't do it. So even in IPv6, the ubiquity of = route optimization is still in question. This gives credence to the = reasoning for the solution in IPv6 as well.

Another thing I would like to point out that the = signaling methodology seems quite similar, as far as the MGP querying = the HA for the binding, to some the initial work on the GES, 8+8 = concepts. You seem to be doing the query without having to changing the = IP header or mess with the addressing schemas - a bonus IMHO. The fact = that you are using the mobile IP HA instead of something like DNS is = also a good idea IMO due to speed and an already overloaded = DNS.

It also seems to me that this would allow IPv4 ISPs = to offer the service without having to fork-lift all of their clients' = host operating systems. A money saving and realistic idea.

On the analysis questions - are there any papers = available which explore these topics you could point us to?

Thanks,

Glenn

------_=_NextPart_001_01C10F0F.14634260-- From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 17 21:18:07 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA03543 for ; Tue, 17 Jul 2001 21:18:06 -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 TAA03877; Tue, 17 Jul 2001 19:18: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 SAA06226; Tue, 17 Jul 2001 18:18:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6I1GnU25683 for mobile-ip-dist; Tue, 17 Jul 2001 18:16:49 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6I1EXN25668; Tue, 17 Jul 2001 18:14:33 -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 SAA10465; Tue, 17 Jul 2001 18:14:46 -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 TAA02021; Tue, 17 Jul 2001 19:14:44 -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 SAA02041; Tue, 17 Jul 2001 18:14:45 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6I1Eiq02453; Tue, 17 Jul 2001 18:14:44 -0700 X-mProtect: Tue, 17 Jul 2001 18:14:44 -0700 Nokia Silicon Valley Messaging Protection Received: from tpagtzis.iprg.nokia.com (205.226.2.115, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpd0PyQlU; Tue, 17 Jul 2001 18:14:43 PDT Message-ID: <3B54E304.30467CD6@iprg.nokia.com> Date: Tue, 17 Jul 2001 18:14:44 -0700 From: Theo Pagtzis Organization: UCL/NOKIA X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.1-STABLE i386) X-Accept-Language: el, en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com CC: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Neighbour discovery proactive state and routing neighbourhood 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 Hi all, we would appreciate people's feedback on the discovery process and mapping of the mobility neighbourhood onto the correct routing neighbourhood for the purpose of establishing IP state in a forward manner. On the particular, issue we would like to hear the views of people on introducing a new state in the Neighbour Discovery process, the one of PROACTIVELY REACHABLE, in the light of extending Neighbour Discovery to tackle proactive mobility. The two issues are discussed in detail in draft-pagtzis-mobileip-proactivev6-00.txt/.ps (the .ps file can be found in (http://www.cs.ucl.ac.uk/staff/t.pagtzis/docs/docs.html)) Thanks Theo UCL/ Mobile Systems From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 17 21:40:54 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA09359 for ; Tue, 17 Jul 2001 21:40:53 -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 TAA14515; Tue, 17 Jul 2001 19:41: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 SAA09532; Tue, 17 Jul 2001 18:41:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6I1e1x25786 for mobile-ip-dist; Tue, 17 Jul 2001 18:40:01 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6I1dwN25779 for ; Tue, 17 Jul 2001 18:39: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 SAA20596; Tue, 17 Jul 2001 18:39:45 -0700 (PDT) Received: from telecom.samsung.co.kr ([165.213.221.4]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA13775; Tue, 17 Jul 2001 19:39:42 -0600 (MDT) Received: from metro (a22414 [165.213.224.14]) by telecom.samsung.co.kr (8.9.3/8.9.3) with SMTP id KAA05227; Wed, 18 Jul 2001 10:42:08 +0900 (KST) Message-ID: <00ed01c10f2a$d70a3ce0$0ee0d5a5@telecom.samsung.co.kr> From: "junhyuk song" To: Cc: , "Pat Calhoun" , =?ks_c_5601-1987?B?waTA57+1?= Subject: [mobile-ip] MN-AAA Authentication Extension Clarification Date: Wed, 18 Jul 2001 10:41:59 +0900 Organization: cdma2000 system MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00EA_01C10F76.45A23360" 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: This is a multi-part message in MIME format. ------=_NextPart_000_00EA_01C10F76.45A23360 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SGkgQWxsLA0KDQpMYXN0IHdlZWssIDNHUFAyIFRTRy1QIHdvcmtncm91cCBkZWNpZGUgdG8gc3Vw cG9ydCBNb2JpbGUgSVAgc2VjdXJpdHkgZW5oYW5jZW1lbnQgYmFzZWQgb24gZHJhZnQtaWV0Zi1t b2JpbGVpcC1BQUEta2V5LTA3IGFuZCBkcmFmdC1pZXRmLW1vYmlsZWlwLWdlbi1rZXktMDAgYnkg Q2hhcmxlcyBQZXJraW5zIGFuZCBQYXQgQ2FsaG91biwgaWYgdGhvc2UgSW50ZXJuZXQgRHJhZnQg YmVjb21lcyBwcm9wb3NlZCBzdGFuZGFyZCBieSBQUzAwMDFCIEMzIHRpbWVsaW5lIChTZXB0ZW1i ZXIpLg0KDQpTaW5jZSB0aGUgZGVmYXVsdCBBQUEgc2VydmVyIGluIElTLTgzNSBpcyBiYXNlZCBv biBSQURJVVMgcHJvdG9jb2wsIE1OLUhBIGtleSBnZXJuYXRpb24gYnkgdGhlIEtleSBSZXBseSBN b2JpbGUgSVAgZXh0ZW5zaW9uIHNjaGVtZSByZXF1aXJlcyBzb21lIGFzc3VtcHRpb24gYW5kIGNo YW5nZXMsIHN1Y2ggYXMgTW9iaWxlIE5vZGUgTVVTVCBjb21wdXRlIE1OLUhBIGF1dGhlbnRpY2F0 b3IgYnkgc29tZSBhcmJpdGFyeSB2YWx1ZS4NCg0KTW9zdCBvZiBhbGwsIG5vdyBNTi1BQUEgYXV0 aGVudGljYXRpb24gU0hPVUxEIGJlIG1hbmRhdG9yeSBiZWNhdXNlIEhBIGRlcGVuZHMgb24gTU4t QUFBIGF1dGhlbnRpY2F0aW9uIGZvciBpbml0aWFsIE1JUCBSZWdpc3RlciBSZXF1ZXN0Lg0KVGhp cyBpcyBzaW1wbHkgYmVjYXVzZSBNTiBkb2Vzbid0IGhhdmUgTU4tSEEgc2hhcmVkIGtleSBmb3Ig dGhlIGluaXRpYWwgUlJRLg0KDQpDdXJyZW50bHkgdGhlcmUgaXMgUkZDMjAwMiBiaXMgMC42IGRy YWZ0IGlzIGF2YWlsYWJsZS4gIFVubGlrZSBSRkMtMjAwMiBub3cgaXQgcmVxdWlyZXMgIkV4YWN0 bHkgb25lIGF1dGhvcml6YXRpb24tZW5hYmxpbmcgZXh0ZW5zaW9uIiByYXRoZXIgdGhhbiAiRXhh Y3RseSBvbmUgTW9iaWxlLUhvbWUgQXV0aGVudGljYXRpb24gRXh0ZW5zaW9uIiAoc2VlIHNlY3Rp b24gMy44LjIuMSkuDQoNCkhvd2V2ZXIsIGlmIHlvdSBsb29rIGF0IHRoZSBzZWN0aW9uIDMuNS4y LCANCml0IHNhaWQgICJFeGFjdGx5IG9uZSBhdXRob3JpemF0aW9uLWVuYWJsaW5nIGV4dGVuc2lv biBNVVNUIGJlIHByZXNlbnQgaW4gYWxsIFJlZ2lzdHJhdGlvbiBSZXF1ZXN0cywgYW5kIGFsc28g aW4gYWxsIFJlZ2lzdHJhdGlvbiBSZXBsaWVzIGdlbmVyYXRlZCBieSB0aGUgSG9tZSBBZ2VudCAu IA0KIFRoZSBNb2JpbGUtSG9tZSBBdXRoZW50aWNhdGlvbiBFeHRlbnNpb24gaXMgIGFsd2F5cyBh biBhdXRob3JpemF0aW9uLWVuYWJsaW5nIGZvciByZWdpc3RyYXRpb24gbWVzc2FnZXMgc3BlY2lm aWVkIGluIHRoaXMgZG9jdW1lbnQuIg0KDQpJIGJlbGlldmUgYXV0aG9yaXphdGlvbi1lbmFibGlu ZyBjb3VsZCBtZWFuIGJvdGggTU4tSEEgYW5kIE1OLUFBQSBhdXRoZW50aWNhdGlvbi4NCklmIHRo ZSBmdXR1cmUgcmVsZWFzZSBvZiBNSVB2NCBSRkMgZG9lc24ndCBzdXBwb3J0IE1OLUFBQSBhdXRo ZW50aWNhdGlvbiBmcm9tIEhBLCBpdCBjYW5ub3QgYWNjb21vZGF0ZSBlaXRoZXIgUkZDLTMwMTIg b3IgS2V5IFJlcGx5IE1JUCBleHRlbnNpb24gZm9yIFJBRElVUyBiYXNlZCBBQUEuICBJIHdpc2gg UkZDLTIwMDIgYmlzIGNhbiBjbGFyaWZ5IHRoZSBzdXBwb3J0IG9mIE1OLUFBQSBhdXRoZW50aWNh dGlvbiBleHRlbnNpb24uDQoNCg0KUmVnYXJkcywNCkpIIFNPTkcNCg== ------=_NextPart_000_00EA_01C10F76.45A23360 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA1LjUwLjQ1MjIuMTgwMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPkhpIEFsbCw8 L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElW PjxGT05UIHNpemU9Mj5MYXN0IHdlZWssIDNHUFAyIFRTRy1QIHdvcmtncm91cCBkZWNpZGUgdG8g c3VwcG9ydCZuYnNwO01vYmlsZSANCklQIHNlY3VyaXR5IGVuaGFuY2VtZW50IGJhc2VkIG9uIGRy YWZ0LWlldGYtbW9iaWxlaXAtQUFBLWtleS0wNyBhbmQgDQpkcmFmdC1pZXRmLW1vYmlsZWlwLWdl bi1rZXktMDAgYnkgQ2hhcmxlcyBQZXJraW5zIGFuZCBQYXQgQ2FsaG91biwgaWYgdGhvc2UgDQpJ bnRlcm5ldCBEcmFmdCZuYnNwO2JlY29tZXMgcHJvcG9zZWQgc3RhbmRhcmQgYnkmbmJzcDtQUzAw MDFCIEMzIHRpbWVsaW5lIA0KKFNlcHRlbWJlcikuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBz aXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+U2luY2UgdGhlIGRl ZmF1bHQgQUFBIHNlcnZlciBpbiBJUy04MzUgaXMgYmFzZWQgb24gUkFESVVTIA0KcHJvdG9jb2ws IE1OLUhBIGtleSBnZXJuYXRpb24gYnkgdGhlIEtleSBSZXBseSBNb2JpbGUgSVAgZXh0ZW5zaW9u Jm5ic3A7c2NoZW1lIA0KcmVxdWlyZXMgc29tZSBhc3N1bXB0aW9uIGFuZCBjaGFuZ2VzLCBzdWNo IGFzIE1vYmlsZSBOb2RlIE1VU1QgY29tcHV0ZSBNTi1IQSANCmF1dGhlbnRpY2F0b3IgYnkgc29t ZSBhcmJpdGFyeSB2YWx1ZS48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+ Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5Nb3N0IG9mIGFsbCwgbm93IE1OLUFBQSBh dXRoZW50aWNhdGlvbiZuYnNwO1NIT1VMRCANCmJlJm5ic3A7bWFuZGF0b3J5IGJlY2F1c2UgSEEg ZGVwZW5kcyBvbiBNTi1BQUEgYXV0aGVudGljYXRpb24gZm9yIGluaXRpYWwgTUlQIA0KUmVnaXN0 ZXIgUmVxdWVzdC48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5UaGlzIGlzIHNpbXBs eSBiZWNhdXNlIE1OIGRvZXNuJ3QgaGF2ZSBNTi1IQSBzaGFyZWQga2V5IGZvciANCnRoZSBpbml0 aWFsIFJSUS48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9E SVY+DQo8RElWPjxGT05UIHNpemU9Mj5DdXJyZW50bHkgdGhlcmUgaXMgUkZDMjAwMiBiaXMgMC42 IGRyYWZ0IGlzIGF2YWlsYWJsZS4mbmJzcDsgDQpVbmxpa2UgUkZDLTIwMDIgbm93IGl0IHJlcXVp cmVzICJFeGFjdGx5IG9uZSBhdXRob3JpemF0aW9uLWVuYWJsaW5nIGV4dGVuc2lvbiIgDQpyYXRo ZXIgdGhhbiAiRXhhY3RseSBvbmUgTW9iaWxlLUhvbWUgQXV0aGVudGljYXRpb24gRXh0ZW5zaW9u IiAoc2VlIHNlY3Rpb24gDQozLjguMi4xKS48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9 Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5Ib3dldmVyLCBpZiB5b3Ug bG9vayBhdCB0aGUgc2VjdGlvbiAzLjUuMiwgPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXpl PTI+aXQgc2FpZCZuYnNwOzwvRk9OVD48Rk9OVCBzaXplPTI+ICJFeGFjdGx5IG9uZSANCmF1dGhv cml6YXRpb24tZW5hYmxpbmcgZXh0ZW5zaW9uIE1VU1QgYmUgcHJlc2VudCBpbiBhbGwgUmVnaXN0 cmF0aW9uIFJlcXVlc3RzLCANCmFuZCBhbHNvIGluIGFsbCBSZWdpc3RyYXRpb24gUmVwbGllcyBn ZW5lcmF0ZWQgYnkgdGhlIEhvbWUgDQpBZ2VudCZuYnNwOy4mbmJzcDs8L0ZPTlQ+PC9ESVY+DQo8 RElWPjxGT05UIHNpemU9Mj4mbmJzcDtUaGUgTW9iaWxlLUhvbWUgQXV0aGVudGljYXRpb24gRXh0 ZW5zaW9uIGlzJm5ic3A7IGFsd2F5cyANCmFuIGF1dGhvcml6YXRpb24tZW5hYmxpbmcgZm9yIHJl Z2lzdHJhdGlvbiBtZXNzYWdlcyBzcGVjaWZpZWQgaW4gdGhpcyANCmRvY3VtZW50LiI8L0ZPTlQ+ PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05U IHNpemU9Mj5JIGJlbGlldmUgYXV0aG9yaXphdGlvbi1lbmFibGluZyBjb3VsZCBtZWFuIGJvdGgg TU4tSEEgYW5kIA0KTU4tQUFBIGF1dGhlbnRpY2F0aW9uLjwvRk9OVD48L0RJVj4NCjxESVY+PEZP TlQgc2l6ZT0yPklmJm5ic3A7dGhlJm5ic3A7ZnV0dXJlIHJlbGVhc2Ugb2YgTUlQdjQgUkZDJm5i c3A7ZG9lc24ndCANCnN1cHBvcnQgTU4tQUFBIGF1dGhlbnRpY2F0aW9uJm5ic3A7ZnJvbSBIQSwm bmJzcDtpdCZuYnNwO2Nhbm5vdCBhY2NvbW9kYXRlIA0KZWl0aGVyIFJGQy0zMDEyJm5ic3A7b3Ig S2V5IFJlcGx5IE1JUCBleHRlbnNpb24gZm9yIFJBRElVUyBiYXNlZCBBQUEuJm5ic3A7IEkgDQp3 aXNoIFJGQy0yMDAyIGJpcyBjYW4gY2xhcmlmeSB0aGUgc3VwcG9ydCBvZiBNTi1BQUEgYXV0aGVu dGljYXRpb24gDQpleHRlbnNpb24uPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9G T05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0K PERJVj48Rk9OVCBzaXplPTI+UmVnYXJkcyw8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9 Mj5KSCBTT05HPC9GT05UPjwvRElWPjwvQk9EWT48L0hUTUw+DQo= ------=_NextPart_000_00EA_01C10F76.45A23360-- From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 18 03:43:03 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA23448 for ; Wed, 18 Jul 2001 03:43: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 BAA03669; Wed, 18 Jul 2001 01:43:20 -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 AAA08029; Wed, 18 Jul 2001 00:43:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6I7fqB26134 for mobile-ip-dist; Wed, 18 Jul 2001 00:41:52 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6I7fmN26127 for ; Wed, 18 Jul 2001 00:41:49 -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 AAA21764 for ; Wed, 18 Jul 2001 00:42:01 -0700 (PDT) Received: from ns2.iaf.fi (ns2.iaf.fi [195.94.103.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA26755 for ; Wed, 18 Jul 2001 01:43:16 -0600 (MDT) Received: from proxyfw.netseal.com (gw.netseal.com [195.94.100.110]) by ns2.iaf.fi (8.11.2/8.11.2) with ESMTP id f6I7bQ401603 for ; Wed, 18 Jul 2001 10:37:26 +0300 Received: from (Undisclosed Firewall protected host) by Baudia Firewall with SMTP id KAA00892 for ; Wed, 18 Jul 2001 10:00:54 +0300] Message-ID: <001701c10f5d$85b7b970$3f02a8c0@garibaldi> From: "Sami Vaarala" To: References: Subject: Re: [mobile-ip] draft-vaarala-mobileip-nat-traversal-00.txt -- NAT traversal using the Mobile IP port Date: Wed, 18 Jul 2001 10:44:48 +0300 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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Henrik, (Long posting, sorry...) > On the dynamically assigned message type: > > Although we have chosen not to use such to tunnel trough 434, I to > some extent agree with what you write on this, however: If you deploy a > number of HA's & clients worldwide, using this solution, and some of > the MIP message numbers which are now unassigned become assigned for > standardised messages, you are in a situation where all of your HA's > and clients will need to be reconfigured to not use those message > numbers -- and if your company is successful in selling this solution, > that could be a lot of HA's and clients! There's always a chance then, > that some customer would miss or ignore the reconfiguration. We seem to disagree on this point, and I'll try to break down the issue to see where exactly we disagree. Basically I am trying to convince you that no reconfiguration is necessary -- unless a software update is done to add support for new message types anyway. 1. I have assumed that it is okay to diverge into a non-conformant mode if support for the traversal feature is mutually established in an authenticated manner. 2. Both the mobile node and the home agent can independently determine which mobile IP message type(s) they are willing to reserve for tunnelling purposes. If the node supports an IANA assigned message type X, it MUST NOT indicate that such a number would be acceptable for traversal purposes. Both the MN and the HA independently define which message type(s) they are willing to accept when _receiving_ tunnelled packets, so difference of implemented message types is not a problem. 3. Only the MN and the HA need to understand these packets. There are no third party conflicts, unless you consider hosts such as network sniffers as such. (True, it would be irritating to see network packets incorrectly dumped, but I don't consider this a major problem :) 4. Now, suppose that MN and HA are both supporting the traversal mechanism AND that they are independently administrated. Supposed now that a new IANA message type X is defined, and the HA (but not the MN) is upgraded to support the message type. 4a. After the software update the HA would no longer indicate that message type X would be valid for traversal. Thus MN->HA traffic would cause no conflicts, even if MN is not updated (since MN will obey the traversal requirements indicated by the HA). 4b. HA->MN traffic would also work. If MN would happen to indicate that X is used as a traversal marker, the HA would determine that MN _does not_ support X anyway, and would refrain from sending the actual message type X to the MN (since it would never process it anyway). Should the HA send X to MN prior to establishing a traversal binding, the MN would respond normally, as if an unsupported message type was received. 5. MN upgraded, HA not -> similar to case 4. 6. One host is upgraded and rebooted while an existing binding is still valid. This causes a small period of time during which the other host may be sending traversal processed packets that might conflict with the rebooted host. However, by using short lifetimes for traversal bindings (eg one minute), this would be a minor concern. ---- The point I am trying to make is that message type changes require a _software update_ anyway, and the software can be updated at the same time to not use conflicting traversal markers. Point 4b) will have to be elaborated in the draft, since it is important with regards to software upgrades. The described approach is not very clean since it interacts with the rest of the Mobile IP implementation. Any ideas on how to make it cleaner? > I don't think you should assume that only your own clients will be used > with your HA's, or only your own HA's will be used to support your > clients -- and if other vendors' products with new message types were to > conflict with your tunneling solution because a reconfiguration had > been missed, it would be quite unfortunate. I don't see how this could happen? The following cases arise: 1. Neither supports the draft -- no problem here. 2. MN supports, HA doesn't -- NVSE ignored. 3. MN does not support, HA does -- NVSE not sent, no problem. 4. Both support, but disagree on which message types are okay for traversal -- no problem, since traversal for each direction is negotiated separately. Have I missed something here that you are concerned about? > In theory, you should still never get a conflict if you take care to > treat these message types as tunneling only after negotiation, and > as unrecognised messages otherwise, but it's balancing a little too > close to the edge for my liking... :-) > (Remember Murphy.) There are conflicts if one assumes that messages before and after establishing a traversal binding are confused, that is true. However, one could also argue that the MN might confuse GRE tunneling with minimal encapsulation, or co-located address with using an FA. Is there a fundamental difference between these different types of confusion? Since the traversal parameters and state are a part of the binding state, which has to be carefully maintained anyway, I don't see a problem with the confusion -- the traversal state would be bound to the same data structures as eg. GRE vs. minimal encapsulation mode. > It would also be unfortunate if the IANA felt that due to the existence > in the marketplace of a solution which had subsumed the use of message > types 0x45..0x4f, those could not be used for new Mobile IP messages > types, and had to be barred. I agree. This is why I think that both hosts should indicate which marker octets they are willing to use for optimized traversal as well, ie by indicating the range or the individual octets supported. Of course, it would be best if there was a consensus that MIPv4 NAT traversal is important, and marker octets were assigned by IANA; then there would be no possibility for confusion, and no need for negotiation of markers. > On TCP-based traversal: > > I think that there would be added complexity and overhead, without > proportionately added benefit. If the protocol being carried in the > tunnel also was TCP, I think you might get complex interactions > between the two levels of TCP timers, resends and whatnot? > We chose to go with UDP because IP-in-UDP behaviour is very close > to IP-in-IP or bare IP. I'm sure you have made the same reflexions. I agree completely; the advantages do not seem to be worth the hassle. UDP tunnelling can be thought of as a new kind of mobility binding, while TCP tunnelling requires much larger changes to the protocol model. > On standardised NAT-traversal: > > Yes. And I'm slightly surprised at the scarcity of comments, so far. > Of course, this subject isn't as sexy as MIPv6 or Fast Handover :-) It is amazing though, because NAT traversal is a _major_ deployment requirement. Does this indicate that people are not deploying? ;-) Best regards, -Sami -- Sami Vaarala Senior Software Architect NetSeal Technologies From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 18 04:52:43 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA01269 for ; Wed, 18 Jul 2001 04:52:42 -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 BAA04875; Wed, 18 Jul 2001 01: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 BAA17707; Wed, 18 Jul 2001 01:52:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6I8pT326261 for mobile-ip-dist; Wed, 18 Jul 2001 01:51:29 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6I8pON26254 for ; Wed, 18 Jul 2001 01:51:24 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA16256 for ; Wed, 18 Jul 2001 01:51:38 -0700 (PDT) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA23276 for ; Wed, 18 Jul 2001 01:51:36 -0700 (PDT) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate.mot.com (motgate 2.1) with ESMTP id BAA23391 for ; Wed, 18 Jul 2001 01:51:36 -0700 (MST)] Received: [from m-il06-r4.mot.com (m-il06-r4.mot.com [129.188.137.196]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id BAA12016 for ; Wed, 18 Jul 2001 01:51:35 -0700 (MST)] Received: from [140.101.173.9] by m-il06-r4.mot.com with ESMTP for mobile-ip@sunroof.eng.sun.com; Wed, 18 Jul 2001 03:51:34 -0500 Received: (from root@localhost) by zorglub.crm.mot.com (8.8.8/8.8.8/crm-1.6) id KAA09566 for mobile-ip@sunroof.eng.sun.com.DELIVER; Wed, 18 Jul 2001 10:51:31 +0200 (METDST) Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by zorglub.crm.mot.com (8.8.8/8.8.8/crm-1.6) with ESMTP id KAA09535 for ; Wed, 18 Jul 2001 10:51:30 +0200 (METDST) To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Question on draft-team-mobileip-mipv6-sec-reqts-0 0.txt References: From: Alexandru Petrescu Date: 18 Jul 2001 10:51:29 +0200 In-Reply-To: Message-Id: Lines: 33 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.0.103 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: Phil Roberts writes: > > For example, the wireless broadcast would allow the MN to overhear > > when a BU with its Home Address were sent by an attacker. > > I'm not sure exactly what you're asking here. This sounds like something > that belongs in the threat model, and in fact I believe there is something > like it in sec 6.2. What I'm proposing is that when the MN overhears a BU with the same Home Address option that was not sent by itself it could be required to "stop" communication. If the attacker wanted to become an MITM then at least the MN will be protected. That does not rely on authorization mechanisms, but on capacity to overhear. Again in case B, when AR forwards a BU from MN and the corresponding BAck from CN it could forbid subsequent attacker BU with the same HoA and different CoA. > > Another example is that the AR's usually trust each other and thus > > might easily exclude an unauthorized AR. > > Do you mean exclude an unauthorized BU? And I'm not sure how ARs > with trust relationships impact messages received by visiting MNs. I meant "unauthorized AR". If attacker adds new AR by attaching to the same point where the other AR's are attached (and not by DR'ing to an existing AR as in threat B.3) then it should be the trust relationships between existing AR's that will exclude the attacker AR. The threat of attaching an AR as described above could probably be added as Threat B.4. Alex From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 18 04:59:28 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA02039 for ; Wed, 18 Jul 2001 04:59:27 -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 CAA09326; Wed, 18 Jul 2001 02:59: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 BAA17600; Wed, 18 Jul 2001 01:59:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6I8wo426303 for mobile-ip-dist; Wed, 18 Jul 2001 01:58:50 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6I8wkN26296 for ; Wed, 18 Jul 2001 01:58: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 BAA18155 for ; Wed, 18 Jul 2001 01:58:59 -0700 (PDT) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA29942 for ; Wed, 18 Jul 2001 03:00:14 -0600 (MDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (motgate 2.1) with ESMTP id BAA26925 for ; Wed, 18 Jul 2001 01:58:57 -0700 (MST)] Received: [from m-il06-r4.mot.com (m-il06-r4.mot.com [129.188.137.196]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id BAA04340 for ; Wed, 18 Jul 2001 01:58:57 -0700 (MST)] Received: from [140.101.173.9] by m-il06-r4.mot.com with ESMTP for mobile-ip@sunroof.eng.sun.com; Wed, 18 Jul 2001 03:58:55 -0500 Received: (from root@localhost) by zorglub.crm.mot.com (8.8.8/8.8.8/crm-1.6) id KAA13643 for mobile-ip@sunroof.eng.sun.com.DELIVER; Wed, 18 Jul 2001 10:58:53 +0200 (METDST) Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by zorglub.crm.mot.com (8.8.8/8.8.8/crm-1.6) with ESMTP id KAA13609; Wed, 18 Jul 2001 10:58:50 +0200 (METDST) To: Basavaraj.Patil@nokia.com Cc: , Alexandru Petrescu-AAP021 Subject: Re: [mobile-ip] Question on draft-team-mobileip-mipv6-sec-reqts-00.txt References: <697DAA22C5004B4596E033803A7CEF440967C9@daebe007.NOE.Nokia.com> From: Alexandru Petrescu Date: 18 Jul 2001 10:58:49 +0200 In-Reply-To: <697DAA22C5004B4596E033803A7CEF440967C9@daebe007.NOE.Nokia.com> Message-Id: Lines: 34 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.0.103 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: Basavaraj.Patil@nokia.com writes: > It would be interesting to see solutions that do not rely on any crypto > to solve the MIPv6 security problem. My remark was not to say that I have such solution in mind. I was mainly pointing out to solve only the minimal set of needs by using crypto. > > For example, the wireless broadcast would allow the MN to overhear > > when a BU with its Home Address were sent by an attacker. > > > > True. But is a legitimate MN even monitoring for such data on the > wireless links? Probably not. Why wouldn't a legitimate MN monitor the wireless link? > > Another example is that the AR's usually trust each other and thus > > might easily exclude an unauthorized AR. > > I am not sure I get the point here. Are you refering to a specific > scenario in the document when you make this observation? YEs, I was referring to threat B.3 but with a twist. If attacker adds new AR by attaching to the same point where the other AR's are attached (and not by DR'ing to an existing AR as in threat B.3) then it should be the trust relationships between existing AR's that will exclude the attacker AR. The threat of attaching an AR as described above could probably be added as Threat B.4. Alex From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 18 05:01:01 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA02268 for ; Wed, 18 Jul 2001 05:01: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 DAA10447; Wed, 18 Jul 2001 03:01:36 -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 CAA18070; Wed, 18 Jul 2001 02:01:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6I90WQ26333 for mobile-ip-dist; Wed, 18 Jul 2001 02:00:32 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6I90SN26326 for ; Wed, 18 Jul 2001 02:00:28 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA18334 for ; Wed, 18 Jul 2001 02:00:41 -0700 (PDT) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA09297 for ; Wed, 18 Jul 2001 02:00:41 -0700 (PDT) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate2.mot.com (motgate2 2.1) with ESMTP id CAA13182 for ; Wed, 18 Jul 2001 02:00:40 -0700 (MST)] Received: [from m-il06-r2.mot.com (m-il06-r2.mot.com [129.188.137.24]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id BAA12726 for ; Wed, 18 Jul 2001 01:53:21 -0700 (MST)] Received: from [140.101.173.9] by m-il06-r2.mot.com with ESMTP for mobile-ip@sunroof.eng.sun.com; Wed, 18 Jul 2001 04:00:29 -0500 Received: (from root@localhost) by zorglub.crm.mot.com (8.8.8/8.8.8/crm-1.6) id LAA14356 for mobile-ip@sunroof.eng.sun.com.DELIVER; Wed, 18 Jul 2001 11:00:35 +0200 (METDST) Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by zorglub.crm.mot.com (8.8.8/8.8.8/crm-1.6) with ESMTP id LAA14315 for ; Wed, 18 Jul 2001 11:00:34 +0200 (METDST) To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Comments on mipv6 threat model From: Alexandru Petrescu Date: 17 Jul 2001 22:05:15 +0200 Message-Id: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.0.103 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Lines: 11 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, I have further comments on the mipv6 threat model in draft-team-mobileip-mipv6-sec-reqts-00.txt. -there's a text ordering problem at the end of section 6.8 and before section 6.8.1: threat H.3 is mentioned twice, once as H.2 and once as H.3. -in the case B (attacker on the same link as MN in a foreign net) an attacker can send false negative Binding Acknowledgments to the MN in response to legitimate BU's. Effect: MN keeps sending BU's. From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 18 05:57:26 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA13210 for ; Wed, 18 Jul 2001 05:57:25 -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 CAA22098; Wed, 18 Jul 2001 02:57: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 CAA22284; Wed, 18 Jul 2001 02:57:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6I9uLU26462 for mobile-ip-dist; Wed, 18 Jul 2001 02:56:21 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6I9uHN26455 for ; Wed, 18 Jul 2001 02:56:17 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA21767 for ; Wed, 18 Jul 2001 02:56:29 -0700 (PDT) Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA27089 for ; Wed, 18 Jul 2001 02:56:28 -0700 (PDT) Received: from Gioconda (c40.local.ipunplugged.com [192.168.4.239]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with ESMTP id LAA29116 for ; Wed, 18 Jul 2001 11:58:15 +0200 From: "Henrik Levkowetz" To: Subject: RE: [mobile-ip] draft-vaarala-mobileip-nat-traversal-00.txt -- NAT traversal using the Mobile IP port Date: Wed, 18 Jul 2001 11:56:23 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <001701c10f5d$85b7b970$3f02a8c0@garibaldi> Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 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 Sami, Yes, I see that the scheme is well-thought out. I hadn't fully appreciated the benefits of both sides indicating which MIP message type they are willing to receive as a data tunnelling marker. To me, it appears as if your scheme will work, too, and will not interfere with other traffic, or cause trouble, except for e.g. tcpdump :-). (I still don't really like the approach of using unallocated message types, though, but now we are down to the esoterics of estethics in software design...) There's also the factor of complexity vs. simplicity - your scheme in itself is not very complex, but simpler would be better. Having a standardised MIP message type for this use would be simpler. There is one implementation aspect to this which we haven't touched on, where I believe our solution is slightly simpler/better than yours, which is the following: Using other ports than 434, we don't have to multiplex MIP control and data, so detunneling can be implemented as a pure kernel activity, while in your case, the packets would have to be looked at by the mip daemon or equivalent, to separate the control and data streams. This drawback would exist equally for a standardised solution using port 434 and a standardised MIP message type, too. Alternatively, one could standardise a separate port for MIP UDP tunnelling. As I indicated earlier, I'd intended to submit a draft for a non-vendor-specific UDP tunneling extension to MIPv4, would you be interested in co-authoring such a draft? It seems as if we wouldn't have trouble coming up with two independent implementations of such a draft, to take it towards standard :-) ? On the volume of comments: Yes... the thought has passed my mind, _are_ people deploying MIP at all? Or is it that the deployments being done are only in the US by holders of large blocks of public IPv4 addresses? Best regards, Henrik Sami Vaarala wrote: > > Henrik, > > (Long posting, sorry...) > > > On the dynamically assigned message type: > > > > Although we have chosen not to use such to tunnel trough 434, I to > > some extent agree with what you write on this, however: If you deploy a > > number of HA's & clients worldwide, using this solution, and some of > > the MIP message numbers which are now unassigned become assigned for > > standardised messages, you are in a situation where all of your HA's > > and clients will need to be reconfigured to not use those message > > numbers -- and if your company is successful in selling this solution, > > that could be a lot of HA's and clients! There's always a chance then, > > that some customer would miss or ignore the reconfiguration. > > We seem to disagree on this point, and I'll try to break down the issue > to see where exactly we disagree. Basically I am trying to convince you > that no reconfiguration is necessary -- unless a software update is done > to add support for new message types anyway. > > 1. I have assumed that it is okay to diverge into a non-conformant > mode if support for the traversal feature is mutually established in an > authenticated manner. > > 2. Both the mobile node and the home agent can independently > determine which mobile IP message type(s) they are willing to reserve > for tunnelling purposes. If the node supports an IANA assigned > message type X, it MUST NOT indicate that such a number would be > acceptable for traversal purposes. Both the MN and the HA > independently define which message type(s) they are willing to > accept when _receiving_ tunnelled packets, so difference of implemented > message types is not a problem. > > 3. Only the MN and the HA need to understand these packets. There > are no third party conflicts, unless you consider hosts such as network > sniffers as such. (True, it would be irritating to see network packets > incorrectly dumped, but I don't consider this a major problem :) > > 4. Now, suppose that MN and HA are both supporting the traversal mechanism > AND that they are independently administrated. Supposed now that a new > IANA message type X is defined, and the HA (but not the MN) is upgraded to > support the message type. > > 4a. After the software update the HA would no longer indicate that message > type X would be valid for traversal. Thus MN->HA traffic would cause no > conflicts, even if MN is not updated (since MN will obey the traversal > requirements indicated by the HA). > > 4b. HA->MN traffic would also work. If MN would happen to indicate that X > is used as a traversal marker, the HA would determine that MN _does not_ > support X anyway, and would refrain from sending the actual message type X > to the MN (since it would never process it anyway). > > Should the HA send X to MN prior to establishing a traversal binding, the > MN would respond normally, as if an unsupported message type was received. > > 5. MN upgraded, HA not -> similar to case 4. > > 6. One host is upgraded and rebooted while an existing binding is still > valid. This causes a small period of time during which the other host > may be sending traversal processed packets that might conflict with the > rebooted host. However, by using short lifetimes for traversal bindings > (eg one minute), this would be a minor concern. > > ---- > > The point I am trying to make is that message type changes require a > _software update_ anyway, and the software can be updated at the same time > to not use conflicting traversal markers. > > Point 4b) will have to be elaborated in the draft, since it is important > with regards to software upgrades. The described approach is not very > clean since it interacts with the rest of the Mobile IP implementation. > Any ideas on how to make it cleaner? > > > > I don't think you should assume that only your own clients will be used > > with your HA's, or only your own HA's will be used to support your > > clients -- and if other vendors' products with new message types were to > > conflict with your tunneling solution because a reconfiguration had > > been missed, it would be quite unfortunate. > > I don't see how this could happen? The following cases arise: > > 1. Neither supports the draft -- no problem here. > > 2. MN supports, HA doesn't -- NVSE ignored. > > 3. MN does not support, HA does -- NVSE not sent, no problem. > > 4. Both support, but disagree on which message types are okay for > traversal -- no problem, since traversal for each direction is > negotiated separately. > > Have I missed something here that you are concerned about? > > > In theory, you should still never get a conflict if you take care to > > treat these message types as tunneling only after negotiation, and > > as unrecognised messages otherwise, but it's balancing a little too > > close to the edge for my liking... :-) > > (Remember Murphy.) > > There are conflicts if one assumes that messages before and after > establishing a traversal binding are confused, that is true. > However, one could also argue that the MN might confuse GRE tunneling > with minimal encapsulation, or co-located address with using an FA. > Is there a fundamental difference between these different types of > confusion? > > Since the traversal parameters and state are a part of the binding > state, which has to be carefully maintained anyway, I don't see a > problem with the confusion -- the traversal state would be bound to > the same data structures as eg. GRE vs. minimal encapsulation mode. > > > It would also be unfortunate if the IANA felt that due to the existence > > in the marketplace of a solution which had subsumed the use of message > > types 0x45..0x4f, those could not be used for new Mobile IP messages > > types, and had to be barred. > > I agree. This is why I think that both hosts should indicate which > marker octets they are willing to use for optimized traversal as well, > ie by indicating the range or the individual octets supported. > > Of course, it would be best if there was a consensus that MIPv4 NAT > traversal is important, and marker octets were assigned by IANA; then > there would be no possibility for confusion, and no need for > negotiation of markers. > > > On TCP-based traversal: > > > > I think that there would be added complexity and overhead, without > > proportionately added benefit. If the protocol being carried in the > > tunnel also was TCP, I think you might get complex interactions > > between the two levels of TCP timers, resends and whatnot? > > We chose to go with UDP because IP-in-UDP behaviour is very close > > to IP-in-IP or bare IP. I'm sure you have made the same reflexions. > > I agree completely; the advantages do not seem to be worth the > hassle. UDP tunnelling can be thought of as a new kind of mobility > binding, while TCP tunnelling requires much larger changes to the > protocol model. > > > On standardised NAT-traversal: > > > > Yes. And I'm slightly surprised at the scarcity of comments, so far. > > Of course, this subject isn't as sexy as MIPv6 or Fast Handover :-) > > It is amazing though, because NAT traversal is a _major_ deployment > requirement. Does this indicate that people are not deploying? ;-) > > Best regards, > -Sami > > -- > Sami Vaarala > Senior Software Architect > NetSeal Technologies > From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 18 06:34:49 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA20845 for ; Wed, 18 Jul 2001 06:34:49 -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 DAA00638; Wed, 18 Jul 2001 03:35:19 -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 DAA26126; Wed, 18 Jul 2001 03:35:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6IAXo326550 for mobile-ip-dist; Wed, 18 Jul 2001 03:33:50 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6IAXlN26543 for ; Wed, 18 Jul 2001 03:33:47 -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 DAA08065 for ; Wed, 18 Jul 2001 03:33:58 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA24867 for ; Wed, 18 Jul 2001 04:33:56 -0600 (MDT) 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 f6IAY8k09433 for ; Wed, 18 Jul 2001 03:34:08 -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 AAB20031; Wed, 18 Jul 2001 03:33:57 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id DAA08444; Wed, 18 Jul 2001 03:33:57 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15189.26132.851712.288182@thomasm-u1.cisco.com> Date: Wed, 18 Jul 2001 03:33:56 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Dynamic Home Agent Address Discovery mechanism In-Reply-To: <7B5C0390ACE7D211BC9C0008C7EABA2B041F8839@daeis07nok> References: <7B5C0390ACE7D211BC9C0008C7EABA2B041F8839@daeis07nok> 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 Franck.Le@nokia.com writes: > * the home agents could require the ICMP Home Agent Address Discovery > Request message to be authenticated and they will only reply to valid > requests. Requests that do not pass authentication could be silently > dropped. (or an error message be sent back, but without the source address > being that of a valid home agent) What is the advantage to early authentication? There would be a lot of work to create a self-authenticating Discovery Request for little gain that I can see. It seems like it would be a whole lot simpler to let the HA reply to any discovery request, but require strong authentication for its use as a home agent. (ie, discover/authenticate/BU/use). > * The Home Agent Discovery reply message could be authenticated, and whereas > the currently specified ICMP Home Agent Address Discovery Reply message > contains one or a list of the global unicast IP address of home agent > operating on the home link; this information could be encrypted. Again, what is the advantage? BU's are not encrypted, so you're going to disclose your choice once you select an HA, right? > * Finally the source IP address of the response packet sent to the > originator SHOULD NOT be that of a Home Agent but some virtual address. Virtual in what way? Something that might fail an RPF check? Mike From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 18 06:35:52 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA21081 for ; Wed, 18 Jul 2001 06:35:52 -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 DAA01020; Wed, 18 Jul 2001 03:36: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 DAA26191; Wed, 18 Jul 2001 03:35:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6IAYYH26568 for mobile-ip-dist; Wed, 18 Jul 2001 03:34:34 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6IAYUN26561 for ; Wed, 18 Jul 2001 03:34:30 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA07769 for ; Wed, 18 Jul 2001 03:34:41 -0700 (PDT) Received: from ns2.iaf.fi (ns2.iaf.fi [195.94.103.2]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA08056 for ; Wed, 18 Jul 2001 03:34:40 -0700 (PDT) Received: from proxyfw.netseal.com (gw.netseal.com [195.94.100.110]) by ns2.iaf.fi (8.11.2/8.11.2) with ESMTP id f6IAU6x11210 for ; Wed, 18 Jul 2001 13:30:06 +0300 Received: from (Undisclosed Firewall protected host) by Baudia Firewall with SMTP id MAA01199 for ; Wed, 18 Jul 2001 12:53:35 +0300] Message-ID: <007801c10f75$a4c97160$3f02a8c0@garibaldi> From: "Sami Vaarala" To: References: Subject: Re: [mobile-ip] draft-vaarala-mobileip-nat-traversal-00.txt -- NAT traversal using the Mobile IP port Date: Wed, 18 Jul 2001 13:37:29 +0300 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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Henrik, From: "Henrik Levkowetz" > There's also the factor of complexity vs. simplicity - your > scheme in itself is not very complex, but simpler would be better. Having > a standardised MIP message type for this use would be simpler. True; or a range of standard MIP message types to avoid overhead. I don't know how you feel about it, but in my opinion the single octet overhead is quite annoying. Breaking the four-octet alignment that naturally would exist might be a pain in some processors that naturally process aligned data. Adding overhead to four octets would help that issue but seems like much extra for little gain. (Incidentally, IPsec NAT traversal requires either 8 or 12 bytes overhead for markers.) > There is one implementation aspect to this which we haven't touched > on, where I believe our solution is slightly simpler/better than yours, > which is the following: Using other ports than 434, we don't have to > multiplex MIP control and data, so detunneling can be implemented as a > pure kernel activity, while in your case, the packets would have to be > looked at by the mip daemon or equivalent, to separate the control and > data streams. This drawback would exist equally for a standardised > solution using port 434 and a standardised MIP message type, too. I agree with this. Our Mobile IP implementation is kernel-based so there is no such problem, but I agree, this would limit implementation options and cause problems with some existing ones. A standard Mobile IP message type (or range) would allow the kernel part to automatically demux traffic, and would not need any configurable parameters as is the case with a negotiable traversal. > Alternatively, one could standardise a separate port for MIP UDP tunnelling. Yes. We need rough consensus on at least the following issues to start things moving: 1. Do we allocate a separate port? If so, what will we do if 434 is allowed but the port in question is not (universal deployment does not happen overnight) -- do we still need a port negotiation? 2. If we go for tunnelling through port 434, do we use a set of markers and optimize overhead, or use a single marker to separate traffic. Is it realistic for IANA to allocate a range of numbers for this application? Or a range for numbers for private use among consenting parties (and a standardized extension for traversal negotiation). I think we should have discussion over this at IETF 51 to get things forward. > As I indicated earlier, I'd intended to submit a draft for a > non-vendor-specific UDP tunneling extension to MIPv4, would you be > interested in co-authoring such a draft? It seems as if we wouldn't have > trouble coming up with two independent implementations of such a draft, > to take it towards standard :-) ? Yes, that sounds good, we would be interested in implementing such a proposal. Of course, we will have to reach some consensus on how to go forward with the various approaches. Best regards, -Sami Sami Vaarala Senior Software Architect NetSeal Technologies From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 18 07:02:29 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA27307 for ; Wed, 18 Jul 2001 07:02:28 -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 FAA07600; Wed, 18 Jul 2001 05:02: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 EAA28289; Wed, 18 Jul 2001 04:02:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6IB0Z926757 for mobile-ip-dist; Wed, 18 Jul 2001 04:00:35 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6IB0TN26750 for ; Wed, 18 Jul 2001 04:00:29 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA09922 for ; Wed, 18 Jul 2001 04:00:40 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA15825 for ; Wed, 18 Jul 2001 04:00:39 -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 GAA25727; Wed, 18 Jul 2001 06:59:45 -0400 (EDT) Message-Id: <200107181059.GAA25727@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-ernst-mobileip-monetv6-00.txt Date: Wed, 18 Jul 2001 06:59:44 -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. Title : Network Mobility Support in IPv6:Problem Statement and Requirements Author(s) : T. Ernst et al. Filename : draft-ernst-mobileip-monetv6-00.txt Pages : 20 Date : 17-Jul-01 This draft addresses the problems of routing datagrams to nodes located in an IPv6 mobile network. A mobile network is one or more IP-subnets attached to a mobile router and mobile as a unit. The mobile router dynamically changes its point of attachment. Applications of mobile networks include networks attached to people (PANs) and networks of sensors deployed in an aircraft, a boat, or a car. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ernst-mobileip-monetv6-00.txt 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-ernst-mobileip-monetv6-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-ernst-mobileip-monetv6-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: <20010717133304.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ernst-mobileip-monetv6-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ernst-mobileip-monetv6-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010717133304.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 18 07:40:45 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA04328 for ; Wed, 18 Jul 2001 07:40:45 -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 FAA23559; Wed, 18 Jul 2001 05:41:18 -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 EAA00853; Wed, 18 Jul 2001 04:41:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6IBdxa26916 for mobile-ip-dist; Wed, 18 Jul 2001 04:39:59 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6IBdtN26909 for ; Wed, 18 Jul 2001 04:39:55 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA28911 for ; Wed, 18 Jul 2001 04:40:07 -0700 (PDT) Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA28745 for ; Wed, 18 Jul 2001 04:40:05 -0700 (PDT) Received: from Gioconda (c2.local.ipunplugged.com [192.168.4.201]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with ESMTP id NAA30606 for ; Wed, 18 Jul 2001 13:41:53 +0200 From: "Henrik Levkowetz" To: Subject: RE: [mobile-ip] draft-vaarala-mobileip-nat-traversal-00.txt -- NAT traversal using the Mobile IP port Date: Wed, 18 Jul 2001 13:40: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: <007801c10f75$a4c97160$3f02a8c0@garibaldi> Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 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 Sami, Sami wrote: > > Henrik, > > From: "Henrik Levkowetz" > > There's also the factor of complexity vs. simplicity - your > > scheme in itself is not very complex, but simpler would be better. Having > > a standardised MIP message type for this use would be simpler. > > True; or a range of standard MIP message types to avoid overhead. > I don't know how you feel about it, but in my opinion the single octet > overhead is quite annoying. Breaking the four-octet alignment that > naturally would exist might be a pain in some processors that > naturally process aligned data. Adding overhead to four octets > would help that issue but seems like much extra for little gain. > (Incidentally, IPsec NAT traversal requires either 8 or 12 bytes > overhead for markers.) Althought maybe not the absolutely most optimal solution, I'd be most happy with a standardised message type, starting with one-octet type and length, and then a reserved two-octet field, to make 4 octets. The overhead is not that horrendous, I think. Just type and length, for a 16-bit alignment would be fairly ok, too. > > > There is one implementation aspect to this which we haven't touched > > on, where I believe our solution is slightly simpler/better than yours, > > which is the following: Using other ports than 434, we don't have to > > multiplex MIP control and data, so detunneling can be implemented as a > > pure kernel activity, while in your case, the packets would have to be > > looked at by the mip daemon or equivalent, to separate the control and > > data streams. This drawback would exist equally for a standardised > > solution using port 434 and a standardised MIP message type, too. > > I agree with this. Our Mobile IP implementation is kernel-based so there > is no such problem, but I agree, this would limit implementation options > and cause problems with some existing ones. A standard Mobile IP message > type (or range) would allow the kernel part to automatically demux > traffic, and would not need any configurable parameters as is the case > with a negotiable traversal. > > > Alternatively, one could standardise a separate port for MIP UDP > tunnelling. > > Yes. We need rough consensus on at least the following issues to start > things moving: > 1. Do we allocate a separate port? If so, what will we do if 434 is > allowed but the port in question is not (universal deployment does > not happen overnight) -- do we still need a port negotiation? For a general solution, my thinking at this moment is to go for primarily a separate port, with fallback to 434 with a new message type permitted. > > 2. If we go for tunnelling through port 434, do we use a set of > markers and optimize overhead, or use a single marker to separate > traffic. Is it realistic for IANA to allocate a range of numbers > for this application? Or a range for numbers for private use > among consenting parties (and a standardized extension for > traversal negotiation). I'd think that IANA would want to conserve their resources, so to speak, and allocate one message type for tunnelling. This would be Ok for us, too. > > I think we should have discussion over this at IETF 51 to get things > forward. Yes, absolutely. I'll be there the whole week, we definitely should get together. > > > As I indicated earlier, I'd intended to submit a draft for a > > non-vendor-specific UDP tunneling extension to MIPv4, would you be > > interested in co-authoring such a draft? It seems as if we wouldn't have > > trouble coming up with two independent implementations of such a draft, > > to take it towards standard :-) ? > > Yes, that sounds good, we would be interested in implementing such a > proposal. Of course, we will have to reach some consensus on how to > go forward with the various approaches. Certainly. Best, Henrik > > Best regards, > -Sami > > Sami Vaarala > Senior Software Architect > NetSeal Technologies > From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 18 08:21:41 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA10236 for ; Wed, 18 Jul 2001 08:21:41 -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 FAA25715; Wed, 18 Jul 2001 05:21:46 -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 FAA15142; Wed, 18 Jul 2001 05:21:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6ICK8427010 for mobile-ip-dist; Wed, 18 Jul 2001 05:20:08 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6ICK4N27003 for ; Wed, 18 Jul 2001 05:20:04 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA15635 for ; Wed, 18 Jul 2001 05:20:16 -0700 (PDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA14988 for ; Wed, 18 Jul 2001 05:20:15 -0700 (PDT) Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f6ICKEO00659 for ; Wed, 18 Jul 2001 14:20:14 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Wed Jul 18 14:19:50 2001 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 18 Jul 2001 14:13:51 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008B07@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] proposed agenda Date: Wed, 18 Jul 2001 14:19:45 +0200 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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi, > v6 Fast Handover draft-ietf-mobileip-fast-mipv6-01.txt > BETH addition? James 10 minutes draft-kempf-beth-ipv6-01.txt > Implementation experience report Rajeev Koodli 10 minutes > => I'd be really interested to know if you have an implementation of the Fast Handoff draft. Rajeev ? Would you be able to give some information on the platform used or (if open source) whether it could be downloaded from somewhere ? Thanks, Hesham From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 18 09:07:24 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA17526 for ; Wed, 18 Jul 2001 09:07:23 -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 HAA06409; Wed, 18 Jul 2001 07:07:38 -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 GAA19279; Wed, 18 Jul 2001 06:07:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6ID5aV27123 for mobile-ip-dist; Wed, 18 Jul 2001 06:05:36 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6ID5WN27116 for ; Wed, 18 Jul 2001 06:05:32 -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 GAA19442 for ; Wed, 18 Jul 2001 06:05:45 -0700 (PDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA15112 for ; Wed, 18 Jul 2001 07:07:00 -0600 (MDT) Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f6ID5gO28282 for ; Wed, 18 Jul 2001 15:05:42 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Wed Jul 18 15:05:33 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Wed, 18 Jul 2001 15:05:36 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008B0A@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Question on draft-team-mobileip-mipv6-sec-reqts-0 0.txt Date: Wed, 18 Jul 2001 15:05:28 +0200 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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > > > True. But is a legitimate MN even monitoring for such data on the > > wireless links? Probably not. > > Why wouldn't a legitimate MN monitor the wireless link? > => Either to save power (on a shared media) or because it can't (on a point to point type link). cards are not normally set to promiscous mode by deault. Hesham From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 18 09:51:10 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA26267 for ; Wed, 18 Jul 2001 09:51:10 -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 GAA25181; Wed, 18 Jul 2001 06:51:33 -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 GAA23850; Wed, 18 Jul 2001 06:51:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6IDn7q27246 for mobile-ip-dist; Wed, 18 Jul 2001 06:49:07 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6IDn2N27239 for ; Wed, 18 Jul 2001 06:49:03 -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 GAA23697 for ; Wed, 18 Jul 2001 06:49:15 -0700 (PDT) Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA06739 for ; Wed, 18 Jul 2001 07:50:33 -0600 (MDT) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate4.mot.com (motgate4 2.1) with ESMTP id GAA23708 for ; Wed, 18 Jul 2001 06:49:13 -0700 (MST)] Received: [from m-il06-r2.mot.com (m-il06-r2.mot.com [129.188.137.24]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id GAA23904 for ; Wed, 18 Jul 2001 06:49:13 -0700 (MST)] Received: from [140.101.173.9] by m-il06-r2.mot.com with ESMTP for mobile-ip@sunroof.eng.sun.com; Wed, 18 Jul 2001 08:49:07 -0500 Received: (from root@localhost) by zorglub.crm.mot.com (8.8.8/8.8.8/crm-1.6) id PAA28599 for mobile-ip@sunroof.eng.sun.com.DELIVER; Wed, 18 Jul 2001 15:49:06 +0200 (METDST) Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by zorglub.crm.mot.com (8.8.8/8.8.8/crm-1.6) with ESMTP id PAA28542 for ; Wed, 18 Jul 2001 15:49:05 +0200 (METDST) To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Question on draft-team-mobileip-mipv6-sec-reqts-0 0.txt References: <034BEFD03799D411A59F00508BDF754603008B0A@esealnt448.al.sw.ericsson.se> From: Alexandru Petrescu Date: 18 Jul 2001 15:49:03 +0200 In-Reply-To: <034BEFD03799D411A59F00508BDF754603008B0A@esealnt448.al.sw.ericsson.se> Message-Id: Lines: 24 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.0.103 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: "Hesham Soliman (ERA)" writes: > > Why wouldn't a legitimate MN monitor the wireless link? > > > => Either to save power (on a shared media) or because > it can't (on a point to point type link). cards are not normally set > to promiscous mode by deault. I can't argue regarding the "save power" argument. I can argue about the "point to point" argument. If you mention point-to-point as a reason for the impossiblity of MN to listen to broadcast messages then the same reason goes for the impossiblity of attacker to listen to the same traffic, and thus it's impossible for attacker to find the legitimate's MN HoA and forge a BU. What are the precise point to point links you refer to? Are many other wireless media accesses of type point to point? Just wondering, please enlighten. Also, monitoring the media is already specified as a potential means to assist in handovers (draft-mobileip). So why not monitoring the media in order to enhance security? Alex From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 18 09:56:49 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA27728 for ; Wed, 18 Jul 2001 09:56:48 -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 GAA27518; Wed, 18 Jul 2001 06:57: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 GAA11397; Wed, 18 Jul 2001 06:57:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6IDtw827304 for mobile-ip-dist; Wed, 18 Jul 2001 06:55:58 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6IDtsN27297 for ; Wed, 18 Jul 2001 06:55:54 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA24483 for ; Wed, 18 Jul 2001 06:56:07 -0700 (PDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA27438 for ; Wed, 18 Jul 2001 06:56:06 -0700 (PDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f6IDu5N08999 for ; Wed, 18 Jul 2001 15:56:05 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Wed Jul 18 15:56:04 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Wed, 18 Jul 2001 15:56:03 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008B0E@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Question on draft-team-mobileip-mipv6-sec-reqts-0 0.txt Date: Wed, 18 Jul 2001 15:55:56 +0200 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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > "Hesham Soliman (ERA)" writes: > > > Why wouldn't a legitimate MN monitor the wireless link? > > > > > => Either to save power (on a shared media) or because > > it can't (on a point to point type link). cards are not normally set > > to promiscous mode by deault. > > I can't argue regarding the "save power" argument. > > I can argue about the "point to point" argument. If you mention > point-to-point as a reason for the impossiblity of MN to listen to > broadcast messages then the same reason goes for the impossiblity of > attacker to listen to the same traffic, and thus it's impossible for > attacker to find the legitimate's MN HoA and forge a BU. > => MITM does not have to be on the same link ..right ? > What are the precise point to point links you refer to? Are many > other wireless media accesses of type point to point? Just wondering, > please enlighten. > => Cellular links for example. > Also, monitoring the media is already specified as a potential means > to assist in handovers (draft-mobileip). So why not monitoring the > media in order to enhance security? > => I don't know which draft you refer to, but if you're referring to the movement detection part of the MIPv6 spec then that is only relevant to shared media like WLAN environments. Hesham From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 18 10:47:33 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08892 for ; Wed, 18 Jul 2001 10:47:33 -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 IAA16771; Wed, 18 Jul 2001 08: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 HAA06567; Wed, 18 Jul 2001 07:47:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6IEjp127416 for mobile-ip-dist; Wed, 18 Jul 2001 07:45:51 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6IEjmN27409 for ; Wed, 18 Jul 2001 07:45: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 HAA18463 for ; Wed, 18 Jul 2001 07:45:59 -0700 (PDT) Received: from zcars0m9.ca.nortel.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA10314 for ; Wed, 18 Jul 2001 08:47:06 -0600 (MDT) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f6IEjP910747 for ; Wed, 18 Jul 2001 10:45:25 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Wed, 18 Jul 2001 10:45:12 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <3HJ27HG9>; Wed, 18 Jul 2001 10:45:15 -0400 Message-ID: From: "Hongyi Li" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] proposed agenda Date: Wed, 18 Jul 2001 10:45:12 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10F98.40163F50" X-Orig: 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_01C10F98.40163F50 Content-Type: text/plain; charset="iso-8859-1" Hi, I submitted a LMM framework draft to MIP group last week. As I am not going to attend the London meeting, I would to like to have some discussions / feedback about the draft on the mailing list. Here it the link to the draft: http://www.ietf.org/internet-drafts/draft-li-mobileip-lmm-framework-00.txt Regards Hongyi > -----Original Message----- > From: Phil Roberts [mailto:PRoberts@MEGISTO.com] > Sent: Tuesday, July 17, 2001 2:35 PM > To: 'mobile-ip@sunroof.eng.sun.com' > Subject: [mobile-ip] proposed agenda > > > > Hi folks, > > here's a new version of the agenda. Although the history > of the working > group has been > to allow presentations of as many drafts as possible, this meeting > represents a departure > from tradition. Essentially we're going to use the time only > for discussing > those things > which seem to indicate a need for face-to-face discussion > time. We would > prefer to discuss > and resolve most of the working group issues on the mailing > list. If you > believe there > is an issue that needs to be discussed that is not covered by > the agenda, > please post to > the mailing list describing what it is and why. If you have > a draft with an > interesting > idea that the working group should consider for standardization or > documentation, please > attempt to generate a discussion on the mailing list. > > Phil and Raj > > Agenda Phil 5 minutes > Update on WG docs Phil 10 minutes > > This slot is for last minute updates. Here is the current > status of docs > that are in last call or submitted to Abha. > > draft-ietf-mobileip-mier-07.txt (submitted) > draft-ietf-mobileip-gnaie-04.txt (submitted) > draft-ietf-mobileip-3g wireless-ext-06.txt (being updated > based on IESG > feedback) > draft-ietf-mobileip-rfc2002-bis-06.txt (being updated based on IESG > feedback) > draft-ietf-mobileip-gen-key-00.txt (wg last call expires > Friday 7/20 > hopefully submitted) > draft-ietf-mobileip-aaa-key-07.txt (to be submitted Friday 7/20) > draft-ietf-mobileip-qos-requirements-00.txt (wg last call > expires 7/25) > draft-ietf-mobileip-reg-tunnel-04.txt (being updated) > draft-ietf-mobileip-optim-10.txt (past wg last call, > sitting on it until > MIP v6 > issues resolved) > > Moving MIPv4 to draft standard Charlie 10 minutes > > Mobile IP v6 security update ? > draft-team-mobileip-mipv6-sec-reqts-00.txt > 15 minutes > Mobile IP v6 other changes in -14 Charlie 5 minutes > draft-ietf-mobileip-ipv6-14.txt > > v4 Low Latency Handover Karim 5 minutes > draft-ietf-mobileip-lowlatency-handoffs-v4-01.txt > Is there anyone who can share implementation experiences? > Is this doc ready for last call? > > v6 Fast Handover draft-ietf-mobileip-fast-mipv6-01.txt > BETH addition? James 10 minutes draft-kempf-beth-ipv6-01.txt > Implementation experience report Rajeev Koodli 10 minutes > > Mobile Network Support Thierry Ernst 15 minutes > Mobile IP Component Redundancy Gopal 10 minutes > > LMM Requirements Carl Williams 15 minutes > (draft-ietf-mobileip-lmm-requirements-00.txt) > > Issues from the list Raj 15 minutes > > > > > > > > > > > > > > > > ------_=_NextPart_001_01C10F98.40163F50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] proposed agenda

Hi,
  I submitted a LMM framework draft to MIP = group last week. As
I am not going to attend the London meeting, I would = to like to
have some discussions / feedback about the draft on = the mailing
list.

Here it the link to the draft:
http://www.ietf.org/internet-drafts/draft-li-mobileip-= lmm-framework-00.txt

Regards

Hongyi



 

> -----Original Message-----
> From: Phil Roberts [mailto:PRoberts@MEGISTO.com]
> Sent: Tuesday, July 17, 2001 2:35 PM
> To: 'mobile-ip@sunroof.eng.sun.com'
> Subject: [mobile-ip] proposed agenda
>
>
>
> Hi folks,
>
>    here's a new version of the = agenda.  Although the history
> of the working
> group has been
> to allow presentations of as many drafts as = possible, this meeting
> represents a departure
> from tradition.  Essentially we're going = to use the time only
> for discussing
> those things
> which seem to indicate a need for face-to-face = discussion
> time.  We would
> prefer to discuss
> and resolve most of the working group issues on = the mailing
> list.  If you
> believe there
> is an issue that needs to be discussed that is = not covered by
> the agenda,
> please post to
> the mailing list describing what it is and = why.  If you have
> a draft with an
> interesting
> idea that the working group should consider for = standardization or
> documentation, please
> attempt to generate a discussion on the mailing = list.
>
> Phil and Raj
>
> Agenda   Phil   5 = minutes
> Update on WG docs  Phil 10 minutes
>
>    This slot is for last minute = updates.  Here is the current
> status of docs
>    that are in last call or = submitted to Abha.
>
>    = draft-ietf-mobileip-mier-07.txt (submitted)
>    = draft-ietf-mobileip-gnaie-04.txt (submitted)
>    draft-ietf-mobileip-3g = wireless-ext-06.txt (being updated
> based on IESG
> feedback)
>    = draft-ietf-mobileip-rfc2002-bis-06.txt (being updated based on = IESG
> feedback)
>    = draft-ietf-mobileip-gen-key-00.txt (wg last call expires
> Friday 7/20
> hopefully submitted)
>    = draft-ietf-mobileip-aaa-key-07.txt (to be submitted Friday 7/20)
>    = draft-ietf-mobileip-qos-requirements-00.txt (wg last call
> expires 7/25)
>    = draft-ietf-mobileip-reg-tunnel-04.txt (being updated)
>    = draft-ietf-mobileip-optim-10.txt (past wg last call,
> sitting on it until
> MIP v6
>          = issues resolved)
>
> Moving MIPv4 to draft standard  = Charlie  10 minutes
>
> Mobile IP v6 security update  ?
> = draft-team-mobileip-mipv6-sec-reqts-00.txt
> 15 minutes
> Mobile IP v6 other changes in -14 Charlie 5 = minutes
> draft-ietf-mobileip-ipv6-14.txt
>
> v4 Low Latency Handover Karim  5 = minutes
> = draft-ietf-mobileip-lowlatency-handoffs-v4-01.txt
>    Is there anyone who can share = implementation experiences?
>    Is this doc ready for last = call?
>
> v6 Fast Handover = draft-ietf-mobileip-fast-mipv6-01.txt
>    BETH addition? James 10 = minutes draft-kempf-beth-ipv6-01.txt
>    Implementation experience = report Rajeev Koodli 10 minutes
>
> Mobile Network Support Thierry Ernst 15 = minutes
> Mobile IP Component Redundancy Gopal 10 = minutes
>
> LMM Requirements Carl Williams 15 = minutes
> = (draft-ietf-mobileip-lmm-requirements-00.txt)
>
> Issues from the list Raj 15 minutes
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>

------_=_NextPart_001_01C10F98.40163F50-- From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 18 11:58:51 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA28917 for ; Wed, 18 Jul 2001 11:58:50 -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 IAA23229; Wed, 18 Jul 2001 08:59: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 IAA06315; Wed, 18 Jul 2001 08:59:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6IFvs227561 for mobile-ip-dist; Wed, 18 Jul 2001 08:57:54 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6IFvoN27554 for ; Wed, 18 Jul 2001 08:57:51 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA25819 for ; Wed, 18 Jul 2001 08:58:03 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA09976 for ; Wed, 18 Jul 2001 08:58:02 -0700 (PDT) Received: from mchandra-u10.cisco.com (mchandra-u10.cisco.com [64.102.66.20]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f6IFw6625356 for ; Wed, 18 Jul 2001 08:58:06 -0700 (PDT) Received: (mchandra@localhost) by mchandra-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA00700 for mobile-ip@sunroof.eng.sun.com; Wed, 18 Jul 2001 11:57:52 -0400 (EDT) Date: Wed, 18 Jul 2001 11:57:52 -0400 From: "Madhavi W. Chandra" To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Re: mobile-ip] WG last call: draft-ietf-mobileip-gen-key-00.txt Message-ID: <20010718115752.A689@cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from PRoberts@MEGISTO.com on Fri, Jul 06, 2001 at 01:55:02PM -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: Hi Charlie and Pat, We've just started following this draft and are trying to grasp its intent. We have a few questions/comments: 1. Since it is not specified, can the 'Reply' Key extensions be appended to both RPYs and RRQs? 2. Section 7, 'FA-FA Key Reply Subtype Data' sounds like a description for MN-HA Reply. 3. Are the 'Reply' Key extensions in Sections 6 and 7 sent unsolicited by a mobility agent (MA)? Actually, who is sending these extensions and how do they even know to send these extension? Also, in what MIP messages are these being sent? Please explain this a bit. 4. Can the 'Reply' Key extensions in Sections 3 and 5 be sent unsolicited to the MN...meaning, not in response to a 'Request' Key extension. 5. Curious...why separate Types for each message? Why not Type = Key Distribution message, Subtype = MN-HA, MN-FA, FA-HA, etc First byte of Subtype = serve purpose of current Subtype? 6. When MN sends 'MN-HA Key Request' extension in RRQ, does it append MN-AAA AE since no MHAE? So, AAA is doing proxy authentication of MN for the HA? Then, HA sends RPY with 'MN-HA Key Reply' extension...what AE is used to secure the RPY? 7. We would like a mobility agent, say MA-1, to pass key to MA-2 for MA-2 to use with MN. If MAs are FAs, then probably the FA-FA Key Reply Extension would be used...appended to what MIP message? What if the MAs are HAs? 8. Section on user scenarios would be helpful...mention that the AAA Registration Keys draft is an instantiation of this draft. A simple user scenario would illustrate the intent of the draft. Thanks, Madhavi On Fri, Jul 06, 2001 at 01:55:02PM -0400, Phil Roberts wrote: > > This is a Mobile IP WG last call for the I-D > draft-ietf-mobileip-gen-key-00.txt > Generalized Key Extensions for Mobile IP. This draft will be sent to the > IESG > requesting a proposed standard status to be associated with it at the end of > the last call period. Please send your comments to the WG discussion list. > > WG Last call issued on : Jul 5, 2001 > Expires on : Jun 20, 2001 > > Basavaraj Patil > Phil Roberts From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 18 12:29:41 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA06586 for ; Wed, 18 Jul 2001 12:29:40 -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 JAA08719; Wed, 18 Jul 2001 09:30:13 -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 JAA03045; Wed, 18 Jul 2001 09:29:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6IGSZj27680 for mobile-ip-dist; Wed, 18 Jul 2001 09:28:35 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6IGSUN27673 for ; Wed, 18 Jul 2001 09:28:30 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA02873 for ; Wed, 18 Jul 2001 09:28:43 -0700 (PDT) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA26788 for ; Wed, 18 Jul 2001 09:28:42 -0700 (PDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id JAA00748 for ; Wed, 18 Jul 2001 09:28:33 -0700 (MST)] Received: [from m-il06-r1.mot.com (m-il06-r1.mot.com [129.188.137.193]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id JAA19137 for ; Wed, 18 Jul 2001 09:28:33 -0700 (MST)] Received: from [140.101.173.9] by m-il06-r1.mot.com with ESMTP for mobile-ip@sunroof.eng.sun.com; Wed, 18 Jul 2001 11:28:32 -0500 Received: (from root@localhost) by zorglub.crm.mot.com (8.8.8/8.8.8/crm-1.6) id SAA21197 for mobile-ip@sunroof.eng.sun.com.DELIVER; Wed, 18 Jul 2001 18:28:29 +0200 (METDST) Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by zorglub.crm.mot.com (8.8.8/8.8.8/crm-1.6) with ESMTP id SAA21167 for ; Wed, 18 Jul 2001 18:28:28 +0200 (METDST) To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Question on draft-team-mobileip-mipv6-sec-reqts-0 0.txt References: <034BEFD03799D411A59F00508BDF754603008B0E@esealnt448.al.sw.ericsson.se> From: Alexandru Petrescu Date: 18 Jul 2001 18:28:26 +0200 In-Reply-To: <034BEFD03799D411A59F00508BDF754603008B0E@esealnt448.al.sw.ericsson.se> Message-Id: Lines: 32 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.0.103 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: "Hesham Soliman (ERA)" writes: > => MITM does not have to be on the same link ..right ? Right, MITM attack could be launched from outside the MN's link. I was not referring to MITM in particular. I was mostly referring to threats B.x of Threat Model. The B.x threats all assume that the attacker can monitor traffic, so why wouldn't the MN itself monitor traffic. > > What are the precise point to point links you refer to? Are many > > other wireless media accesses of type point to point? Just > > wondering, please enlighten. > > > => Cellular links for example. So IP runs over all Cellular links in a point-to-point manner. Is there any proposal to run IP over a Cellular link more in a 802.3 MAC manner? > > Also, monitoring the media is already specified as a potential means > > to assist in handovers (draft-mobileip). So why not monitoring the > > media in order to enhance security? > > > => I don't know which draft you refer to, but if you're referring > to the movement detection part of the MIPv6 spec then > that is only relevant to shared media like WLAN environments. Yes, I was referring to that part, thank you for this clarification. But I was thinking that the Threat Model draft refers to that same MIPv6 spec and thus shared environments are addressed implicitely. Alex From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 18 12:49:35 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10736 for ; Wed, 18 Jul 2001 12:49:34 -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 JAA18573; Wed, 18 Jul 2001 09:49:51 -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 JAA08301; Wed, 18 Jul 2001 09:49:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6IGmLp27792 for mobile-ip-dist; Wed, 18 Jul 2001 09:48:21 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6IGmIN27785 for ; Wed, 18 Jul 2001 09:48:18 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA18652 for ; Wed, 18 Jul 2001 09:48:31 -0700 (PDT) From: Franck.Le@nokia.com Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA07640 for ; Wed, 18 Jul 2001 09:48:30 -0700 (PDT) Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f6IGmIi09228 for ; Wed, 18 Jul 2001 11:48:31 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Wed, 18 Jul 2001 11:48:16 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 18 Jul 2001 11:48:15 -0500 content-class: urn:content-classes:message Subject: RE: [mobile-ip] Dynamic Home Agent Address Discovery mechanism Date: Wed, 18 Jul 2001 11:48:15 -0500 Message-ID: <57A26D272F67A743952F6B4371B8F81108C1D5@daebe007.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 Thread-Topic: [mobile-ip] Dynamic Home Agent Address Discovery mechanism Thread-Index: AcEPdWiT834eSntnEdWJUgAIx6TWpQAMq5Qw To: X-OriginalArrivalTime: 18 Jul 2001 16:48:15.0987 (UTC) FILETIME=[70D34C30:01C10FA9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f6IGmIN27786 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: >From: ext Michael Thomas [mailto:mat@cisco.com] Content-Transfer-Encoding: 8bit >> * the home agents could require the ICMP Home Agent Address Discovery >> Request message to be authenticated and they will only reply to valid >> requests. Requests that do not pass authentication could be silently >> dropped. (or an error message be sent back, but without the source address >> being that of a valid home agent) > What is the advantage to early authentication? There > would be a lot of work to create a self-authenticating > Discovery Request for little gain that I can see. It > seems like it would be a whole lot simpler to let the > HA reply to any discovery request, but require strong > authentication for its use as a home agent. (ie, > discover/authenticate/BU/use). The reason for authenticating a Discovery request is to ensure that only valid MNs obtain the list of HAs serving a subnet or network. Obviously there are other ways that an attacker can learn about the HAs in a network, but this approach at least puts in some barriers to having information about HAs in a network being publicly available (via the ICMP discovery request). We believe that operators would like to some extent protect the identity of the HAs in their network. So the mechanism suggested helps such cases. If a network wants to be open, then yes you do not need to have the authentication of the discovery message. But as we mentioned, it's an option that needs to be supported in the spec. Of course the use of a router on a network as an HA definitely requires strong authentication in the BU. Is there any reason why the same authentication requirements be not available for the discovery message? >> * The Home Agent Discovery reply message could be authenticated, and whereas >> the currently specified ICMP Home Agent Address Discovery Reply message >> contains one or a list of the global unicast IP address of home agent >> operating on the home link; this information could be encrypted. > Again, what is the advantage? BU's are not encrypted, so > you're going to disclose your choice once you select an > HA, right? True. The BUs are not encrypted. But an attacker only learns about a single HA being used by some user as opposed to getting information about all HAs in a network. I guess it's a matter of making it harder for the attackers to discover information on HAs. Many different kinds of attacks could be launched targeting HAs in a network and this could be at least to some extent made harder if the info about HAs was not readily available. Only the attackers on the MN-HA paths would be able to get the serving HA address which reduces the potential number of attackers significantly. From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 18 12:58:35 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12287 for ; Wed, 18 Jul 2001 12:58:34 -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 KAA09630; Wed, 18 Jul 2001 10:58: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 JAA10757; Wed, 18 Jul 2001 09:58:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6IGvhY27846 for mobile-ip-dist; Wed, 18 Jul 2001 09:57:43 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6IGvdN27839 for ; Wed, 18 Jul 2001 09:57:39 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA25430 for ; Wed, 18 Jul 2001 09:57:52 -0700 (PDT) Received: from hypnos.cps.intel.com (hypnos.cps.intel.com [192.198.165.17]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA13533 for ; Wed, 18 Jul 2001 09:57:50 -0700 (PDT) Received: from SMTP (fmsmsxvs03-1.fm.intel.com [132.233.42.203]) by hypnos.cps.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22 root Exp $) with SMTP id QAA08719 for ; Wed, 18 Jul 2001 16:57:40 GMT Received: from fmsmsx26.fm.intel.com ([132.233.48.26]) by 132.233.48.203 (Norton AntiVirus for Internet Email Gateways 1.0) ; Wed, 18 Jul 2001 16:57:32 0000 (GMT) Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 18 Jul 2001 09:57:31 -0700 Message-ID: <4148FEAAD879D311AC5700A0C969E890049A3019@orsmsx35.jf.intel.com> From: "Iyer, Prakash" To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] New draft on NAT-VPN traversal for Mobile IPv4 Date: Wed, 18 Jul 2001 09:57:23 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C10FAA.B6F26380" 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_01C10FAA.B6F26380 Content-Type: text/plain; charset="iso-8859-1" This draft was submitted last week but has'nt made it out of the queue yet. Posting a preview copy. -Prakash <> ------_=_NextPart_000_01C10FAA.B6F26380 Content-Type: application/octet-stream; name="draft-adrangi-mipv4-midbox-traversal-00.ZIP" Content-Disposition: attachment; filename="draft-adrangi-mipv4-midbox-traversal-00.ZIP" Content-Transfer-Encoding: base64 UEsDBBQAAAAIAMtR7SpFzzVlMEQAANU8AQArAAAAZHJhZnQtYWRyYW5naS1taXB2NC1taWRib3gt dHJhdmVyc2FsLTAwLnR4dO19a3MbR5Lgd8f5P1ToIjbIEAGJpB42d8Z3CD4srkWKJ1Hrm3X4NppA g+hVoxvX3SBFB3+FP+zvvXzUI6u6Gg8S9Hpvp2ZCBoHurKqsrHxX1rfffPuNUuq0aNKqSBt1XFxn RZpWWXGtLpP6izopq2Gqou0kqbKRGoyqBF5SDOf88vjj+fGlOvo4OLmMv9ZqF1XyJakn6vQurRjM XwDmuOklDLo3zWY3r+Df0VX5tddUyU1a1Unee/nyBwkG55Crw7Ka9RnKUdKkB/jLP83zO7X38uUu f3/8dZZVaX2g/ikp5klFP+3xT96/sp2VV1meqtOLm1fq0oxADYZVWdfqfHCpkmKk/vniXP0Ind4m d3Ub3qcmaea1KseqmWS1OkunZau7S/xlVA7n07RoFHxOCrs2vSNECnUEP2SFGs/zXA3LYlxW06SA VXJwbrNmohL4eVaVN1mdlQV1/CkdNvBZ7b7Evz6eHO693HvTl9N1H/1uYSRVqm7L6gtShhmhnk3q 6Me930FJW6fHlyfbOypjkEm9wzOCPw10B+O6Kuezuq/OyyaFfpJGldBbpb9X0+QOJlmXapTVTZVd zZs0AsQNNqnDWa0xdyJJAewmyYH6AfcqgYF8zabzKWKjzr4KQNOyaCY1zRAHe5Wq+WwEFDLaUVU6 y5MhfgIQ5VVd5il8r67u9ByjE8Dlv1NNNk376rRhOkhmsMizKksQR6Wa1245eg6ImUkNHY/TKkV6 mcIr8F6OI4A3hxlhOZ3qEQDCC3zhGeJUjAdID3q8hi1U95/FEXgJNJHDoiBGhvOqQmoOkToE6ICQ ZDgEQDDzRFLPpGlmBy9e3N7e9rO0GffL6voFfnixm416yRUsdzKE5Wu+Nmr5CIId9GmSjMpbdQRM YNiUVZY+YCw1wehPmmneQUOXpbrJ0lvaHjB96GwZRnbULIcNIffxcJIOvxCIZ62JPyN4SOvAA5oE NtsIlwYf7qbkyNyBH4ybWT+r+8Oy/1uitgbjKhsmsEcdGHygKKvRvI+bfOu8rJBCCnU8B9JL4VF6 AEBcJ1XVz+CRT+WcHxEcwTw8nRcFyI5++Vs/mauti2SYjbOh+phNNSSDZrX1+ZM6Tmq5Gocl/L1N u4aHnfXT0Zye/DmFJ/n39qIMNO7iq/UzICSHtVfvB+c1wp6Ujapnpd78dZNUhGrYJkAnt9koBZEy gi1c3gHavb1xjCiH/cj7ECRY2jAHmM2vcpgmcT1Vz4cT3FxJVs0Am7XE9rAcj1PodFLO4Hv8zwz7 ngJDr1XaDPvqKkEqhZVDgdRnsTEsp1dEBIEYQIJIbpIsT0CEZc0dUuB0njcgV8tRqmB4uL/hvVF6 kwH901gdDGAvMOqkIRlCPBg3S5N8AaijmwQo7zologYizIp5CSJuWuqefEjwBOAR6B4QMJzo0ewg ExtV2Q1hd4LjSZmtWpGLSHVQ4JnajhoY+KCh1+pkmhJjBPLKRqM8BV0B5rIlZbMQLEZKY0fp12QK O2+bVprkSZ2mOBxc5noGox0BV4Vp9s2YxP5ChWAC6/ilKG9RJBckYYGn0oqnlRXOeTbNGo3G1jaF TmpiySxPYYJiEnp9WQAhry9rXCUFImNO4lzs0wrQQOyaViotkiugaphPMiXqhv1X0RiwI6nTJKzJ CMklkIhkBNsZ1u3/zjMS6CiFYAmLa/gVtgRORr7grda0TvMbnMUgRzDXTJF28DCz67RIkeXksKfS r01a1BkMG3cEAvr2G62w+frayu2XC6TQ3V/Vt99+Y/UUlgQrqpkMx9Mi+f+64Xx4depZSryMpjIG uV0zg5VUaCH3SUg5MBYlSE9FCRRTfFF5gloxcJq0GAGFZHp/GoGFmxP2S1MKOCy9v3u519/vAVOY wYIDOtVsclfjyNQ0HWUJ8p7bNLfSS/x7iUSjPoyBlQK6UO8QP+72iauVozkRev8BbZ8h7cH802qa FWVeXt8teynaXjGk/T5p4sXdtF72RlfTkF7xmpwB07moyq8PGZWFBJj6BIK+RF6jzs7VieUNwPaW QcH22kDak5DeDR4BCTB1REKLNvED5vnGQAJMHWX1sLxhDX99WBbS6757V30EWV6MgGGuCqZvITEc zz67nFTEcHD7GcNsJUiwdvSSAwXDg10xJSsuRW18ERwBCdZuUNfz6Yw5P+7dAUtUln+LwUB7ayDB 2qnPtRGTDmUowryxdgD6zgHC6f08SQswLUiSAHVW6TVok8A3rM5ge/gfCyEhmYPqNDRSBV89/ABE mqW5VUg/EnQtej6CGEmNTneR3OVlMooNeNX2vRzOnqPLO7/bY5YsC3gWmMUW0p6hpkrCAOnblMMy B97b3KaAQMAcLum7wSJIgKJj0HxA+6snuH6fjy7UJejAKZBVghIb8M6qCHd5lDQJLucYJMnuroS0 5+86Wqbz32EJh80ciHRSghIE0g50LLAjG5+T+ZCAmmzfa+NpT0J6ZTAVXWRQ7r+AvD3Jweo4qcop YgyklUaYD+l1B6QZCNMWHOCDAOfs3Ixp30HaN3BGiMiGEQm6ke390LwVa7uvHKRX3ZAOz73+o5Be G0ivkINPp6i8oKqsNSeYHENHKV0WJGpZx2JHAPmJCIJRDRZ0tqTtvnFjAXr8aLo5dFpcsng2pklI exJSWYyz67leNaTmZokodZBg5S+Ernw6FTYHaqqW2SV1jWxqFHA8B+lNv/X25S2YNfSC2bW8b2jn huMzkN50S5PTizodes6+yNwkJNSZ7DsPECm7bw2kPdK+0muhxLP6DjOhLrpAtCDtP1Iu7X5nICFt G80VaKAGo4mHt6IyJiEBpk7Q3H8H4wEjeEUIpklIgKkLNKqqmxQ4mnaUIP5PCzCSgLmA/jqv0hUg 7ccgHZ39i1zJEhAHqnkM0vcG0mupe/kiHDZfPZ+hH8AnkU5Iu33PepP8MjKGsPmQdlfm3+M2//Yg 7a3Iv8cR/r33UkJCPRUw7LMUzWnYFeqkpdeZ1imwrzWJx2tyNHs+rkk4w7KhpxBWcikklrrffqPj JDsc5hBtJeuWjdi9pzFieZaWDqT6saLU1LPUkPa6IS2Vmnv7DtI+Sk3eFiew3B9LdPB/AI41zX5b Tut7rwwk4OU/pXfqLCkAiRRZQXb3aWD29TJYDtJbpssg2LOATkNIrw2k7+zckB18IJOdOHiPfXsI 3gMbgHKQvu8HbJf2hhUTLWYTDN5Cgrl1mRfWtSj9GG0u5SDFecoZbBkkY2QC/YVt742DtJA/Ld3k ElI3f4rz7i5IPn0vn03Y9t46SDA7C4W3iFZOtFttoarqQdqLQjq0kM4WQ9ISD+kyHc4rdN9KRWrR u37b0zLhe/TKoFs0T0fX0d2wrBlIuy/RWGkeAME0C4lUXx3/ehAwAwn+DVxh7eAxupI4RkBMB7Q1 dsrxDr8lrZniDbilbkUEgqIPDo6OQ8BDP8NvM5akZJEYN7gLCIAV9SM9uv+jgNCkwwn52Yz/cOWg gINhwgPCX1+ktzI+oOphioGdUgcKtC0jYEhBqjUe8rgJj/4iL7wDhFFOGLLkR8an3ydhoZ36O2qK vmoXk2H4clZGJZMLAHbDvEGWiojKkAFilAbdb0fpGSIMZvmbh51/AftNbYFw2N4RfvIpz7cAnJKJ 9QwG+gwWa/hFZYXelw6GCRft8PaFyf0OfdTzKwwh9V2MCqmAPfllFc6nThvi+fMZ9oeBpEqB2dKQ T5dthdEIQ7c8IDcxB2II7NCoWCDGMPbOgVEeOA8bkCICXWbxZBTrdoJTpxHggGA2mvA1MAsHxmAh WOL0sMLqDg23AJsFpE7fLv0YsHKb5HmPgx0jGDIuXNFgYNtB8cmrYB+5JhIYKnAEf7GG5TwfKWAT 5Rz7lxjGyJ0XnpFU3RkLcgA6okI7JjKgZXAYBOJ4vwNTjoEjqnmB6Jzx+gKGmJ4pDSKBdS9GwV7E 3SDmAkBuESMY8UyqEX32Azv+MBRrAzOgz8yLVPNSjqVnGp1/2B0qGeLJgEHaqIeObGmfoQ14ZZrF kqMSOdjQW1frOlEYdElHbcuK6cLFwORqOTj+yHU4LFzqnY5QmBjOAtwtQEI2RVaIsdGaPakuT4ix wGt0nRTEdhLcnDnI+fpAADLZPa+ACOphlV3hODQ2ZuTiiDz8GpNnhnPiBxZF1m6A950H3THYCJw3 q8HxGbWHBEAWbFFLDzYpw0bZs8KEwRowYoAQvbgw66gsh/g5XB0USjomZ1nM0FOrdxCbQh7oWRAZ 6sVA1Rif2IwRt/80Rhz860fU7Nem+8EIftJ67w1IsnKaZMWB94QIuif+0yN62iDTUJZ9WgogrT3O fNc2ykf4zxSZvfNTW20kkywWJAIgE/b1KBSifc00Ip3gFpnXnlCm7CzMQwFpoFUUVA2KYXVHfi/c ppQhB4I+YaDM/tA174Pxp4vJDlXJjN1zDUsPI83SQWG/PKWCeRP6VoaSB+zIf4evDvAFb31YBCBs AeJ3dBp7zn8i6VE6JpPtSrKnXyjn7+Xer94eFh9RSpOdXR20+k0K7W2i3zlQhHzBY53BfHCxvqQk j0ASPTv7/Ony2Q7/V51/oM8fj//X59OPx0f4+dO7wfv39oMcFz/76d2Hz++P3CcH4/DD2dnx+RGB AfiDvz3bCcTusw8Xl6cfzgfvnwUSBgmH83oy1mgoEY9QyGx05HMaQuLu7ve/BgxdhKFbe+/Hj8cH 6kfOcyAEImEfF8NkVs9z4bqidvrp4sCpPZ/SChVvQ6hyn5AVeiDokix/X7DhM28iz7zxV/1AnWv2 OGD9EO37os5Rx4yTytl57wK4zQF67kGZQeJmEtTv61jg2bn/zuGHwYE6LHt5OcRESODyVdqDZxe+ dnpx0bsAo+NAiHZarHEyFD3yvgOV9AY12q13g21FSnwIaX61GiBO2ApAALJ+/FmPRohF2IbENeND AZuiNRYNCAezFA6PZOvnCJjTi97RAb5zlKJvmonJLKL32Cd6rC7nmIjbfgJksxmPdG5dUN8vMCxY oTILIDrfJaR4LzMCXhjTpv32t9+ESRetzeP/ipxIKtfI3Js71nIpIVbri5FsyFkCLMuw6MSEgLLm 9zoQOe8GvP9n2bCJASL9IQVQ6PsJxkeRgpp0GVh+ivmZ0YK6RsN0gJDwQc0UaSI4IvkV+8nRYCOT BiT/M1jmZjh5hgzZQQKFp9eUYAWNUDoVWnOJT/bdAFiVQkMj55E7MDwHVL044kFOAbSRzrSf4t3A ZSChOYZ+OFLIrjxhV9flMKMNTnLCgiEWYU1aH3OUjVB4rg+dJU1admqCLzCE8FUSKLgcnKOJq0UZ gWJEUX0GMzAL8n5QQrobtVBRyPRCQJvR/149kf6HjdBQT1CifRqw3nWDDpl5rT2WXjZDaiL9nOIn 4ATIeDfYqrcDyS7a8x605/Hf7pHw7nvUIj/LtgiM/g3bfeRn26Cne9wy93Ewqk//oydjP5t2L3pc cTzPe7Y9d8/dr44dbveOqMX3S6a1/miobQhFKw4p3pbMTCAo8qvXVhhNKFhMO2F2/qr/Uh0EnJwM kBgPDGENJDca/M0GdEGSZ1pStbwjyKbQlICN6MsE8zIfL7EWbHM3I7endSqwr3NxjvNO5xB2VDZG 9sc52HFlF12ON92OiQU+DYeO2yzPga8D/yX5Vc0L1GsSNQJTp4eMFtlt3RCfRdQ5OCBTZmVN6cDI 1jNOIOejLl4XBI8E2p1iiA4IwzbrtSQxMz6fD4VJzW7LdKuxSg0FI/okP1HASAaN2VpOuN9iEl7W qKpMpjW7hBNc9DS7Loy/ostUG9SB6rATDIOEgXY20k/sM0KK9rRrdKHlGa6x0FOiXfZohSRYT55U OmcAabGiqP9M58tJv7BxIZBpag3SJb2gBIQ1p6Q5mMCONG8Rxv7LvVeLYQR+gGmKdn5WT0GyOQP/ PLAZ3w2MN3+94YLSwpPXahi70tuokngJZhR207m7jC3dvdSrL6sEw/6KmlJb2EXdwno3KjxAhdwt wFBIp0BSpx5GJl1zDWTEOwowjBZHPc3qOhy6g7M67GmJSmNqFtSST70GZOI+C5O56eHNqJmvn1DN DGiRgykhY1yLL4b2TkIsUdOvMe1MTA61U9LPNYeUhMOhVDz9WrBhf5MWJMONyHQnr0huwsYUPukO cRawWuQK/ylY7cq7aB0muQUz+gdcJh/p+BN8+Q/qZLC9DtNEMwxPL/rzu8rYEKe41hpb7P9vZpyM YIs2WU3ZFA/kxpgUNM8aNAkHHy86gCyFwrPtBrDs/XYuF7z84fPlce/DxWWLZ+53HFvp2K2BJu7H kOB97U0z8SCj5jsIVuFHRZ/0dGBANkKNzqICY65zUmeXeomSK5AdfYuG1nAwo8xlgHqqq9iPqQt1 i7ja2KZBclpILYPIDg6OC7uhvIKEji3EmKRwQ+LQyFckphPqpR0zwphMnqe57YLz2nwumPChNMF7 LTL66hLzSxC5O8R3r+q0kdLEQeJF9u0qveRD52LmcSB3QnvHHZdfyXjR4AwsvcjkXCLjbJSNKZ+o 0V4tiTDG9lL30rffEJV3H6nqpPNzuwA1qmh87tDEN83MNdrI7y3d7D552M5gFHcFyN6h08xaohzo Qm8ibzkMcCGrCVnDcpaGdqN+DSfecQJs+e6u3LNG/GlTNqtMQkQKyzNs1CS7lg4uL/cJaVafzQZB JtJaXPIWMiCQUnmAONYlXOcJOYXvSi0PzUH/KALM/Fc8tyaeX+F0Gj29GUXyzR+jSNJ5NGZNbA3T 7glVPbV1O8kwKSOhDAD8DzqMPd8z8RGR82TJsgYemW6rmJENECYZed4dHMENsV6JSoak06AuWJRF z/YQRrC2pqVXsSDPvmC1AJMC8cvRu8OLX7fZg61hjuIQoztrllB6gvZyo7qsASdRrcZzH3ChgISO JWuDF+DkZc1KtQkc3FBApXTYdxCsyg0SZpiaIWgPDy2E2XiA4duk0gk5554ksbKK57AIm4wmk1jo Z0BJyatdeLA5TFTGJzThEI15RrseMQ8KSPcKnW4e8YQuznsO4JuIqveLD0m6Y813ZiTPVQuw96AP iT2l8gGEcU9UfE+fXGfmw3P6zwPGZDvTvlt1f4h/h6P14bZaC2srjXCFlVyENb8JuCs0+fZzr9uu eENX8xYKTKZ78dfDIT1uTCvSv2ntr8QePEACwVxI9JuMOng5MeI2mJA1R8XF8Q16TsfqFuQqiJsh wiXpOtOisIZvJuUtmiVze6wBN4OD4SLuWvxbJmTZrfbRBxx+TGebHSCtHsWNStOvUXMtr0xykut+ 3NSmcRob5CsM4goTObWW4KUboSqbVrnntzCHQSgCjRELLdrCcZgT31JNdFBIwcU4MbJfM4LTi15W 9ECisiM2NWMy/NyeOnBw2J2D35nh0PwnoCOwbsjZCJRIJfIXYmol5nJTba+sIa07GwKKrFtCTg16 rMjA9McSiB1ZOOvsPJCTlJMpjpGCYpIV2ZTzH7Sd++pXGvePH48xpyyayoNP7r59ufurmlJasTux CRulBuM3T6j2VoBZmGVgnCyvJBDfJyQ94ym2pmgJuuWS6jplryzJ7PbWS4ubrCoLPnzH+dIIwbk2 KIuqmqceHnvUv05kD/e1S+HCPQD4oaiArnbjYNA6pDqNuShXyVn2iEHQETw4ThMOJ1GexWjElhYe ZKh0VpbOJ9kapSNtdzeyugovH+XubbPZTiaAmRQMXaZkY3K4pwzK7HQcQo1VndQVsijkLF6aenM3 o2xnnaYesz00al3+PS0NJV6rdHqVjkbomQGFenRFrkJO3XNAtmp3CA1N3FyhdkojA9DbOJ10qk17 gzE2tf050S4WVa2i+jcAeMEBzTtgPFOao5/uUV6hK5ARF6Ei5ypALXZG8AEno5JW0fWiKHg6Tahu FkJCWJuxht4+oTXk7RZDUOzM1EmqtDi1TgjUtG62laQMckQQqkWiqPUVCNTVaT7u4aH6a3IAebl+ bJvg11emKOE0TShjerEBRFFNsYFNfNMXRNEV9mY++BsxBzA08jll6JqpkuNk5fcpsZOFTUL5iV4i kAPiUoLYZNkRngaO+i/v0mA44oJxGyGV7K3io+Vc88zkCxr6qhH1p4PzgdoiSfL97ne/7qhf3n84 HLwXDrX3p+c//brtj+50bBAtBwgbh495MY1QJUpSXYgxcB6QF//3XJ/DpNBGnjsDMmojBWR+F2+X j5JR6CmEBn2dFjwvkQRDwsL/2bjsrElv/KYvyLkohzAA1VvSiXYL5ZZiTj9dmPNKpX9SKZBz9tCk pzbUEzpGpJEGr9VUx7QA/QULMCIap3JEPyOxODpzP/iSHgbH+9EgzpPOXD4Me/S2IboVcRH+EXB+ iwF13JgZP5p+nVGYl+JIKW03WKyTOZV5xJR9GRtBvFhNwuoWGulzrV7I4xi0BXjAvgLu/Nju1AdK D+miFY+Lj6cmSzgkIcoADRmUoKBwu2OWuKcJ2gltdbswBRDk/NttNzjw5imWSMR3vfExMZEG4qAY t3xqcmy1PSI4gqU6Dx1cFWrFulBxTF56L2FxUU6K5MAA1YprtPzwkkk9LtHhTTOJSTbp9KydhCg5 IR/p9o5Bk56MDk0t7exQdygbCE+FautLCi4+RDEIs0QbOh0D82EWH42oCjAwcqrya1+Y6WJVhvyi ADz6cJpgGDIeVinB1crn8qFof1qN29Y5/yjHd5LkY5c4z7PuRDImOQMbskjGsAiFjSjbn3YvGeY8 rPBpB8lNRRwLpe6jdDYANZdCOZQvHDNmI9V5DMocGO5Ri5erVBheJpyG1bXYitohRlmRLVyqSZrP Ai4mVUppcVdpM6+KwPA2w3Qg4PUX54OLS5EN0sWvcEVkycsRRROcJebsKJNnJyIkDyjZ1jGMQVsf XAAlSE/zzKAFHnSBVdjxFjXs1sAgvNqkQv7dEyrkLOlcaVZvbmGwZ6GICOnisbXzdNk8AdR+GtQk zr2C0NYpZuJDzI30KfpAWlpI1qKq7cjWix1YSFIE8hG+Kh2TWqEhESnO6zTcljJsYAfIx2DEqChW Xfssz/JqlgEiC8cGiNs6ut9z1IZ1cEA0l1XWV+9YnaJsWlp7rVQZV8OOVrRAM0y10TGWhpZDJiLA nEMcifBrPZykUzL48KRf9ptDkwUSGbUZMnLzmzJDq7jRnoejtID/gM3WM6fLLKCto/ITILdpgKmb 45aOO4E2cF0hM6jRt4pnOm1+7jRtJqWgSJzjiCPJnCchY9soWlEftcWwlq25DQdFKB4bILDVEKZs jrHp5kG49zaa/k757b71Cm/HLaDCv77cXuWVlnP9h1bP4Suq3WzP9pnlrwTdrvJK6+/lrzxgLopL hJHxs/or/4aSxP4dvNJey/u/yNlHX7GD0MCXTt8DSWDbr+i2wpTCv71X/L9spGU/UQei4Gk5XsTG PBBtg0j0tHRr6eZ22NL5tX7z3zg9PLtQoCuUpkoUphwufEN1t9ZvwZvhsnH7YfmbNEomlHCYneNZ f9TLqEy3paMNf130WyexyR8c2V0B2f0zORTMufqVKS9KeO6Py24o1s1j6X0rOKXpwIgdQl5sMMQo 97aepCP2UM+SymaVLbZIRXJRkTX6VOPEWSpWPXZKMcLYjH77/RPqt4tVd6M48aHClB5YgqjQSHea FappNRfxSdRvaVX2SVPFnySYtgKn9O0m2ifB1+4AtNCedlA6x8uJ0jSktKrInwdW0O7+K7V1UZZV LoGcYIUe9I9uR4+aUoEq45g2hO/4sINjz1g6JRUHsVWnqS0voitXbxuUR+bEQZia9UsHE7AJmiao UYYUkyusTkMqv9HLfJdb97ba0dEXE64nm4ajs1H/2YKg9yIrGAkKFHDW/ng+DvwOkCJuIdSY8YDx nIwLo+o7QMuV/p91dYqeDnm503CXHiQ9nGQ4ydIbnUJwhf7+JL/7zSinAH6YMiQsQaS2sn7a3/GS F+qUL9MZKyfJXHL+lIUFZtG3S/w5IN6aLWCAbqFMinnHHnKc0tIM+guJCaxcL717LYXXAswBXqQx bRwpD47agxBw5iIeHdmtDl/Oi+d5mjSkl2pX7al99Uq9Vm/UW/Wd+n6t7zSY571H/s8AuleXeFjT tnv1Pi2uWcGNNFQ/dRzIfLH5EfntQhLbj21iM2Ua3BA3PSLZBGEB3g7U7ncvxXeMOyyKwjH5GrZg Afu0wS2lSY18iZSZY8NY/s6w1LcDH5Fzm+1NK4WbVS8RwZWWplmbAzpuO55j5Wgk3Eo+tCI+D9Sg CBiqg/HB5FQCd+BNXjtb2VRd8pmDDhU4GJaVZs0iUcgCuyWfHZx2KkWEFXncZN07E+KM5QE4iOiZ FgsaUsTXSSn5rYsTbjLJ1j3O43uugqcK5Hu5GmP1VZvl4yHCCAHVKsohhk2lR4C6kpxTsyJlSPzi I8ZeQxiP1Dj1TUkvn0Lj5CmKBQ+tSrFr+PfQWWObTzjocOj73pBVzGsVWNgRvwxBVktBh+mzrd/b kFUE9FIw7a+ig34IGD0alLf2sSVg2q8EHhZq962VCrppv7IcxbFuYu9EvvKYrZJWYn9PySJZizmY ByNoIXczrPExl8DEGeWluzXAhK4wLR8/J0Xqar6QYKzTmiu96ILuUpOPmX9sqHmha+SMZBRwauiO jrUJNsjTMcHw1EwXU9Dasb2ArQo4YTzAFvnzl8Vpk5415eDom262QzPJRbuttYQTIUwW8+mVlyGH RyvIbDXJDU3pZuaFG10ZgUhZxGWRToGN+GJHBvkKLFeZdoESm0di9aGmRUBLVsIGM/iSYoBOqbq1 fwpElrCVCS99yszAI2/BWGt5p6yDgzPAjMka85A45AwyuLLFUXwxr2X6C4LrgOg8P5d8RZF1ML0y XDkQWynlHM4p82I8zz0qCtJ+M1d2tCxgO13dkfrEWaLnn9+/54lxCW40A3c403Lm5d9qMzRq7SGy Z0sWuhWktYekaf9RyBAmGNKDF1WiR/NsnOKlmIuN9UseoA6qw55CnigBJU1kNSxsQ/ZiJ8j8S7kJ TIGvlLQRjqAZxNB31oXtmaIOgum0rxfLnO/FSJQ5B0W0Wpfs3QNKzcqRtwN+StPZIMcwnNXIgnWS G4JlxmOv3+pea8PsFjCouKLqwFhd13DoZQyzxXFjhvwyINrSl7lqm9E/n+KqzpUvPeteqOXODocx h6SgIm3c0cFqoLhqxaOCKKNYx7exwN+xQWN+Yx6PjY4p0lxx3ZaPI2xPOibklxfIps6Zfds+A8QE rRUmWtp1S1/224qnu2h10TGzG/lRL/VB7EVsj3LcyPZwJ45pXc6c2LNtUgndNzbrzomBNpgo1zYt IIMD9bmlZQrJuuZ8DOd74CWN3dwQnkDFqG4LawO0zcZ8mdNVeEInizPkdgBiy3eYaJf5ndVA9Buo gWx3xSFOOjjtAaNMBW3ZBoq02J66xxK86q+KiyDTN6J2smFF9Dt+zQ/EwRzhY6akg7qXdGp+qLIb 90oMTPgFfHOoD3K4sZybGsXrgMHmqkhGHtg8in3iXJ2cdvRxIU1EDkxASlrF7gtv27eb9Lk9yc1u m0ezboaSHXX8nZJNeyyKAzbrol4ud50O4onKQBEm7KAYdlylwzSzZ7FZZlEJH4Tj75Jl2RA6MO8l pS9IY2+FOam6tl8f2ozHn7MOX7D1+c53QQzsdQrhWmtVYoHJ66cyh/IbhreVp0nlRcI7rCEHxSom 217mOk0EwzT6HIcRY/DPjNJlU//09iX1ReJYGxcZJ1sWytW1MG3z1KebFVVyAy7e44s2+LuB/NLf 495vq+5MFd/jbrhrgMHWtcc3ucG7Nrbx7dRhjM7UwBsmw4l3WNwnXXR9dNRUHdMRUHTVyoMQes8G YFqxd3NV3MJDG+jwk7sg0eeDowUSKWkG+FCpq8J0O13d/jMJDsu8Ea4+YdQnveBsCQ8wZpg7KN5S RLkUerWmdMFoFwzjumKs2op4eFqbk8oWxmhlUBK2jPWcoW+IPGfam+mKgmHeVFbMKW1cj0xKBdGR GFktSCkr5H0x/K6xJx50VXucdemzVI753lJxgVKfnepk4juBVNH5Itgr0yuoblRr4iqNXJjl3jsR B6HaBsEGGUDQDI8NGKBawCGXK1FVJsF0sLVNcjXTIvgUuotLJdhEz8slFmt5+peYTkkqq4qtrsEn 5o55cPCFKEI3g85l2ETk2cwnpuLNmB5PdR+ZbOujY5nd4ZsFnYu8eMs488SC+QO3jGnMU/cNR/Xi dt7123EKQWEUTT5hvxp+1Uo4sWkmDszShJPaZpycl1RaR0eFqBsHx47cSO4gpEIlRaKHNgUMEtoy shDbqSaD5Nwd88FeuPnY6m5+ikmEVhZ88hTKKJm9gHm9OL2IvRp5XhPJD9GuFg6t1dOS51s9dTHD 6CdG8jqv6O7MqNpviUSM194dHNbAJDIzdx9T9QTPX6OU2yPuWzx0HNlVi2LgVmdwUBadMW7lbNPr oKtkM9iJ4cl0zkU+5QI7CGSSJqCVazcUmDOiK95cqS215aBoLGRU5efUAFFbzCwM62OVC13C7mvk mWKblWyKU0/DpE6pnuZVum2ysDXydc0tK30QqOcb9o1ZxIcLlhnmAWiZkwrHE7NsAvmTg9QRMCfU 7kTUdv1My/Pu12oRHwU1GDO74+Z1oQRGIT2A/VOTMoAE2l+tQ/geSeJTNaR4wH/HX+kvaWRTWpC3 vUma/dWpNQjjiLz6CARh0F9/xc1Bz5v3NjwX8REpwCsfIR2ytEHw1vC7dskmB8IkD5T6ADOt1Y70 OfnfCwXfZwGbmBovk9UIly8Tr9Kfa5miKxV+3IxK+aRXnC3bwJI3AC6zuuO65Mfg1SMOFTjLlFpA EiqgCqV10UOXDttNC+qR5KDpAKXsq2518/DcmetRvJunjaS0IsougjPmW85ftz5BzUM6Im+FRJjt TEX0dwQcU8SIpCRf2ozOAWQs5McudcYZj7urPiNXZQQCuU3zvH0Ai+R4bQW5Fd8sceVwPGd4Q/yv 4Gc1lTrp2dYgOpnoemLUot9Tfl3HWyY/yC1PS6J2xkyDkYkNWHsdG6Lwivagd31mnccCayYKp7dJ h9BeTOjRzSj2k9t70Z0nrUC70VbfZu1b5S7NjEXYn7BCItH6tAQGWa7RMw6MEXOseVGJDV1OvlVw nI+juTX0rzTfKO+LIlu4sBZwvjj2XYRhAd9bfTlarb0+ix1UWk05UI9AkmgtNcL3Ua2oSrQUCd9B taIy8QgsirZi3H1eGFbc0vIC3c7BiGh5JhexreYt41Lxj54/TeS6M5uSUB+OoUXqwYNXXbArnT3y xy67ntRmFMSnupwMdZtXeMHalK4iAx5pCgMDrbEmgGUAyoIKJcpLqijd3VboarN0+at+r5bAkX5E 2jbTcCnr9Q7LOZZ/xHKDOkimay+lt25QQdys781rl48M0ZAPXcHjxIVWXG89L7m4o9wRXxoTSWdz cMRQBq7OmTmnotmnO2Zs71viO6EcHFB6ODWtv2iQrvw5pzukWFMJBCCWtMQqC5wYJ92NYVyd7vjo KmjQ2TWeYeB7U3D2HfnOXnDMm1n8PlTbhatWZ+ZHQFnzClP0/SBJ6/BDm4vigQlks5E0fAdH1Cmr YqE/h/GRORypSzZKAtyTBKjpieHYoy+WJjoI0v7eRZdYDlujAq+wxi1S+LFD68DmewExtWVWYZE2 XbrS3dQXXXI7Arcs4Rha+yKV+lRj62mZswUY05bYQGZzXkvcve5j8oQ9M3Pq1ZYfi0FhLeYazR+k g8vFpTt5QjNTilUX4HKFJfMEOTSAx+h1pY9HaWWxY5dvYwVxvGDHP/nTfd5HjmYAu4XO3FDurfBv Kq7Rq48o4SLYE1Jd0YPFBzJsl662gDsibC8vJHREC9N0HZpmHXyUXleJruvh7RZgfqMeGoMCH25E uM5v+q21vbzF+mrY/0K3sxQ2XfV1McmAq9xKsBxQKecFB3ACzoTKE6ZDdydAzHxJ86b7Piq6yI3u bNMndWs3d9MpJSDcTrAsYLQwb6yoHjNtya00+5bXww2plDJKAdqB0Wq5S+RCn0iUq+kDIhEeMmU6 yo9jVlzJx0EhMtQ56QmwvAo4b8L1uUFL0eVsxEhuiTV6A8GvchzBBBavnpV4zbWWGOhyNwfUidsi koKL5hygSO+ioLqscc3XjKZfd3w7sNu5siiz7LTxr1Qz4s5eyQQo0LUfvUKwAoIZLrofeE0pr6ih RaU3YUQpXuiiYxG0HtG1wGQni22gIF3qnpaB/D3mwpIG97BRsjxGh5dvFCNNy16tbLxcfITxjt9S zm6s0cOUoGeqnmsRsBn99ynvVOOrVUpxLY47J1ynyZSIEbSPXlP2UoOI1q0bIx6SvhSepKrhRFcJ Miat8+oSor7sb2SOWkr3Obiu7VxUMqzKuuYB9BgqEEetDy60TJXnxnyhK46e99xn5X4J38Lfv/3m /iQoVnvvjCPV++Eeuu39+DOfLHe/3L+TDIwNqfvnBqr+gJA+oF+QQMpR4Ren6AW8Nz88dy8BJHGJ 1gleooXPn/ysX1SyiV9wVAP+cMhXbnWMyb4oUOL90h7TCg06C78KUGmpALApOwtfWnWB/T+fu2G7 7ldqgrn57f90fK9/wbGfiZvVYpF18xMNUZ1IVsxf3fOb4cg7IS1pbSKPsm4dVH/Tf7nGfVzj1nUi 5mdZDx+n5hQGMEydauDUhovorZStYVKpLh1CxjGIYWuvfzNxJYz18eyaTHzi1C2Fx3nN96yY6nIY fTJibPfAmGtC0dCl0A1OtLRBhQDP5UrF9YR96VywBnWFD/AFH92dlQCGDBksqjshRJArnm5z8ZQF ccvKNukJqFw4Vl2bSyYwbJHvcPgf8d6y9zg7RxwZYMs2uG7XrKS5Y4aKcwfC+8Lq5GWVXdOVDngY vtF6i62F7w3Er4EfyfW3Bfz0C58G1iCs0jEQA5VppKP7QpIA9swaoCqOmjhbK7xkcXtFkEdwoxcW U+6R9ZvM4jZNjFD21iMU+PbES0awV1e4RFeDIK0daZzYIkUWWScy6ULfhIoqI18wSnTnriMO7rnh 6y62zR0uDs4sqXSdDVrCHRW7zLNOm/mMDHJxXEMWavZIy0Yzhnh5AOWO55hYwtfeaZCgFsOjrJDJ 0XBIqcNeEb1Iw+sNuiZOfaUvVPWiq3qIieZ8ehCDjFVqdT6uuc0ONkpW0ARedg25r36hX3qfjg97 P34+PTr+VehP4pro9FreooZwNqNUPuXVVDz5oTWZyLU/ctiwOLi0rjCkTKsqSs5ENfXx6iBlcwjp xlxNxu7KDO/aV3wMtX+P2/MW4MGhj0EPy7HMvqSR/cffoEemUEXnqDw1WNyDF/Qg+KDXF9AFLFSW SLnUU8eBXm54wVTe39XCfuBEwWBw/Y8KHT0r7CPDy9PRdeobS6GC4Ht7ziKl3vTmNTcqaUe5PxXP JoWO+SIF/6Z7HCbbcIgqLZnwSiJRniZt1XzFVAQj8vB9T1tBrytbIn5XAm1ab3MWij/hk0HPeufM ZYHkwzmXl83bex5LrvaPrhscnINE2gvZY7HLs5a47IWnUCylA+J8XNJMtm5MnWhYmssxzzquNjG1 VPwuzX0gmX+/+9B6JuTmZKN/RYf4Aoe/6clnIa5PW8T4jmW/9vttpf3rPhXwQW9IUnESo6Q9E04n Ve0aT2A11l10Bcv5hQsTmVoui2a5vXAd25M0iNT3g6VfwVTP9EUaDtCXFEumcpDJFSFrZGUAK7aF ItVywHhC07FDDJQZvmYujdXKUZQRnorIldlNpvqCdgOEbgWmWyIymSwj3vAJTOikvFk9xwOJC9T/ HaRpqk+HOgYcY6x6vmCnnCSwyu9YeeyY56Xzl4zx6Yl52vortH5XR2728FwfX9J0RqPDleQzWKT9 o2sGPeOglN0WbHahrjadT51z0EEhabqDNx1rrzA+biNxpEVoEg0pwccVUCLfZ6QJBItpA55gPC41 px0KRBX/qPTrONXljl0ffKZKxWpCvyGiBAp9iYgHAmnmYMjpSL8hc3ylnuAdalKECVL2sq+6E5p8 igc18aLighmgWmU1MXEEelqMK1jsaj5s/OpXkjAmvNa5OShtie7Aj0qYLkwmGHxqaOEz9BWLXk1V av/1jya+LG+7nc8oKEEKqfcqbkV3fZ9YJE3DzOLRpVp3DNLZ7tbA1JKbFVXadzgG33DIinFqjiHe TvikcpKDUTW6MxeWjnh0esbPCrBBTC2uzei8T3n7E8oNkvLPAB1TPPOib4IkXO6wfjWmMvIgp/Wl voA8SZizKqNMBPYmw4Mj+stpIBmeldV1yJzK44Mg7Yci0FpK4VFHUtzokh4W6SkfT7ArqG+JNWvO 5L8fI3/ktsJpUyIppR28kW4zdpEIfHVmXsAo6HRKxYY9DcvqVUIA2O7GdMch73lNafpHq7rBmPNk iCMdpXJK2KQawtmZOCSnyZU6oMqCiPTASEwV9k9prrXiPvDNCWqzFaMXSPs6LdAwBGohK1ZyVmmy aGEFjPwSD1IlVcObCGyeMaWrwgzdbZcCxmhi3AHQn/Zy0a0VoFE654ndTER3yIsSz6+GUxwcvq8l 23sNHJwuprRF66Sn3vAJ33cXXf2BKUUAfMx56cKz3mQj6Xsws4JObue5753SUbM2J5QagBgb8TB/ Srt9F0UOzyF3cG9SyrhqUcR4sddP2tNFjTsI4sBooXLpo3FZcQ73frRPV4iDqazjYkgJhc+GY282 U86d0QFdtaKrG+nsjrkIc/EgdCaMuNPCpfUsq3kRvc+iv6zwqiCIifYntcoc6pTsaHWCyKWUeHyc zpegZnGNyIjZMVd3M2QLejdEDah+cMoxiJlfuBwWUFKq1Gg+Do7NiDnvoVricXxZibGDVmW+GU2G r4XPWs5DvjPuZNAOGI/9mJeX2D1QVZLlPbwY3tzp5uLDgk1EirmTCHSQsqA8id2kKmhnIiOb/rZo 9JtfdUy3WC1u+j58MB5WidXg5mdbLfp6+zH+vj2qtV5vj2qt1z8uLtttv4u3ZeW6zWPtXvj78MGO 3iMVvvnZVjOvt4FYWQNsf40y3cpCOwuKclsZsrtyXTxxEjusi4d/bEadfcrLnqRn1maC6LJopl6G P0nO1wDW8u8oWhwkrZzg9Za5vtRFq/rG383WEaGNStAI/5gDg34X9mueO9FufjzxE8BwGJ5Br9sD 8pmXlObTZ0EeVdDsZPCvtsJfR10C+8pKOzZW7AjWxSSCrw4G2x9X0CyynCexIisb7VQ2s64OV49a 19jyrVN3IvziP+u6ei22Z6V9gV9Y/8wfsNZnogjYI9ZaVt1ZVLBMrb5IiwqWrQEG2x+31kZS7nVI yrDi0/jPWvEpGMSfqOzTMgJbzpL4/NwiqlAbJwxqq2z+P0ZyL64hulTkWsntnlqMzT8KnUJgnv8B eHQYeBQepSL1x+LR8Kv9PjmR/GMqH6Vbe2zv2vFY2oUOYgfLshEFf+9J7tbSDf0kxv1nY4+cuGOc ESJg4d7rqdOCA0N4YiMa0N8Cxb6h3C/8Ej1yf6W7W/xwjnwoCWTc/GrbjgnDTVkTjX7j+PnkvPXh cnIavaLnYIvSeNkKUZ8Wu8ZRTLTOqnt8yoHBHBPA1hTr37wbBH7UPd/pSKc0L9gl4kfIgmVx0Ul0 u8S9LqEt5k2ubtJZ7Yd+ydOfjjQJN5Vf2kiU+jo87wfDMV4crjyJLu1yCMDohMa+HgH+wN0e6C7i qN5pRR3tECnkRRkS0SwVu459fwPiGwDG5AHWVJXIVSH1glw0bjzflM7QCOU8S8oT1KcBokvS3vU9 hQ5Mz8/gHvc9gZ63mk8PZMVNmd+4YxUhvrzpaeR3HbcgZF5aZB5LZMb4f+hWM02c0onx6dgrkRbn 8T8dq4sJ1ovaVVunnwY/nV3AULflReU/dL0bftHRlvS7p7Ysip68305KODOHp7rowC2jA9HeHTLf UkKQe6DTT2yuzxCVumrrhnHnfGRG9PyqJxgL++z9DlxHzPSsl+xIXkq3Ym1CeEIENahgmSnc43w8 rC1QgYwxngWLCZbUZi4gRyN3lgaURUoK6tTo3vEnGb0xN7Xx0LlXDqhzcXgOlBiwgLx5VfjZzNGO zDlHgxI04EOjIozBOPkTqzJDGZEOsBfn8a2gsNCMywsW+PXqrxjZ3ISlpAVr2zbj9zNuL0MGqFHk 4Gj2pqWZSy1gzO+Ekz3lWnj+KumqeO1Z81wNbmZeZZ2QXJjbMqmkbbnLRS5leYmwFp2RxDt6+3Aq WKJ3F6V4orQxigWfXbtz4Wsft5EcSkkMmosb7TsIjkhmjs2ZiN7Ouw/+qyKMT37hPt8LIJqTPgAI DWUzivJTXAJmunBoslJjrRn633p46on2w4OhBM0H64YcpSTxMfChC/cGWGnwf9h0+J/LQ6oe2jvy 9TN621OSgQoP8Bf7avi0JFOSCgf0tH7MFwtyz0WqLx6e+4JMRxd9FpoUSX5XY9oRJl0Ty0lsqnM6 xRwETEvR2STEgCi2GbmQwnFNj2krc9wVz+qamx2Sxm16L1eM8mpHNm7SsddP2rP1XSQPsH5Fi9aX 5Koy3l/4pxGQ3i+myKRPp175Qv7LSs17J0r5l0X1m3zyDoj93sL0f4lC2hye2ieyqXZCby9q02LI W1R0GxxKkvSzJ5cTwZKAyObmyGtsogt/pwXZJJ70kSB74speWlqkrIF+KYBlOeXGS7x2YIyN7fSL /lI2HXpOhaYlaeLSe3Zd7dHBEapPu8Pfa51Q55TyuU2ZcTDMPjF072ce+ar1w1erm6c9hHI3QatP S53LnMJSBbcCMyQR+RBXhGhssq+5p9f5rsowfWima64toi+jukuF3UHwVHfPbjrlwi+kiAubbhnC OslgwWKvX0pQRq83o8w+xe1ubJnvdVvmh+eLYnCXvJTs9xX+OeNHDE1uMiGjaRxCKiY5Z6SberCh YDNaVjKbAY/V1ZocJFu3SWhGNki4HeZcrmwO0xEUvdETk+TbkurbC83hfmtH2UKzVhDgRmgdxAax oHeWEQIhoEihQ1tIxR+Pm3tZ0FEhG5NxPPrfWZHBxRhyfjAdpXaAyIQ1x9c4Z3k+wwRjM87WrD1l WIwI7X6er8DC79CZL1OIckDnMJmcxhB3kJaZ5F2GuICwokmOkP/khvijoGhP6HIo7aw83dYai3zx 4dauHItaD4p99UHY/Uv46gOgxD8uSS5g+zv2/GIVUMVfimgDsrdOcz3a4dm5HaB5TXXM8nLSYcYf njtoUTM+NpLDNs9fbgi1NQIr77sNF6MzmG/X6uWSh1qnmlEtMhRpPu5+eAfEznCZddgqpP5wI7GN Ksu8VsacSTZ5KCKDtkzN/VMYRKjkY35NzA7yrR0HKLCKVtVsN6Nt7j+Btmm6WJlS1iaNZbSwmMn5 tBDT00xASKpp7rC00xfFJg3O1sjqdp4qpr8IVTEHyZaKQKXN072WU8ai1t7SzrR1ZvHaq6akcWtM 40UrGshNa1a3fluDHha15z5Rrpp65rMJ2JtEFezlEBdEwNo4TmEBCTikzD5m/K5FLFrhVlttPXE5 22spHX2rr+zqzrnFa/y49XVtGVfoyo675N/WFQW+lA7tmMct+n/pzaoiWQHi0CSzYFkkBlbFjySf BTlEiXE3+Bla+1j9nQ+NnpSV+kiVTj6AZTjNflt2ONSyBns5rzl/GgHzy8cPny+Pex8uLn/19FlZ oSb2nqxm4NQHDMtj3XgByBw3FFXlYwckTcn1GZc8c0l1iI83ffUT2L9nrvSETq7Sp8CXYIRrYLXT SWZVepOV89qe+MT7keUqOjAtSctXVVK5slXKTzhIZybpw1Vg0Hk4fsGLKxofnXHXVWWp2ooYEpOf Kd5PN6s4xxYyTT7Tj4Vpa3cIisqrOSiuoNepKXPB7hIYhrmbaDqvG7+knb232QHC/m0Zdu8q5xzr bABm7vyUC1Ornh7bYFXavae8tstWoEXCxboovSTHeimukEnDBXJ0BUJaQp0GKdGOmBjC8mtSflYB 3qr0Gb0DmNfnY8VTOjVLLFzKxaT00bQZFXEncoMFoHKGCRWcz6kkQJ4VXwwxZDd+kTAPAB+DM4aB mCGCxdPOpBjeJDkVjQlKQlWpX9LHUvQO5lqCaMr1lgBSbrBEJFW9tzQqaJs3WZ1MU0eXSM9F6ZVi im90OmhsNg8qR1hGIl60QgCwS6i3JF8iaXlFnnA5BXkoHl2QXFJD8DtXXEOysLecx42LLZ1vC/K6 u2dpDlQHDC1zjGyafNHyxqXMiSGK2m6lYeF6HLqsW+kI0FogmpE7OCZLO8jCblyGdFnXma4aZauA hYB/d7aEIABXbAqprzJ6Dzv6rYv2TFbtc85+j5BEflwjxePv5Hj2jZ0d3HlOgAruxttPMFhbysxz NEtEXE5MMQ8/CTzBFYE+dRUjE2WwtptXNCmMX0TG1nUlhUGhVgvDLHgGKgUTxQ7kkqPQ4NsX9tz2 IAd4KL8CseSsk4Dezdg02dEGN1LHbZbvrPaDVPGBWAXrlra8tr9zFu0W5gm6Shrw9fauIdlgk28S he6vG796rK0sxNDkYWFXlHwpi9HFOLFMRh3UUWzMRX+ur2HXDOs5Bp9q9X7v8oKKcBmlE4RbTWPR AU28mNDdo6Kzah2cO7YKruS1KXIZvu+HBdVQVNj6pK0qLOFid66JeKWV5etOd+NS5OU14EhGosbz gnhckit73RCfEKgZMVp5krVbcJh8JEMAohMSY6Bsy6VQDfd52YAKt1E9/Ryf11V1ZDmYGB/wi0PK e8hduRlTYxSoZj7DCmS2WJs9zxMWuyLHNEkzU00LHp3A1m5V1grHIxhZU6f5mBGGYtLUP5vO8ybr gZo5KnWuBBV+ZOoME9b0LjD6IbkgSCOyFeH0GEQhPfc21gKaF2Z3eNd6sMpiznsoPvaiq4hRgTWP FCzGYs41iyO6KcarNQeDQwEpIMUCiXVQDdHQfTrS1/OYDhwZxmVCcCXBUNfqrdLRfKiltI8Si8Ur 0LcavIomp3tDiEwi0w8Ihss1SzKJkYaDYzVyIg3HAEBl+Vy3dzmXCptekQQ5H1zabX/pVV3ajC7/ VDesUfOZkrh9VbMM5kP2gpWsMOkntnS63OTExRBdiSj4a2r70jkmvgokqLENGPzdU1lMIVBEK9YP bdoXk9CtVl7Ne5v26eDY22eo9tgZEsQx4hFsN7QIkC5GtpyWvd7l/eC8ldBgLqHRQ40U0s+oYFmP 6Y8UAldOPJRbbsz6jDNgYsiiFKmI5kgvMtzTSAXWTwzIotkW09flaGN1Zm2dTzGeDLkeAEcfgKRk S0XM+MyA/duxHBxxBQ9vjMRE8E/0dbf/m0D/jcG10n0dJOMLgLUhjVMURPKRL3dpvPjLmS7Gd8Kn Ad4uqxJT6yG4wUQSfM/lzaJiJ+m2rlet8wSv8wqqZdUP7jtgiEvK1bIzwFEYrb/bdQ8AHdpjuSoM bN0HiWMwNoFT8dUFSJ86pWOCTYvp2cpnxOStXiQsYweIvAaFpg1XEjigElnAeYsvuNoWQCK3aPXF gCO0KGC3bKLQcy6f1X5F1FPm1dBdqIX7Un+FmjIJVLEfUaPOjccTWbY8ooadB851MxS3P59oSXmb OAL8+zZZr7Xd+evWffENGREFIPW1VTpxSQXErdASCp3TdJMKCYdC3I3oALWqLC6prdiZu7E53Mrm ooL/ulJRm256Xb2izWq0triczWowsP1R9Pp2YRUbv+Ttygk4m9HWn+o+uAejr5sSl1LRMobJRBxd 9Eesd5stdXOlzShjizfrQsHQjSIplzaGIp2nuQBFMeXgcdVmlopeJoO43FxAQue2OFpXYZmHYMg2 yS383PoT/3Cw+PixdcDQmiguYirSJEWycsuE4ahD3xsFWB9uBPGjkuG4+Oxmt/WxMj66GuPJmRy8 mqgIBmaISG3wfpE33PvqFAsF/s5lSCw8qaPBKNnuxb/uS5cqEUl1uN8kblTr3zVU8Q2NIdB111+g 2Pqo9Rcotj4PWKBNrk+4OJuR4095BdfaWbHrIuq/6iG7CIqlP9xy2eW4/WPPpykWD3tR8XAoU/Ad xNhk3aN/2sT7yKiXKeaLwAbtT5wZ37H9Zyts/0vv2Vgm5FpZkDrwHJ73RW/WP9sk+eUZkv/hdBPZ 2g+nHK/9PcFzDZtr/W5ajfrVbNbpJk7FWQX7VslhtApVSSmzDudnq60Dw1Feiys5K+RObwo/ajOK Dd6z9M1/ewrVRlJNoBhrE3QDqJC04uzPRxKLsXvsKj+aWv5DyUXsY0wjMvdIncpLkwVXvfR2OeWc iAwTdOFicg7atCZ1ySau8lkY7YOtqYylSRChW8C5JCVfBJn5lwkhlVBY1u+eIAmrm5Jz8tLV+qF8 qa1aT2o7fjmyzT7RapNJ3BMeX+x2Zu6ZsLe41IqGPc7cIAkOx8FHpS4O2FQlZi5QigF6nW/meWFS RTKXZDC111sQENNd32Ae/v2+rwZDrEOS462tMu3Rrg060ktMaqAYK96ty/CT4os6w78GBUjwW/a6 H2Iu9G1aqPfZ3BYexb2e28u+0E+qy8hmFRZVymAGpDak6Yhiz6XMQnIujN2XfXUBmzoYYxt6Vrv8 cq6dAiMZZzlXp3BVWWcEjKHIi7uVzD7FqPwNJpfTpAH06fHlSWtou1h6lNK47bViv3w8OURG+KuC D8wSsV4WrwpdrKazR+zT+y8xcxqfxk/wdNshNKaxe8uq+3ll+8E3z3SqjjiNBIjBoHxGZQbdq7tv X+7yq/gJXv0RayxmQzpygF36IFyXu3jJCHUJn+A9PB9wW6Lah4PE24SgK/idyPG0GHG+Lr0vsmzV e5hjLlC2+z3exUfjgU8A10QFBjklfhryudApEUaQGBBH7w4vzLj2cT5Hd0Uyhfm84xvnZALBhdmA /OpZ69ZtkkpXQCdZ3mO0Z7MecvXreTZKey93+83XRvVas6rVC+J3Lr1e/YhvwBqmul60XUQ+BGpW 07JLHtIv7z8cDt733p+e//SrmIs/DaDu05tXsOWKL733JSbrDdw1vZpGg/YXnlqWNuPebynsEgDY I6mLeeqIaBC3+z+YZbEnVJAo20dRYKHtfHY82BZpBKjEl3qwjwFrP8g9DP8OmM0c4C04J0mVjZRW N1hX8Hb4t98Aze2q8/5xX+29biZqcJMW8/Tbb95leV5flVW5oz58BKCfPw0Q3sUEtv2Bev1yv/d2 d6+3+/Z7VB2OgVXnB2qMnfW16vE/MfEu7w/LKb4Hb1bJl6SeWI3nwYOJjWXvzave7ne7r+1QZtxb P4Pe5EgknjaliD3VDUEL/qX/P+3/NoSd/Zekpv4/UEsBAhQLFAAAAAgAy1HtKkXPNWUwRAAA1TwB ACsAAAAAAAAAAQAgAAAAAAAAAGRyYWZ0LWFkcmFuZ2ktbWlwdjQtbWlkYm94LXRyYXZlcnNhbC0w MC50eHRQSwUGAAAAAAEAAQBZAAAAeUQAAAAA ------_=_NextPart_000_01C10FAA.B6F26380-- From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 18 13:16:48 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15460 for ; Wed, 18 Jul 2001 13:16: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 LAA25402; Wed, 18 Jul 2001 11:17:13 -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 KAA16240; Wed, 18 Jul 2001 10:16:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6IHEsp27928 for mobile-ip-dist; Wed, 18 Jul 2001 10:14:54 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6IHEoN27921 for ; Wed, 18 Jul 2001 10:14:50 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA29801 for ; Wed, 18 Jul 2001 10:15:03 -0700 (PDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA24651 for ; Wed, 18 Jul 2001 10:15:02 -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.11.0/8.11.0/WIREfire-1.3) with SMTP id f6IHF0N26136 for ; Wed, 18 Jul 2001 19:15:00 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed Jul 18 19:14:59 2001 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 18 Jul 2001 19:08:57 +0200 Message-ID: <795A014AF92DD21182AF0008C7A404320C52046E@esealnt117> From: "Karim El-Malki (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] proposed agenda Date: Wed, 18 Jul 2001 19:14:57 +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: Hello Phil > v6 Fast Handover draft-ietf-mobileip-fast-mipv6-01.txt > BETH addition? James 10 minutes draft-kempf-beth-ipv6-01.txt > Implementation experience report Rajeev Koodli 10 minutes This round there are 2 proposals for addition to v6 fast handoffs which are BETH (which also addresses BET w/bicasting: BETB) and a bicasting addition to the current fastv6 draft: draft-elmalki-mobileip-bicasting-v6-00.txt. Why is the bicasting draft not in the agenda? It is an unsolved issue from the v6 design team which we had planned to get WG feedback on as it did not make it into the draft. Rgds /Karim From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 18 13:48:14 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21132 for ; Wed, 18 Jul 2001 13:48:13 -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 KAA17616; Wed, 18 Jul 2001 10:48: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 KAA24559; Wed, 18 Jul 2001 10:48:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6IHkWi28071 for mobile-ip-dist; Wed, 18 Jul 2001 10:46:32 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6IHkTN28064 for ; Wed, 18 Jul 2001 10:46:29 -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 KAA04494 for ; Wed, 18 Jul 2001 10:46:42 -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 LAA21681 for ; Wed, 18 Jul 2001 11:46:40 -0600 (MDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f6IHkoe17377 for ; Wed, 18 Jul 2001 10:46: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 AAC02479; Wed, 18 Jul 2001 10:46:39 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA08497; Wed, 18 Jul 2001 10:46:39 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15189.52094.935416.608548@thomasm-u1.cisco.com> Date: Wed, 18 Jul 2001 10:46:38 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Dynamic Home Agent Address Discovery mechanism In-Reply-To: <57A26D272F67A743952F6B4371B8F81108C1D5@daebe007.NOE.Nokia.com> References: <57A26D272F67A743952F6B4371B8F81108C1D5@daebe007.NOE.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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Franck.Le@nokia.com writes: > Of course the use of a router on a network as an HA > definitely requires strong authentication in the BU. Is there any reason > why the same authentication requirements be not available for the > discovery message? There's no way to use IPsec to secure an anycast. What you're proposing is non-trivial which is why it needs a pretty significant amount of justification. Mike From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 18 14:37:54 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA01085 for ; Wed, 18 Jul 2001 14:37: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 MAA05038; Wed, 18 Jul 2001 12:38:14 -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 LAA22938; Wed, 18 Jul 2001 11:37:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6IIaln28261 for mobile-ip-dist; Wed, 18 Jul 2001 11:36:47 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6IIahN28254 for ; Wed, 18 Jul 2001 11:36:43 -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 LAA07227 for ; Wed, 18 Jul 2001 11:36:55 -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 MAA03669 for ; Wed, 18 Jul 2001 12:36: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 LAA20897 for ; Wed, 18 Jul 2001 11:36:53 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6IIaq815991 for ; Wed, 18 Jul 2001 11:36:52 -0700 X-mProtect: Wed, 18 Jul 2001 11:36:52 -0700 Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdLJeE9z; Wed, 18 Jul 2001 11:36:42 PDT Message-ID: <3B55D73A.51A6EE3A@iprg.nokia.com> Date: Wed, 18 Jul 2001 11:36:42 -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: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] proposed agenda References: <034BEFD03799D411A59F00508BDF754603008B07@esealnt448.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, We are working on FMIPv6 implementation. This is in a unix* platform. The talk is about the experiences in the on-going implementation. Regards, -Rajeev "Hesham Soliman (ERA)" wrote: > > v6 Fast Handover draft-ietf-mobileip-fast-mipv6-01.txt > > BETH addition? James 10 minutes draft-kempf-beth-ipv6-01.txt > > Implementation experience report Rajeev Koodli 10 minutes > > > => I'd be really interested to know if you have an implementation > of the Fast Handoff draft. Rajeev ? > Would you be able to give some information on the platform used > or (if open source) whether it could be downloaded from somewhere ? > > Thanks, > Hesham From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 18 14:42:59 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA02388 for ; Wed, 18 Jul 2001 14:42:58 -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 MAA09486; Wed, 18 Jul 2001 12:43: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 LAA24120; Wed, 18 Jul 2001 11:43:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6IIfuH28311 for mobile-ip-dist; Wed, 18 Jul 2001 11:41:56 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6IIfpN28304 for ; Wed, 18 Jul 2001 11:41:51 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA07184 for ; Wed, 18 Jul 2001 11:42:03 -0700 (PDT) Received: from tml-gw.tml.hut.fi (tml.hut.fi [130.233.44.1]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA07231 for ; Wed, 18 Jul 2001 11:42:02 -0700 (PDT) Received: (from smap@localhost) by tml-gw.tml.hut.fi (8.8.7/8.8.7) id VAA25166 for ; Wed, 18 Jul 2001 21:40:14 +0300 Received: from mail.tml.hut.fi(130.233.45.70) by tml-gw.tml.hut.fi via smap (V2.0) id xma025164; Wed, 18 Jul 01 21:40:09 +0300 Received: from morphine.tml.hut.fi (morphine.tml.hut.fi [130.233.45.7]) by mail.tml.hut.fi (8.11.0/8.11.0) with ESMTP id f6IIf9N23420 for ; Wed, 18 Jul 2001 21:41:09 +0300 (EEST) Received: from localhost (lpetande@localhost) by morphine.tml.hut.fi (8.11.3/8.11.3) with ESMTP id f6IIfjM05340 for ; Wed, 18 Jul 2001 21:41:45 +0300 (EET DST) X-Authentication-Warning: morphine.tml.hut.fi: lpetande owned process doing -bs Date: Wed, 18 Jul 2001 21:41:45 +0300 (EET DST) From: Lars Henrik Petander To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] new mipv6 draft and BSA 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 just read through the new Mobile IPv6 draft, but the role of binding security association is still somewhat unclear to me. When MN returns home and sends a deregistration BU to its HA and CNs will the BSAs be deleted along with the binding cache and binding update list entries? There might be potential problems with replayed or delayed packets, if the CNs and the HA delete their binding cache entries for the MN, but do not delete their BSA (and also the shared secret used for the session) for the MN. Regards, Henrik Petander From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 18 18:14:25 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA18378 for ; Wed, 18 Jul 2001 18:14:24 -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 QAA14340; Wed, 18 Jul 2001 16:14:56 -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 PAA11189; Wed, 18 Jul 2001 15:14:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6IMDNu28770 for mobile-ip-dist; Wed, 18 Jul 2001 15:13:23 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6IMDJN28763 for ; Wed, 18 Jul 2001 15:13:19 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA25769 for ; Wed, 18 Jul 2001 15:13:31 -0700 (PDT) Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA18892 for ; Wed, 18 Jul 2001 15:13:25 -0700 (PDT) Received: from HANSPC (sparcis.ipunplugged.com [10.0.1.163]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with SMTP id AAA05142 for ; Thu, 19 Jul 2001 00:14:57 +0200 From: =?iso-8859-1?Q?Hans_Sj=F6strand?= To: Subject: RE: [mobile-ip] draft-vaarala-mobileip-nat-traversal-00.txt -- NAT traversal using the Mobile IP port Date: Thu, 19 Jul 2001 00:12:27 +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.4133.2400 In-Reply-To: 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 > > > There is one implementation aspect to this which we haven't touched > > > on, where I believe our solution is slightly simpler/better than yours, > > > which is the following: Using other ports than 434, we don't have to > > > multiplex MIP control and data, so detunneling can be implemented as a > > > pure kernel activity, while in your case, the packets would have to be > > > looked at by the mip daemon or equivalent, to separate the control and > > > data streams. This drawback would exist equally for a standardised > > > solution using port 434 and a standardised MIP message type, too. > > > > I agree with this. Our Mobile IP implementation is kernel-based so there > > is no such problem, but I agree, this would limit implementation options > > and cause problems with some existing ones. A standard Mobile IP message > > type (or range) would allow the kernel part to automatically demux > > traffic, and would not need any configurable parameters as is the case > > with a negotiable traversal. > > > > > Alternatively, one could standardise a separate port for MIP UDP > > tunnelling. > > > > Yes. We need rough consensus on at least the following issues to start > > things moving: > > 1. Do we allocate a separate port? If so, what will we do if 434 is > > allowed but the port in question is not (universal deployment does > > not happen overnight) -- do we still need a port negotiation? > > For a general solution, my thinking at this moment is to go for primarily > a separate port, with fallback to 434 with a new message type permitted. Agree, I strongly think that a separate port should be used (and registered by IANA), mandating 434 is higly dangerous. Higher capacity routers _must_ handle the user plane in hardware, no compromise possible there. Forwarding user plane traffic of probably Gb/s of traffic to the slow path will for sure whack over any router on the market. The UDP tunnel must therefore be separated from the mip control plane , this has to be done already in HW. Since addressing can't be used, (the tunnel is decapsulated in the router) port numbers are whats left. Requiring the routers to look even further into the packets for markers are not viable in my mind, not with todays ASICs etc. The solution must be implementable on todays router plattforms. There is also the case where the HA is only acting as a signalling proxy, then the user traffic should be switched to another router. You don't want that traffic up to the signalling proxy. But, as you point out, change is gradual. Port "negotiating" (more of a handshake really as proposed) is therefore a good thing to get through conservative firewalls. Regards /// Hasse From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 18 18:25:54 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA20293 for ; Wed, 18 Jul 2001 18:25: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 PAA22554; Wed, 18 Jul 2001 15:26: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 PAA13428; Wed, 18 Jul 2001 15:25:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6IMOSw28846 for mobile-ip-dist; Wed, 18 Jul 2001 15:24:28 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6IMOON28839 for ; Wed, 18 Jul 2001 15:24:25 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA27681 for ; Wed, 18 Jul 2001 15:24:31 -0700 (PDT) Received: from hypnos.cps.intel.com (hypnos.cps.intel.com [192.198.165.17]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA24103 for ; Wed, 18 Jul 2001 15:24:21 -0700 (PDT) Received: from SMTP (fmsmsxvs03-1.fm.intel.com [132.233.42.203]) by hypnos.cps.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22 root Exp $) with SMTP id WAA17754 for ; Wed, 18 Jul 2001 22:23:50 GMT Received: from fmsmsx26.fm.intel.com ([132.233.48.26]) by 132.233.48.203 (Norton AntiVirus for Internet Email Gateways 1.0) ; Wed, 18 Jul 2001 22:23:50 0000 (GMT) Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 18 Jul 2001 15:23:49 -0700 Message-ID: <4148FEAAD879D311AC5700A0C969E890049A3023@orsmsx35.jf.intel.com> From: "Iyer, Prakash" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] proposed agenda Date: Wed, 18 Jul 2001 15:23:12 -0700 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: We now have many drafts addressing the problem of NAT and VPN traversal for mobile IP. Can we have a slot on the agenda to summarize these solutions and discuss WG next steps. -Prakash Intel Arch Labs From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 18 19:18:03 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA01684 for ; Wed, 18 Jul 2001 19:18: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 RAA23281; Wed, 18 Jul 2001 17:18: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 QAA08412; Wed, 18 Jul 2001 16:18:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6INH0e28971 for mobile-ip-dist; Wed, 18 Jul 2001 16:17:00 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6INGuN28956 for ; Wed, 18 Jul 2001 16:16:56 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA09884 for ; Wed, 18 Jul 2001 16:17:08 -0700 (PDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id QAA01877 for ; Wed, 18 Jul 2001 16:17:08 -0700 (PDT) Received: (qmail 15854 invoked by uid 500); 18 Jul 2001 23:06:15 -0000 Date: Wed, 18 Jul 2001 16:06:14 -0700 From: Pat Calhoun To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] proposed agenda Message-ID: <20010718160614.I1139@charizard.diameter.org> References: <4148FEAAD879D311AC5700A0C969E890049A3023@orsmsx35.jf.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4148FEAAD879D311AC5700A0C969E890049A3023@orsmsx35.jf.intel.com>; from prakash.iyer@intel.com on Wed, Jul 18, 2001 at 03:23:12PM -0700 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, Jul 18, 2001 at 03:23:12PM -0700, Iyer, Prakash wrote: > We now have many drafts addressing the problem of NAT and VPN traversal for > mobile IP. > Can we have a slot on the agenda to summarize these solutions and discuss WG > next steps. Discussing next steps, and understanding whether this is an area of work that the WG should add to its charter seems reasonable. However, summarizing the solutions can be done by simply reading the drafts. If folks care, they will read them. PatC From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 18 20:08:14 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA13647 for ; Wed, 18 Jul 2001 20:08:13 -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 SAA20003; Wed, 18 Jul 2001 18:08: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 RAA20466; Wed, 18 Jul 2001 17:08:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6J071029117 for mobile-ip-dist; Wed, 18 Jul 2001 17:07:01 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6J06wN29110 for ; Wed, 18 Jul 2001 17:06:58 -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 RAA20252 for ; Wed, 18 Jul 2001 17:07:11 -0700 (PDT) Received: from maile.telia.com (maile.telia.com [194.22.190.16]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA09442 for ; Wed, 18 Jul 2001 18:08:27 -0600 (MDT) Received: from parchment (h242n1fls33o801.telia.com [213.64.180.242]) by maile.telia.com (8.11.2/8.11.0) with SMTP id f6J077c02393 for ; Thu, 19 Jul 2001 02:07:07 +0200 (CEST) From: "Henrik Levkowetz" To: Subject: RE: [mobile-ip] Slot on the agenda - Nat traversal? (Was: proposed agenda) Date: Thu, 19 Jul 2001 02:07:06 +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: <20010718160614.I1139@charizard.diameter.org> X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 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 Pat, I agree. Furthermore, from the amount of comments so far, it would seem that although important to those concerned (including myself), the number of people interested in this topic at this time is fairly limited. Possibly a bar BOF or similar would get us moving forward quite as well as time on the MIP workgroup agenda, except that maybe some agenda time might be needed to understand whether this should be an area of work for the workgroup. Best, Henrik PatC wrote: > > On Wed, Jul 18, 2001 at 03:23:12PM -0700, Iyer, Prakash wrote: > > We now have many drafts addressing the problem of NAT and VPN traversal for > > mobile IP. > > Can we have a slot on the agenda to summarize these solutions and discuss WG > > next steps. > Discussing next steps, and understanding whether this is an area of work > that the WG should add to its charter seems reasonable. However, summarizing > the solutions can be done by simply reading the drafts. If folks care, they > will read them. > > PatC > From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 18 23:46:04 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA24776 for ; Wed, 18 Jul 2001 23:46:03 -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 VAA27181; Wed, 18 Jul 2001 21:46: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 UAA01192; Wed, 18 Jul 2001 20:46:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6J3j4p00589 for mobile-ip-dist; Wed, 18 Jul 2001 20:45:04 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6J3j0000582 for ; Wed, 18 Jul 2001 20:45:01 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA01128 for ; Wed, 18 Jul 2001 20:45:12 -0700 (PDT) Received: from tama5.ecl.ntt.co.jp (tama5.ecl.ntt.co.jp [129.60.39.102]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA05002 for ; Wed, 18 Jul 2001 20:45:11 -0700 (PDT) Received: from nttmail3.ecl.ntt.co.jp (nttmail3.ecl.ntt.co.jp [129.60.39.100]) by tama5.ecl.ntt.co.jp (8.9.3+3.2W/3.7W/01/21/00) with ESMTP id MAA19709 for ; Thu, 19 Jul 2001 12:45:10 +0900 (JST) (envelope-from ohnishi.hiroyuki@lab.ntt.co.jp) Received: from eclscan3.m.ecl.ntt.co.jp by nttmail3.ecl.ntt.co.jp (8.9.3+3.2W/3.7W/03/21/01) with ESMTP id MAA08862 for ; Thu, 19 Jul 2001 12:45:09 +0900 (JST) (envelope-from ohnishi.hiroyuki@lab.ntt.co.jp) Received: from imd.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id MAA00101 for ; Thu, 19 Jul 2001 12:45:09 +0900 (JST) Received: from ohnishi-gw.lab.ntt.co.jp ([129.60.10.130]) by imd.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id MAA05028 for ; Thu, 19 Jul 2001 12:45:09 +0900 (JST) Message-Id: <4.3.2-J.20010719124533.02d7fd60@imd.m.ecl.ntt.co.jp> X-Sender: ho005@imd.m.ecl.ntt.co.jp X-Mailer: QUALCOMM Windows Eudora Version 4.3.2-J Date: Thu, 19 Jul 2001 12:45:42 +0900 To: mobile-ip@sunroof.eng.sun.com From: Hiroyuki OHNISHI Subject: [mobile-ip] test 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: From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 19 00:11:56 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA01077 for ; Thu, 19 Jul 2001 00:11:55 -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 WAA07884; Wed, 18 Jul 2001 22:12: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 VAA03518; Wed, 18 Jul 2001 21:12:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6J4B6l00653 for mobile-ip-dist; Wed, 18 Jul 2001 21:11:06 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6J4B2000646 for ; Wed, 18 Jul 2001 21:11:02 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA25989 for ; Wed, 18 Jul 2001 21:11:14 -0700 (PDT) Received: from tama5.ecl.ntt.co.jp (tama5.ecl.ntt.co.jp [129.60.39.102]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA00722 for ; Wed, 18 Jul 2001 21:11:09 -0700 (PDT) Received: from nttmail3.ecl.ntt.co.jp (nttmail3.ecl.ntt.co.jp [129.60.39.100]) by tama5.ecl.ntt.co.jp (8.9.3+3.2W/3.7W/01/21/00) with ESMTP id NAA27022 for ; Thu, 19 Jul 2001 13:11:08 +0900 (JST) (envelope-from ohnishi.hiroyuki@lab.ntt.co.jp) Received: from eclscan3.m.ecl.ntt.co.jp by nttmail3.ecl.ntt.co.jp (8.9.3+3.2W/3.7W/03/21/01) with ESMTP id NAA17644 for ; Thu, 19 Jul 2001 13:11:08 +0900 (JST) (envelope-from ohnishi.hiroyuki@lab.ntt.co.jp) Received: from imd.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id NAA02029 for ; Thu, 19 Jul 2001 13:11:07 +0900 (JST) Received: from ohnishi-gw.lab.ntt.co.jp ([129.60.10.130]) by imd.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id NAA07085 for ; Thu, 19 Jul 2001 13:11:06 +0900 (JST) Message-Id: <4.3.2-J.20010719131114.02dce2d0@imd.m.ecl.ntt.co.jp> X-Sender: ho005@imd.m.ecl.ntt.co.jp X-Mailer: QUALCOMM Windows Eudora Version 4.3.2-J Date: Thu, 19 Jul 2001 13:11:39 +0900 To: mobile-ip@sunroof.eng.sun.com From: Hiroyuki OHNISHI Subject: Re: [mobile-ip] re:draft-ohnishi-mobileip-mbg-00.txt 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: Hi, At 17:23 01/07/17 -0500, you wrote: >Hiroyuki and Yasushi, > >In reference to your draft: > >http://www.ietf.org/internet-drafts/draft-ohnishi-mobileip-mbg-00.txt > > >I have a few questions and comments: > >Would the MGBs be similar or perhaps even the same border routers between >autonomous systems of 2 ISPs such as two cellular ISPs? MBGs are located as border routers between ISPs. But MBGs have Mobile IP functions and they are not same as ordinary border routers. >What signaling protocol are you looking at to distribute the fact that >the address ranges are mobile address from the HA to the MGBs: BGP, OSPF, >IS-IS or do you feel that this can be done with simple configuration? In this version of this draft, I assume that the address ranges are set with simple configuration. Because I want to control MBGs and HAs strictly to support stable security associations. But I also recognize the necessity of the distribution techniques. I am not sure whether the use of routing protocol to distribute the address ranges of mobile nodes is appropriate or not. Is there any comments? >It seems to me that the conveyance of this information would also >constitute an IP roaming agreement. An automatic, routing protocol-based >way of setting these up would be of benefit IMO. Furthurmore, I believe >some similar work should be done to identify geographical adjacency for >handoff purposes. I also want to know answers of the following questions. This draft provides a realistic way to achieve route optimization without adding any functions to CNs. And this technique will help ISPs to provide Mobile IP services. I hope many folks will be interested in this work. Comments are welcome. >Question to the chairs and/or ADs: > > >Would this work fall under MIP WG or routing WGs? > >Are you planning any follow-up work on this? > >The expect that the antagonists to this draft may complain about the >number of per-node routes and what this will do to the routing table size. >Last time I checked route lookups were pretty fast in most of the newer >products - even with fairly large routing tables; nevertheless, I expect >there to be some contention on this. Has there been any analysis on this? > >Some positive comments I have on this is that it does indeed seem to be a >very realistic deployment method for route optimization. I have not heard >of any plans to support route optimization on IPv4 hosts by any of the >major OS vendors. It makes sense to me to distribute the fact that certain >addresses are mobile to portions of the network. I honestly believe that >there are other reasons such as location privacy to maintain the mobile >bindings in routers as well. I believe that such functions are better left >in purpose built machines that handle handle fast lookups on relatively >large route tables. Some analysis on this aspect would also be useful? > >Another thing I would like to bring up to folks on the list is that even >in IPv6, there is no MUST that CN hosts support the binding functions of >MIPv6. With this in mind, I expect there will be nodes out there that >don't do it. So even in IPv6, the ubiquity of route optimization is still >in question. This gives credence to the reasoning for the solution in IPv6 >as well. > >Another thing I would like to point out that the signaling methodology >seems quite similar, as far as the MGP querying the HA for the binding, to >some the initial work on the GES, 8+8 concepts. You seem to be doing the >query without having to changing the IP header or mess with the addressing >schemas - a bonus IMHO. The fact that you are using the mobile IP HA >instead of something like DNS is also a good idea IMO due to speed and an >already overloaded DNS. > >It also seems to me that this would allow IPv4 ISPs to offer the service >without having to fork-lift all of their clients' host operating systems. >A money saving and realistic idea. >On the analysis questions - are there any papers available which explore >these topics you could point us to? > >Thanks, > >Glenn Thanks, Hiroyuki From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 19 03:27:55 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA22870 for ; Thu, 19 Jul 2001 03:27:54 -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 BAA21938; Thu, 19 Jul 2001 01:28: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 AAA21048; Thu, 19 Jul 2001 00:28:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6J7R1h01048 for mobile-ip-dist; Thu, 19 Jul 2001 00:27:01 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6J7Qu001041 for ; Thu, 19 Jul 2001 00:26:56 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA20978 for ; Thu, 19 Jul 2001 00:27:10 -0700 (PDT) Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA22139 for ; Thu, 19 Jul 2001 00:27:10 -0700 (PDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate4.mot.com (motgate4 2.1) with ESMTP id AAA15819 for ; Thu, 19 Jul 2001 00:27:09 -0700 (MST)] Received: [from m-il06-r3.mot.com (m-il06-r3.mot.com [129.188.137.194]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id AAA01244 for ; Thu, 19 Jul 2001 00:27:09 -0700 (MST)] Received: from [140.101.173.9] by m-il06-r3.mot.com with ESMTP for mobile-ip@sunroof.eng.sun.com; Thu, 19 Jul 2001 00:26:52 -0700 Received: (from root@localhost) by zorglub.crm.mot.com (8.8.8/8.8.8/crm-1.6) id JAA04378 for mobile-ip@sunroof.eng.sun.com.DELIVER; Thu, 19 Jul 2001 09:26:58 +0200 (METDST) Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by zorglub.crm.mot.com (8.8.8/8.8.8/crm-1.6) with ESMTP id JAA04310 for ; Thu, 19 Jul 2001 09:26:57 +0200 (METDST) To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Comments on mipv6 threat model References: From: Alexandru Petrescu Date: 19 Jul 2001 09:26:56 +0200 In-Reply-To: Message-Id: Lines: 54 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.0.103 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 shouldn't follow-up to my own posts, and this is long. The amount of available information to the attacker should somehow be quantified and/or ordered. E.g. an attacker has to pay a lesser dollar price in order to listen to a wireless broadcast media and a higher dollar price to install himself on the HA subnet. Each damage (realization of threats) should be quantified and/or ordered. E.g. a DoS attack on the MN is undesirable but an MITM is worse. A threat model should be more related to a real world environment, media access type, inter- or intra-operator, how often do handovers happen. Something along the lines of an evoluated RFC2005 (Applicability Statement for MIP). A threat model should refrain from even suggesting solutions, like in "should be authorized" or "should have an SA". In the draft, for each threat, there's scenario, threat, reaction, effect, requirement. The requirements should probably be left off. The "effects" are in fact "risks" and should be deduced later, not at the same time as building the threat model. Location privacy can be violated not only by means of Binding Requests (threat D.2) but also by means of sending tunnelled packets supposedly coming from the HA as redirections from a CN not having a binding cache entry for this MN. (page 98 last paragraph of MIPv6-14). E.g. an attacker CN builds a tunnelled packet that would come via the HA from a CN that does not have a binding for the victim MN. In this packet the attacker puts its address as the source address in the inner packet. I'm wondering if I'm right on this one. Threat G.1 too much related to B.3. If I were to exploit "forwarding from a previous CoA" I would mount the following... Consider MN1 and MN2 (MN2 is the victim), attacker AT, oldAR and newAR, TRD is a tunnelled redirected packet, the sort that the CN sends to an MN through the HA, for which MN has no entry in binding cache. Now, MN1 moves from oldAR to newAR. MN1 establishes binding for CoA at oldAR. AT sends fake BU to oldAR and removes binding of CoA. MN2 shows up under oldAR and obtains CoA. AT sends TRD to MN1 such that MN1 sends BU of CoA to CN towards MN1, and not towards the legitimate MN2. Thus MN1 "attacks" MN2, all indirectly provoked by AT. Threat G.1 assumes that AR defends a certain address that is also defended by MN, on the same link. What will DAD give? "Functional requirements"? Like in the following. If a legitimate MN knows that it could only send BU's according to the rate limiting restriction, it has no reason to try to process and respond to an incoming flood of binding requests. Thus this kind of particular flooding (resource exhaustion) threat can be dealt with without authentication requirements. Alex From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 19 03:52:44 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA25682 for ; Thu, 19 Jul 2001 03:52:43 -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 AAA02984; Thu, 19 Jul 2001 00:53: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 AAA08973; Thu, 19 Jul 2001 00:52:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6J7pPU01131 for mobile-ip-dist; Thu, 19 Jul 2001 00:51:25 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6J7pL001124 for ; Thu, 19 Jul 2001 00:51:21 -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 AAA08818 for ; Thu, 19 Jul 2001 00:51:21 -0700 (PDT) Received: from ns2.iaf.fi (ns2.iaf.fi [195.94.103.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA10606 for ; Thu, 19 Jul 2001 01:52:37 -0600 (MDT) Received: from proxyfw.netseal.com (gw.netseal.com [195.94.100.110]) by ns2.iaf.fi (8.11.2/8.11.2) with ESMTP id f6J7kfL03016 for ; Thu, 19 Jul 2001 10:46:42 +0300 Received: from (Undisclosed Firewall protected host) by Baudia Firewall with SMTP id KAA03013 for ; Thu, 19 Jul 2001 10:10:06 +0300] Message-ID: <006601c11027$f9f5d090$3f02a8c0@garibaldi> From: "Sami Vaarala" To: References: Subject: Re: [mobile-ip] draft-vaarala-mobileip-nat-traversal-00.txt -- NAT traversal using the Mobile IP port Date: Thu, 19 Jul 2001 10:54:00 +0300 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.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 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: X-MIME-Autoconverted: from 8bit to quoted-printable by mercury.Sun.COM id AAA02984 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA25682 Hans, From: "Hans Sjöstrand" > > For a general solution, my thinking at this moment is to go for primarily > > a separate port, with fallback to 434 with a new message type permitted. > > Agree, I strongly think that a separate port should be used (and registered > by IANA), mandating 434 is higly dangerous. Do you mean that it is dangerous as a protocol design feature, or dangerous to existing specifications and/or implementations? > Higher capacity routers _must_ handle the user plane in hardware, no > compromise possible there. Forwarding user plane traffic of probably Gb/s of > traffic to the slow path will for sure whack over any router on the market. I agree. > The UDP tunnel must therefore be separated from the mip control plane , this > has to be done already in HW. Since addressing can't be used, (the tunnel is > decapsulated in the router) port numbers are whats left. Requiring > the routers to look even further into the packets for markers are > not viable in my mind, not with todays ASICs etc. The solution must be > implementable on todays router plattforms. This is true as far as existing, hardware based HAs are concerned. However, not all HAs are hardware-based, and I think it is not good to add extra latency and the associated UDP port decision problems (which traversal port will work thru this set of random, third party routers) to all HAs (software or hardware) only because some existing implementations might not be able to support a traversal mode based on using port 434. Since mobile nodes are practically always modifiable (ie software), we could define a protocol that allowed the HA to decide which traversal method (434 or other) is used. This would allow "modifiable" HAs to use the port 434, which provides faster handovers and more predictable traversal behavior, while existing hardware-based implementations that cannot perform multiplexing beyond address/protocol/port could use a separate port. The MNs would have to support both, but this does not seem to be a major issue. This is indeed what Henrik suggested. The protocol would then go something like this: 1. MN indicates support for traversal, and MAY a. Request that traversal be used regardless of NAT existence b. Indicate which port it would like to use, if possible. Port 434 would indicate that a (standardized) marker is used, and another port would indicate direct tunnelling. 2. HA performs NAT detection (and takes the 1.a. flag into account) and assigns a traversal port if it determines traversal is needed. Port number semantics the same as in 1. The HA could also assign a keepalive interval. 3. Data tunnelling begins. This would combine the features of both drafts, and would support both types of HAs. HAs would only have to support a given NAT traversal method or port. There is still the issue of lost keepalive packet in case of non-434 traversal, in which case the NAT mapping is not formed. If the MN has no data to send, HA-to-MN data will not flow, until the MN resends the keepalive (which can be long), or until actual data is sent. How about the following: - If the HA does not receive a keepalive/data packet to the assigned port, it sends a Mobile IP message that requests resend of a keepalive packet. - This packet would use the same message type that is used for tunnelling, we would have a special flag for "keepalive request". The HA would set a short timer for the initial keepalive (eg 3 seconds). Upon expiration, it would send a keepalive request, and keep resending for a number of times, until the first keepalive (or data packet) has been received. After that, the server never sends the keepalive request. The loss of a keepalive request causes a resend of such a request, and should not cause arbitrarily long traffic blackholes. The keepalive request would only be used in case of non-434 port. It should be implementable in hardware, because you would only catch packets the to the data tunnelling port until you got the first packet (which confirms to some extent that the NAT mapping was formed) and then stop catching the packets. How does this sound? Best regards, -Sami -- Sami Vaarala Senior Software Architect NetSeal Technologies From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 19 07:07:28 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA29093 for ; Thu, 19 Jul 2001 07:07: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 FAA17969; Thu, 19 Jul 2001 05:07:49 -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 EAA23089; Thu, 19 Jul 2001 04:07:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6JB6D001416 for mobile-ip-dist; Thu, 19 Jul 2001 04:06:13 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6JB68001409 for ; Thu, 19 Jul 2001 04:06:08 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA06332 for ; Thu, 19 Jul 2001 04:06:20 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA00833 for ; Thu, 19 Jul 2001 04:06:19 -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 HAA28105; Thu, 19 Jul 2001 07:05:22 -0400 (EDT) Message-Id: <200107191105.HAA28105@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-elmalki-mobileip-bicasting-v6-00.txt Date: Thu, 19 Jul 2001 07:05:21 -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. Title : Simultaneous Bindings for Mobile IPv6 Fast Handoffs Author(s) : K. Malki, H. Soliman Filename : draft-elmalki-mobileip-bicasting-v6-00.txt Pages : 10 Date : 18-Jul-01 Fast Handover for Mobile IPv6 [Fastv6] describes a protocol to minimise the amount of service disruption when performing layer-3 handoffs. This draft extends this protocol by adding the simultaneous bindings functionality as a handoff smoothing technique. Traffic for the MN is therefore bicast or n-cast for a short period to its current location and to one or more locations where the MN is expected to move to shortly. This removes the timing ambiguity regarding when to start sending traffic for the MN to its new point of attachment and allows the decoupling of layer-2 and layer-3 handoffs. It also saves the MN periods of service disruption in the case of ping-pong movement. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-elmalki-mobileip-bicasting-v6-00.txt 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-elmalki-mobileip-bicasting-v6-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-elmalki-mobileip-bicasting-v6-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: <20010718142141.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-elmalki-mobileip-bicasting-v6-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-elmalki-mobileip-bicasting-v6-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010718142141.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 19 07:07:46 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA29207 for ; Thu, 19 Jul 2001 07:07:45 -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 EAA03603; Thu, 19 Jul 2001 04:08:04 -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 EAA23027; Thu, 19 Jul 2001 04:06:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6JB5Ah01395 for mobile-ip-dist; Thu, 19 Jul 2001 04:05:10 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6JB56001388 for ; Thu, 19 Jul 2001 04:05: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 EAA27351 for ; Thu, 19 Jul 2001 04:05:17 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA16592 for ; Thu, 19 Jul 2001 05:05: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 HAA27762; Thu, 19 Jul 2001 07:04:20 -0400 (EDT) Message-Id: <200107191104.HAA27762@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-williams-mobileip-lmm-requirements-00.txt Date: Thu, 19 Jul 2001 07:04:19 -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. Title : Localized Mobility Management Requirements Author(s) : C. Williams Filename : draft-williams-mobileip-lmm-requirements-00.txt Pages : 8 Date : 18-Jul-01 Mobile IP is required for hosts moving within the Internet topology. Mobile IP manages IP mobility resulting from the change in Care-of-Address when a host moves within the Internet topology. When a Mobile Node moves from one point of attachment to another, a mobility binding update to the respective home agent and/or correspondent node(s) occurs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-williams-mobileip-lmm-requirements-00.txt 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-williams-mobileip-lmm-requirements-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-williams-mobileip-lmm-requirements-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: <20010718141948.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-williams-mobileip-lmm-requirements-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-williams-mobileip-lmm-requirements-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010718141948.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 19 07:10:33 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA29780 for ; Thu, 19 Jul 2001 07:10:33 -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 EAA04687; Thu, 19 Jul 2001 04:10: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 EAA23437; Thu, 19 Jul 2001 04:10:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6JB9gP01485 for mobile-ip-dist; Thu, 19 Jul 2001 04:09:42 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6JB9b001478 for ; Thu, 19 Jul 2001 04:09:37 -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 EAA20701 for ; Thu, 19 Jul 2001 04:09:49 -0700 (PDT) Received: from mail.zrz.tu-berlin.de (mail.zrz.TU-Berlin.DE [130.149.4.15]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA28856 for ; Thu, 19 Jul 2001 05:11:06 -0600 (MDT) Received: from ftsu07.ee.tu-berlin.de ([130.149.49.87] helo=ftmail.ee.tu-berlin.de) by mail.zrz.tu-berlin.de with esmtp (exim-3.31) for id 15NBgg-00058a-00; Thu, 19 Jul 2001 13:09:46 +0200 Received: from ee.tu-berlin.de (fu@sinope.ee.TU-Berlin.DE [130.149.49.127]) by ftmail.ee.tu-berlin.de (8.11.3/8.11.3) with ESMTP id f6JB9kh24829 for ; Thu, 19 Jul 2001 13:09:46 +0200 Message-ID: <3B56BFFA.9A70F398@ee.tu-berlin.de> Date: Thu, 19 Jul 2001 13:09:46 +0200 From: Xiaoming Fu Organization: Telecommunication Networks Group, TU-Berlin X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.14 i686) X-Accept-Language: en-US, de, zh-CN MIME-Version: 1.0 To: "mobile-ip@sunroof.eng.sun.com" Subject: [mobile-ip] draft-tkn-mobileip-qosbinding-mipv6-00.txt Content-Type: text/plain; charset=gb2312 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, Recently we have proposed a new idea on QoS for MIP. This work is based on HMIPv6 and follows the concept of the QoS option presented by draft-chaskar-mobileip-qos-01.txt (H. Chaskar, etc). The difference lies on that we update a binding status only when QoS requirements are met, i.e., QoS-conditionalized. We also compared it with the WG draft "Requirements of a QoS Solution for Mobile IP". Any comments, suggestions, or critics are welcome. Xiaoming Fu A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : QoS-Conditionalized Binding Update in Mobile IPv6 Author(s) : A. Festag et al. Filename : draft-tkn-mobileip-qosbinding-mipv6-00.txt Pages : 29 Date : 16-Jul-01 Abstract This draft presents a scheme for QoS support in Mobile IPv6 based on the architecture of Hierarchical Mobile IPv6. A QoS option, a hop- by-hop header extension option first presented by Chaskar et al. [6], is carried in the message containing the Binding Update (BU) option to the mobility anchor point (MAP). Handoffs are conditionalized upon the availability of sufficient resources in the route between MN and MAP to meet QoS requirements. When sufficient resources are not available and there is more than one new access router, the procedure can be reiterated. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-tkn-mobileip-qosbinding-mipv6-00.txt From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 19 09:54:06 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA03965 for ; Thu, 19 Jul 2001 09:54:04 -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 GAA28292; Thu, 19 Jul 2001 06:54: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 GAA13889; Thu, 19 Jul 2001 06:53:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6JDqAh01811 for mobile-ip-dist; Thu, 19 Jul 2001 06:52:10 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6JDq7001804 for ; Thu, 19 Jul 2001 06:52:07 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA05859 for ; Thu, 19 Jul 2001 06:52:20 -0700 (PDT) From: Franck.Le@nokia.com Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA29628 for ; Thu, 19 Jul 2001 06:52:19 -0700 (PDT) Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f6JDr2I12673 for ; Thu, 19 Jul 2001 08:53:03 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Thu, 19 Jul 2001 08:52:19 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.1600); Thu, 19 Jul 2001 08:52:18 -0500 content-class: urn:content-classes:message Subject: RE: [mobile-ip] Dynamic Home Agent Address Discovery mechanism Date: Thu, 19 Jul 2001 08:52:18 -0500 Message-ID: <57A26D272F67A743952F6B4371B8F81106AD78@daebe007.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 Thread-Topic: [mobile-ip] Dynamic Home Agent Address Discovery mechanism Thread-Index: AcEPsdDqCAjcO3ulEdWBSQBQi2X+DwAp3LBg To: X-OriginalArrivalTime: 19 Jul 2001 13:52:18.0947 (UTC) FILETIME=[06C09530:01C1105A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f6JDq7001805 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 As Mobile IPv6 defines its own built-in security mechanism (please see the Binding Update format of the last version of the draft - section 5.1), we do not have to use IPsec but, in the same way, the ICMP Home Agent address Discovery Request message could embed some own specific security mechanism. -----Original Message----- From: ext Michael Thomas [mailto:mat@cisco.com] Sent: 18 July, 2001 12:47 PM To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Dynamic Home Agent Address Discovery mechanism Franck.Le@nokia.com writes: > Of course the use of a router on a network as an HA > definitely requires strong authentication in the BU. Is there any reason > why the same authentication requirements be not available for the > discovery message? There's no way to use IPsec to secure an anycast. What you're proposing is non-trivial which is why it needs a pretty significant amount of justification. Mike From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 19 09:59:29 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA04975 for ; Thu, 19 Jul 2001 09:59:29 -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 GAA00700; Thu, 19 Jul 2001 06:59:54 -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 GAA14432; Thu, 19 Jul 2001 06:59:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6JDwPC01856 for mobile-ip-dist; Thu, 19 Jul 2001 06:58:25 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6JDwL001849 for ; Thu, 19 Jul 2001 06:58:21 -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 GAA14050 for ; Thu, 19 Jul 2001 06:58:35 -0700 (PDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA25533 for ; Thu, 19 Jul 2001 07:58:31 -0600 (MDT) Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f6JDwVO08506 for ; Thu, 19 Jul 2001 15:58:32 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Thu Jul 19 15:58:27 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Thu, 19 Jul 2001 15:58:31 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008B1D@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Dynamic Home Agent Address Discovery mechanism Date: Thu, 19 Jul 2001 15:58:21 +0200 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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > As Mobile IPv6 defines its own built-in security mechanism (please see > the Binding Update format of the last version of the draft - section > 5.1), we do not have to use IPsec but, in the same way, the ICMP Home > Agent address Discovery Request message could embed some own specific > security mechanism. > => I believe IPsec is needed and will work for the HA. The problems highlighted for MIPv6 / IPsec are not really applicable for the HA. In particular the key exchange mechanism. This can be preconfigured in the MN. Strong authentication to the HA should be supprted IMHO. Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 19 10:17:29 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09874 for ; Thu, 19 Jul 2001 10:17:29 -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 HAA08229; Thu, 19 Jul 2001 07: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 HAA16878; Thu, 19 Jul 2001 07:17:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6JEG4N01952 for mobile-ip-dist; Thu, 19 Jul 2001 07:16:04 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6JEG0001942 for ; Thu, 19 Jul 2001 07:16: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 HAA16436 for ; Thu, 19 Jul 2001 07:16:11 -0700 (PDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA24352 for ; Thu, 19 Jul 2001 08:17:30 -0600 (MDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f6JEGIe21333 for ; Thu, 19 Jul 2001 07:16:18 -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 AAC21399; Thu, 19 Jul 2001 07:16:09 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA08792; Thu, 19 Jul 2001 07:16:09 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15190.60329.73842.522790@thomasm-u1.cisco.com> Date: Thu, 19 Jul 2001 07:16:09 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Dynamic Home Agent Address Discovery mechanism In-Reply-To: <57A26D272F67A743952F6B4371B8F81106AD78@daebe007.NOE.Nokia.com> References: <57A26D272F67A743952F6B4371B8F81106AD78@daebe007.NOE.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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Franck.Le@nokia.com writes: > As Mobile IPv6 defines its own built-in security mechanism (please see > the Binding Update format of the last version of the draft - section > 5.1), we do not have to use IPsec but, in the same way, the ICMP Home > Agent address Discovery Request message could embed some own specific > security mechanism. 1) The current draft does not specify any mechanism so it's impossible to tell whether it's an appropriate mechanism for HA discovery. I wouldn't make that assumption. 2) The HA/MN security association should be able to use IPsec as before; the problem was the selector for multiple IP level protocol headers when piggyback BU's to CN's. Use of AH or ESP to the HA (see draft-thomas-mobileip-esp-bu-00.txt) with a single BU in the packet should work fine with existing IPsec implementations that support normal 5-tuple selectors. (ie, are 240[7-9] compliant). 3) I really don't understand why the draft put in a BU SA field, or the authdata field since there is no consensus on that and the requirements draft was just published. Nor do I see why the current draft needs to state requirements in section 4.4 Mike > > -----Original Message----- > From: ext Michael Thomas [mailto:mat@cisco.com] > Sent: 18 July, 2001 12:47 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: RE: [mobile-ip] Dynamic Home Agent Address Discovery mechanism > > > Franck.Le@nokia.com writes: > > Of course the use of a router on a network as an HA > > definitely requires strong authentication in the BU. Is there any > reason > > why the same authentication requirements be not available for the > > discovery message? > > There's no way to use IPsec to secure an anycast. > > What you're proposing is non-trivial which is why > it needs a pretty significant amount of justification. > > Mike From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 19 10:37:08 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12770 for ; Thu, 19 Jul 2001 10:37:07 -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 IAA24738; Thu, 19 Jul 2001 08:37: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 HAA19507; Thu, 19 Jul 2001 07:37:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6JEZrN02024 for mobile-ip-dist; Thu, 19 Jul 2001 07:35:54 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6JEZo002017 for ; Thu, 19 Jul 2001 07:35:50 -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 HAA25961 for ; Thu, 19 Jul 2001 07:36:02 -0700 (PDT) Received: from hotmail.com (f201.law7.hotmail.com [216.33.237.201]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA05466 for ; Thu, 19 Jul 2001 08:37:18 -0600 (MDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 19 Jul 2001 07:36:00 -0700 Received: from 206.170.35.222 by lw7fd.law7.hotmail.msn.com with HTTP; Thu, 19 Jul 2001 14:36:00 GMT X-Originating-IP: [206.170.35.222] From: "Hemant Chaskar" To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] draft-tkn-mobileip-qosbinding-mipv6-00.txt Date: Thu, 19 Jul 2001 14:36:00 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 19 Jul 2001 14:36:00.0398 (UTC) FILETIME=[214242E0:01C11060] 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 Xiaoming: The addition of resource allocation status bits and the two levels of QoS - desired and acceptable, to QoS object are good additions to the scheme. You have mentioned that this scheme has low signaling overhead. I would also like to add that it has less latency in QoS re-establishment along the new path. Also it is possible to use more optmized procedures for refreshing the QoS state. Regarding D bit: The natural question is what happens if the two way paths are assymetric? I think there is a more efficient way to refresh the QoS states if any, after QoS object is included in the first BU. One can assign a small ID to QoS object calculated as, for example, the hash of QoS object by MN-specific (and private) key such as password. Then we only send this ID as h-b-h options in some data packets at regular intervals. That way it will refresh the state and not waste wireless bandwidth for refresh. You draft says that the QoS object can be transferred from old AR to new AR by context tranfer framework. In that case, who sends BU to MAP? In other words, it is not possible that the MN sends BU and AR "fills in" the QoS object h-b-h option as it changes IP packet length and disturbs the authentication calculation. Hemant >From: Xiaoming Fu >Reply-To: mobile-ip@sunroof.eng.sun.com >To: "mobile-ip@sunroof.eng.sun.com" >Subject: [mobile-ip] draft-tkn-mobileip-qosbinding-mipv6-00.txt >Date: Thu, 19 Jul 2001 13:09:46 +0200 > >Hi, > >Recently we have proposed a new idea on QoS for MIP. This >work is based on HMIPv6 and follows the concept of the QoS >option presented by draft-chaskar-mobileip-qos-01.txt >(H. Chaskar, etc). The difference lies on that we update a >binding status only when QoS requirements are met, >i.e., QoS-conditionalized. > >We also compared it with the WG draft "Requirements of a >QoS Solution for Mobile IP". > >Any comments, suggestions, or critics are welcome. > >Xiaoming Fu > > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : QoS-Conditionalized Binding Update in Mobile >IPv6 > Author(s) : A. Festag et al. > Filename : draft-tkn-mobileip-qosbinding-mipv6-00.txt > Pages : 29 > Date : 16-Jul-01 > >Abstract > This draft presents a scheme for QoS support in Mobile IPv6 based on > the architecture of Hierarchical Mobile IPv6. A QoS option, a hop- > by-hop header extension option first presented by Chaskar et al. > [6], is carried in the message containing the Binding Update (BU) > option to the mobility anchor point (MAP). Handoffs are >conditionalized > upon the availability of sufficient resources in the route between MN > and MAP to meet QoS requirements. When sufficient resources are not > available and there is more than one new access router, the procedure > can be reiterated. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-tkn-mobileip-qosbinding-mipv6-00.txt _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 19 10:50:36 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA15061 for ; Thu, 19 Jul 2001 10:50: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 IAA03792; Thu, 19 Jul 2001 08:49: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 HAA01330; Thu, 19 Jul 2001 07:49:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6JEmCl02076 for mobile-ip-dist; Thu, 19 Jul 2001 07:48:12 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6JEm8002069 for ; Thu, 19 Jul 2001 07:48:08 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA00962 for ; Thu, 19 Jul 2001 07:48:20 -0700 (PDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA24154 for ; Thu, 19 Jul 2001 07:48:19 -0700 (PDT) Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f6JEmIO06655 for ; Thu, 19 Jul 2001 16:48:18 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Thu Jul 19 16:48:13 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Thu, 19 Jul 2001 16:48:17 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008B1F@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] recognising the source of a packet in MIPv6 Date: Thu, 19 Jul 2001 16:48:10 +0200 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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hello Dave, Charlie and all While updating the HMIPv6 draft I thought of a very simple optimisation for the MN to recognise whether a packet has been tunnelled by the HA, another node along the way (eg. MAP) or was sent directly from the CN. We've had it in the draft from the start but I think it would be good to generalise it. I believe it would be much easier for the MN to do a quick and simple check (instead of the currently specified check to see whether the packet was tunnelled or not): - Did the packet contain a routing header ? - Did the routing header contain the Home address of the MN as the last segment and its CoA (as specified in the BU list) ? If the answer to both is yes then the packet was route optimised. if no then it wasn't and it doesn't really matter whether it was tunnelled by THE HA or another node. This will have two advantages (outside the HMIPv6 area) : - Simpler processing in the kernel since the MIPv6 code would not have to "remember" whether the inner packet being processed now was originally tunnelled. - Will allow for future HA redundancy mechanisms because if the HA crashes and another HA starts tunnelling the packet the MN does not need to know or care. Excet of course when it's about to refresh the Binding Cache but that can be handled by the HA redundancy protocol. Note that this check is backward compatible. Ie. it doesn't affect anything on the wire and will still work if some MNs do it and others don't. Comments ? Regards, Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 19 11:44:16 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA27766 for ; Thu, 19 Jul 2001 11:44:15 -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 IAA17385; Thu, 19 Jul 2001 08:44: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 IAA14396; Thu, 19 Jul 2001 08:44:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6JFhNC02242 for mobile-ip-dist; Thu, 19 Jul 2001 08:43:23 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6JFhJ002235 for ; Thu, 19 Jul 2001 08:43:19 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA16722 for ; Thu, 19 Jul 2001 08:43:31 -0700 (PDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA20430 for ; Thu, 19 Jul 2001 08:43:31 -0700 (PDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f6JFhUN06157 for ; Thu, 19 Jul 2001 17:43:30 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Thu Jul 19 17:43:29 2001 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 19 Jul 2001 17:37:26 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008B21@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] draft-tkn-mobileip-qosbinding-mipv6-00.txt Date: Thu, 19 Jul 2001 17:43:23 +0200 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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hello Hemant, > You draft says that the QoS object can be transferred from old AR to new AR > by context tranfer framework. In that case, who sends BU to MAP? In other > words, it is not possible that the MN sends BU and AR "fills in" the QoS > object h-b-h option as it changes IP packet length and disturbs the > authentication calculation. > => This is one way of doing it and we are puttnig it in the appendix of HMIPv6: - oAR triggers the handover by sending a Prrtradv - In the mean time the oAR does the CT. Note that the oAR should already have the QoS objects/attributes. - The MN sends a BU, not to the oAR but to the MAP before it moves. This BU can include a H-B-H option. On another note, I'd like to ask you and the authors a stupid question :) why can't we reuse the router alert option for this instead of having a new option ? Regards, Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 19 12:00:08 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA00871 for ; Thu, 19 Jul 2001 12:00:07 -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 KAA03100; Thu, 19 Jul 2001 10:00:34 -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 JAA17325; Thu, 19 Jul 2001 09:00:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6JFx0e02320 for mobile-ip-dist; Thu, 19 Jul 2001 08:59:00 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6JFwv002313 for ; Thu, 19 Jul 2001 08:58:57 -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 IAA17034 for ; Thu, 19 Jul 2001 08:59:09 -0700 (PDT) From: Franck.Le@nokia.com Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA01772 for ; Thu, 19 Jul 2001 09:59:07 -0600 (MDT) Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f6JFxpI19248 for ; Thu, 19 Jul 2001 10:59:51 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Thu, 19 Jul 2001 10:59:08 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.1600); Thu, 19 Jul 2001 10:59:07 -0500 content-class: urn:content-classes:message Subject: [mobile-ip] FW: I-D ACTION:draft-le-aaa-diameter-mobileipv6-00.txt Date: Thu, 19 Jul 2001 10:59:07 -0500 Message-ID: <57A26D272F67A743952F6B4371B8F81106AD7F@daebe007.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 Thread-Topic: FW: I-D ACTION:draft-le-aaa-diameter-mobileipv6-00.txt Thread-Index: AcEQay+fVWBDr3wfEdWaKAAAhlNL6Q== To: , X-OriginalArrivalTime: 19 Jul 2001 15:59:07.0960 (UTC) FILETIME=[BE13D380:01C1106B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f6JFwv002314 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 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Diameter Mobile IPv6 Application Author(s) : S. Faccin et al. Filename : draft-le-aaa-diameter-mobileipv6-00.txt Pages : Date : 18-Jul-01 This document specifies a new Application to Diameter for Mobile IPv6, allowing an IPv6 mobile node to receive service from foreign service providers thanks to the support of inter domain roaming by the AAA infrastructure. The draft describes a solution that allows the Diameter infrastructure to authenticate and authorize an IPv6 mobile node, distribute security keys to enable the provisioning of services to the IPv6 mobile node, and perform and optimize mobility procedures for the IPv6 mobile node. A URL for this Internet-Draft is: Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-le-aaa-diameter-mobileipv6-00.txt". A list of Internet-Drafts directories can be found in or Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-le-aaa-diameter-mobileipv6-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 Jul 19 12:06:12 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02183 for ; Thu, 19 Jul 2001 12:06: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 KAA08201; Thu, 19 Jul 2001 10:06: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 JAA18610; Thu, 19 Jul 2001 09:06:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6JG5R102372 for mobile-ip-dist; Thu, 19 Jul 2001 09:05:27 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6JG5N002365 for ; Thu, 19 Jul 2001 09:05:23 -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 JAA26889 for ; Thu, 19 Jul 2001 09:05:35 -0700 (PDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id KAA07222 for ; Thu, 19 Jul 2001 10:05:33 -0600 (MDT) Received: (qmail 31830 invoked by uid 500); 19 Jul 2001 15:54:37 -0000 Date: Thu, 19 Jul 2001 08:54:35 -0700 From: Pat Calhoun To: Franck.Le@nokia.com Cc: aaa-wg@merit.edu, mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Re: [AAA-WG]: FW: I-D ACTION:draft-le-aaa-diameter-mobileipv6-00.txt Message-ID: <20010719085433.B30610@charizard.diameter.org> Mail-Followup-To: Franck.Le@nokia.com, aaa-wg@merit.edu, mobile-ip@sunroof.eng.sun.com References: <57A26D272F67A743952F6B4371B8F81106AD7F@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: <57A26D272F67A743952F6B4371B8F81106AD7F@daebe007.NOE.Nokia.com>; from Franck.Le@nokia.com on Thu, Jul 19, 2001 at 10:59:07AM -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: Very cool! I do, however, wonder where this work belongs. Should it be in AAA WG, or in Mobile IP? Once we are done with the set of specs in AAA, we will only have the API and the MIB left, so I believe they would have bandwidth. My preference is in AAA WG, but requiring some coordination with MIP. PatC On Thu, Jul 19, 2001 at 10:59:07AM -0500, Franck.Le@nokia.com wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Diameter Mobile IPv6 Application > Author(s) : S. Faccin et al. > Filename : draft-le-aaa-diameter-mobileipv6-00.txt > Pages : > Date : 18-Jul-01 > > This document specifies a new Application to Diameter for Mobile > IPv6, allowing an IPv6 mobile node to receive service from foreign > service providers thanks to the support of inter domain roaming by > the AAA infrastructure. The draft describes a solution that allows > the Diameter infrastructure to authenticate and authorize an IPv6 > mobile node, distribute security keys to enable the provisioning of > services to the IPv6 mobile node, and perform and optimize mobility > procedures for the IPv6 mobile node. > > A URL for this Internet-Draft is: > .txt> > > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-le-aaa-diameter-mobileipv6-00.txt". > > A list of Internet-Drafts directories can be found in > > or > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-le-aaa-diameter-mobileipv6-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 Jul 19 12:49:35 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09831 for ; Thu, 19 Jul 2001 12:49:34 -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 KAA15449; Thu, 19 Jul 2001 10:49:47 -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 JAA06248; Thu, 19 Jul 2001 09:49:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6JGlut02460 for mobile-ip-dist; Thu, 19 Jul 2001 09:47:56 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6JGlr002453 for ; Thu, 19 Jul 2001 09:47:53 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA14906 for ; Thu, 19 Jul 2001 09:48:05 -0700 (PDT) From: stefano.faccin@nokia.com Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA04343 for ; Thu, 19 Jul 2001 09:47:46 -0700 (PDT) Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f6JGlAi03912 for ; Thu, 19 Jul 2001 11:47:10 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Thu, 19 Jul 2001 11:47:08 -0500 Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.1600); Thu, 19 Jul 2001 11:47:07 -0500 content-class: urn:content-classes:message Subject: [mobile-ip] RE: [AAA-WG]: FW: I-D ACTION:draft-le-aaa-diameter-mobileipv6-00.txt Date: Thu, 19 Jul 2001 11:47:07 -0500 Message-ID: <82ECD4351A4A9547957C606034A3CB8D0A17D8@daebe005.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [AAA-WG]: FW: I-D ACTION:draft-le-aaa-diameter-mobileipv6-00.txt X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 Thread-Index: AcEQbMe2JTBD53xeEdWJUgAIx6TWpQABOwtQ To: , Cc: , X-OriginalArrivalTime: 19 Jul 2001 16:47:07.0869 (UTC) FILETIME=[72A310D0:01C11072] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f6JGlr002454 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 Pat, I agree with you. I'd prefer to see this work done in AAA WG, but definitely MIP WG needs to provide inputs and we need to make sure there is coordination. Taz -----Original Message----- From: ext Pat Calhoun [mailto:pcalhoun@diameter.org] Sent: Thursday, July 19, 2001 10:55 AM To: Le Franck (NRC/Dallas) Cc: aaa-wg@merit.edu; mobile-ip@sunroof.eng.sun.com Subject: Re: [AAA-WG]: FW: I-D ACTION:draft-le-aaa-diameter-mobileipv6-00.txt Very cool! I do, however, wonder where this work belongs. Should it be in AAA WG, or in Mobile IP? Once we are done with the set of specs in AAA, we will only have the API and the MIB left, so I believe they would have bandwidth. My preference is in AAA WG, but requiring some coordination with MIP. PatC On Thu, Jul 19, 2001 at 10:59:07AM -0500, Franck.Le@nokia.com wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Diameter Mobile IPv6 Application > Author(s) : S. Faccin et al. > Filename : draft-le-aaa-diameter-mobileipv6-00.txt > Pages : > Date : 18-Jul-01 > > This document specifies a new Application to Diameter for Mobile > IPv6, allowing an IPv6 mobile node to receive service from foreign > service providers thanks to the support of inter domain roaming by > the AAA infrastructure. The draft describes a solution that allows > the Diameter infrastructure to authenticate and authorize an IPv6 > mobile node, distribute security keys to enable the provisioning of > services to the IPv6 mobile node, and perform and optimize mobility > procedures for the IPv6 mobile node. > > A URL for this Internet-Draft is: > .txt> > > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-le-aaa-diameter-mobileipv6-00.txt". > > A list of Internet-Drafts directories can be found in > > or > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-le-aaa-diameter-mobileipv6-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 Jul 19 13:03:00 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11989 for ; Thu, 19 Jul 2001 13:02:59 -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 LAA27354; Thu, 19 Jul 2001 11: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 KAA01998; Thu, 19 Jul 2001 10:03:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6JH26U02527 for mobile-ip-dist; Thu, 19 Jul 2001 10:02:06 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6JH22002520 for ; Thu, 19 Jul 2001 10:02: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 KAA18247 for ; Thu, 19 Jul 2001 10:02:15 -0700 (PDT) Received: from hotmail.com (f78.law7.hotmail.com [216.33.237.78]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA26291 for ; Thu, 19 Jul 2001 11:02:13 -0600 (MDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 19 Jul 2001 10:02:14 -0700 Received: from 206.170.35.222 by lw7fd.law7.hotmail.msn.com with HTTP; Thu, 19 Jul 2001 17:02:14 GMT X-Originating-IP: [206.170.35.222] From: "Hemant Chaskar" To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] draft-tkn-mobileip-qosbinding-mipv6-00.txt Date: Thu, 19 Jul 2001 17:02:14 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 19 Jul 2001 17:02:14.0529 (UTC) FILETIME=[8F0C6710:01C11074] 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: Hello Hesham: Please see comments inline: >From: "Hesham Soliman (ERA)" >Reply-To: mobile-ip@sunroof.eng.sun.com >To: "'mobile-ip@sunroof.eng.sun.com'" >Subject: RE: [mobile-ip] draft-tkn-mobileip-qosbinding-mipv6-00.txt >Date: Thu, 19 Jul 2001 17:43:23 +0200 > > Hello Hemant, > > > > You draft says that the QoS object can be transferred from old AR to new >AR > > by context tranfer framework. In that case, who sends BU to MAP? In >other > > words, it is not possible that the MN sends BU and AR "fills in" the QoS > > object h-b-h option as it changes IP packet length and disturbs the > > authentication calculation. > > > => This is one way of doing it and we are puttnig it in the appendix > of HMIPv6: > > - oAR triggers the handover by sending a Prrtradv > - In the mean time the oAR does the CT. Note that the oAR should already > have the QoS objects/attributes. > - The MN sends a BU, not to the oAR but to the MAP before > it moves. This BU can include a H-B-H option. > [Hemant] This BU MUST go through new AR towards MAP, so that it follows the same path as the packets would follow from the new AR. Is this satisfied in the above scheme? > On another note, I'd like to ask you and the authors a stupid question :) >why can't we > reuse the router alert option for this instead of having a new option ? > > [Hemant] Frankly, I have not considered that alternative, so let me delve more into it before responding. Probably Xiaoming et. al. have an answer. > Regards, > Hesham > > _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 19 13:09:02 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12790 for ; Thu, 19 Jul 2001 13:09:01 -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 KAA00985; Thu, 19 Jul 2001 10:09:33 -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 KAA03354; Thu, 19 Jul 2001 10:09:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6JH8IU02594 for mobile-ip-dist; Thu, 19 Jul 2001 10:08:18 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6JH8F002587 for ; Thu, 19 Jul 2001 10:08:15 -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 KAA19395 for ; Thu, 19 Jul 2001 10:08:28 -0700 (PDT) From: Basavaraj.Patil@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 LAA05922 for ; Thu, 19 Jul 2001 11:09:46 -0600 (MDT) Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f6JH8Ti06673 for ; Thu, 19 Jul 2001 12:08:29 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Thu, 19 Jul 2001 12:08:27 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.1600); Thu, 19 Jul 2001 12:08:26 -0500 content-class: urn:content-classes:message Subject: [mobile-ip] RE: [AAA-WG]: FW: I-D ACTION:draft-le-aaa-diameter-mobileipv6-00.txt Date: Thu, 19 Jul 2001 12:08:26 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF4408606E@daebe007.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [AAA-WG]: FW: I-D ACTION:draft-le-aaa-diameter-mobileipv6-00.txt X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 Thread-Index: AcEQbMe2JTBD53xeEdWJUgAIx6TWpQACHSOg To: , Cc: , X-OriginalArrivalTime: 19 Jul 2001 17:08:26.0878 (UTC) FILETIME=[6CFC59E0:01C11075] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f6JH8G002588 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 > > Very cool! > > I do, however, wonder where this work belongs. Should it be in AAA WG, > or in Mobile IP? Once we are done with the set of specs in AAA, we > will only have the API and the MIB left, so I believe they would have > bandwidth. > > My preference is in AAA WG, but requiring some coordination with MIP. The work needs to be done in the AAA WG. And yes it will require coordination between the two WGs. I completely agree with your view Pat. -Basavaraj From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 19 13:17:24 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13960 for ; Thu, 19 Jul 2001 13:17:24 -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 LAA10021; Thu, 19 Jul 2001 11:17:49 -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 KAA05684; Thu, 19 Jul 2001 10:17:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6JHGQ102691 for mobile-ip-dist; Thu, 19 Jul 2001 10:16:26 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6JHGM002684 for ; Thu, 19 Jul 2001 10:16: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 KAA07683 for ; Thu, 19 Jul 2001 10:16:35 -0700 (PDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA08868 for ; Thu, 19 Jul 2001 11:16:32 -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.11.0/8.11.0/WIREfire-1.3) with SMTP id f6JHGWN00742 for ; Thu, 19 Jul 2001 19:16:32 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu Jul 19 19:16:28 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Thu, 19 Jul 2001 19:16:32 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008B22@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] draft-tkn-mobileip-qosbinding-mipv6-00.txt Date: Thu, 19 Jul 2001 19:16:27 +0200 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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hello Hemant, > > > > > You draft says that the QoS object can be transferred from old AR to new > >AR > > > by context tranfer framework. In that case, who sends BU to MAP? In > >other > > > words, it is not possible that the MN sends BU and AR "fills in" the QoS > > > object h-b-h option as it changes IP packet length and disturbs the > > > authentication calculation. > > > > > => This is one way of doing it and we are puttnig it in the appendix > > of HMIPv6: > > > > - oAR triggers the handover by sending a Prrtradv > > - In the mean time the oAR does the CT. Note that the oAR should already > > have the QoS objects/attributes. > > - The MN sends a BU, not to the oAR but to the MAP before > > it moves. This BU can include a H-B-H option. > > > > [Hemant] This BU MUST go through new AR towards MAP, so that it follows the > same path as the packets would follow from the new AR. Is this satisfied in > the above scheme? > => No. If you want it to go through the nAR then you can use the Network determined model in the Fast Handoffs draft and send the BU to the MAP after you move. However, this goes back to my question about the use of the router alert option. Would something like the following work: - oAR sends Prrtradv - oAR does the CT to nAR - MN sends a normal BU to the MAP (no QoS) - nAR does a proxy RSVP to the MAP to set the outbound link - For inbound traffic it is more difficult, perhaps one handwaving idea would be to get oAR to do transfer the QoS context to the MAP as well ? I'm just not sure whether linking everything to the BU is useful. Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 19 13:17:44 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14034 for ; Thu, 19 Jul 2001 13:17:43 -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 KAA05834; Thu, 19 Jul 2001 10:17: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 KAA05292; Thu, 19 Jul 2001 10:17:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6JHFJK02675 for mobile-ip-dist; Thu, 19 Jul 2001 10:15:19 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6JHFF002668 for ; Thu, 19 Jul 2001 10:15:15 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA07376 for ; Thu, 19 Jul 2001 10:15:28 -0700 (PDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id KAA10494 for ; Thu, 19 Jul 2001 10:15:28 -0700 (PDT) Received: (qmail 1230 invoked by uid 500); 19 Jul 2001 17:04:30 -0000 Date: Thu, 19 Jul 2001 10:04:29 -0700 From: Pat Calhoun To: Basavaraj.Patil@nokia.com Cc: pcalhoun@diameter.org, Franck.Le@nokia.com, aaa-wg@merit.edu, mobile-ip@sunroof.eng.sun.com, aboba@internaut.com, david@mitton.com Subject: [mobile-ip] Re: [AAA-WG]: FW: I-D ACTION:draft-le-aaa-diameter-mobileipv6-00.txt Message-ID: <20010719100429.D30610@charizard.diameter.org> Mail-Followup-To: Basavaraj.Patil@nokia.com, pcalhoun@diameter.org, Franck.Le@nokia.com, aaa-wg@merit.edu, mobile-ip@sunroof.eng.sun.com, aboba@internaut.com, david@mitton.com References: <697DAA22C5004B4596E033803A7CEF4408606E@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: <697DAA22C5004B4596E033803A7CEF4408606E@daebe007.NOE.Nokia.com>; from Basavaraj.Patil@nokia.com on Thu, Jul 19, 2001 at 12:08:26PM -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: On Thu, Jul 19, 2001 at 12:08:26PM -0500, Basavaraj.Patil@nokia.com wrote: > > > > Very cool! > > > > I do, however, wonder where this work belongs. Should it be in AAA WG, > > or in Mobile IP? Once we are done with the set of specs in AAA, we > > will only have the API and the MIB left, so I believe they would have > > bandwidth. > > > > My preference is in AAA WG, but requiring some coordination with MIP. > > The work needs to be done in the AAA WG. And yes it will require > coordination > between the two WGs. I completely agree with your view Pat. Bernard & Dave, Since there seems to be some consensus, we need to raise this issue in the AAA WG meeting, and see whether the document can be added to the milestones. Thanks, PatC From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 19 14:05:33 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA27967 for ; Thu, 19 Jul 2001 14:05:32 -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 LAA00675; Thu, 19 Jul 2001 11:05: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 LAA17591; Thu, 19 Jul 2001 11:05:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6JI4T302898 for mobile-ip-dist; Thu, 19 Jul 2001 11:04:29 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6JI4P002891 for ; Thu, 19 Jul 2001 11:04:25 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA24909 for ; Thu, 19 Jul 2001 11:04:39 -0700 (PDT) Received: from palrel2.hp.com (palrel2.hp.com [156.153.255.234]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA21384 for ; Thu, 19 Jul 2001 11:04:36 -0700 (PDT) Received: from strtio1.cup.hp.com (strtio1.cup.hp.com [15.13.129.245]) by palrel2.hp.com (Postfix) with ESMTP id 63DDC142E; Thu, 19 Jul 2001 11:03:05 -0700 (PDT) Received: (from jlau@localhost) by strtio1.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) id LAA10942; Thu, 19 Jul 2001 11:04:53 -0700 (PDT) Date: Thu, 19 Jul 2001 11:04:53 -0700 (PDT) From: Joe Lau Message-Id: <200107191804.LAA10942@strtio1.cup.hp.com> To: aaa-wg@merit.edu, mobile-ip@sunroof.eng.sun.com, pcalhoun@diameter.org Subject: [mobile-ip] Re: Proposed Text for Issue 91 (KDC) Cc: jlau@cup.hp.com Mime-Version: 1.0 Content-Type: text/plain; charset=X-roman8 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 Pat, I have a question on your recent proposed text for Issue 91 (KDC) > Below is my proposed text for this issue. > ... > > 6.1 MIP-FA-to-MN-Key AVP > > ... > > MIP-FA-to-MN-Key ::== > { MIP-Peer-SPI } > { MIP-Algorithm-Type } > { MIP-Session-Key } > * [ AVP] > > 6.5 MIP-MN-to-FA-Key AVp > > ... > > MIP-MN-to-FA-Key ::== > { MIP-Algorithm-Type } > { MIP-Replay-Mode } > { MIP-Session-Key } > * [ AVP] How come MIP-FA-to-MN-Key, unlike MIP-MN-to-FA-Key, has no MIP-Replay-Mode AVP? Similar problem for the "6.2 MIP-FA-to-HA-Key AVP". Thanks for the clarification. Joe From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 19 14:07:34 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA28610 for ; Thu, 19 Jul 2001 14:07: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 MAA20944; Thu, 19 Jul 2001 12:07: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 LAA17934; Thu, 19 Jul 2001 11:07:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6JI6d202944 for mobile-ip-dist; Thu, 19 Jul 2001 11:06:39 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6JI6Z002937 for ; Thu, 19 Jul 2001 11:06:35 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA03398 for ; Thu, 19 Jul 2001 11:06:49 -0700 (PDT) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA23213 for ; Thu, 19 Jul 2001 11:06:35 -0700 (PDT) Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21) id ; Thu, 19 Jul 2001 14:04:56 -0400 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] draft-tkn-mobileip-qosbinding-mipv6-00.txt Date: Thu, 19 Jul 2001 14:04:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="GB2312" 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 current working assumption is that Mobile IP is generating requirements for support for QoS in Mobile IP entities and that these requirements will be folded into what is needed from the nsis working group. The nsis working group has not yet been formed, but it is anticipated shortly after London. > -----Original Message----- > From: Xiaoming Fu [mailto:fu@ee.tu-berlin.de] > Sent: Thursday, July 19, 2001 7:10 AM > To: mobile-ip@sunroof.eng.sun.com > Subject: [mobile-ip] draft-tkn-mobileip-qosbinding-mipv6-00.txt > > > Hi, > > Recently we have proposed a new idea on QoS for MIP. This > work is based on HMIPv6 and follows the concept of the QoS > option presented by draft-chaskar-mobileip-qos-01.txt > (H. Chaskar, etc). The difference lies on that we update a > binding status only when QoS requirements are met, > i.e., QoS-conditionalized. > > We also compared it with the WG draft "Requirements of a > QoS Solution for Mobile IP". > > Any comments, suggestions, or critics are welcome. > > Xiaoming Fu > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : QoS-Conditionalized Binding Update in Mobile > IPv6 > Author(s) : A. Festag et al. > Filename : draft-tkn-mobileip-qosbinding-mipv6-00.txt > Pages : 29 > Date : 16-Jul-01 > > Abstract > This draft presents a scheme for QoS support in Mobile > IPv6 based on > the architecture of Hierarchical Mobile IPv6. A QoS option, a hop- > by-hop header extension option first presented by Chaskar et al. > [6], is carried in the message containing the Binding Update (BU) > option to the mobility anchor point (MAP). Handoffs are > conditionalized > upon the availability of sufficient resources in the route > between MN > and MAP to meet QoS requirements. When sufficient > resources are not > available and there is more than one new access router, > the procedure > can be reiterated. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-tkn-mobileip-qosbind ing-mipv6-00.txt From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 19 14:07:36 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA28612 for ; Thu, 19 Jul 2001 14:07:34 -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 LAA01715; Thu, 19 Jul 2001 11:07: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 LAA17737; Thu, 19 Jul 2001 11:06:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6JI5KZ02919 for mobile-ip-dist; Thu, 19 Jul 2001 11:05:21 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6JI5G002912 for ; Thu, 19 Jul 2001 11:05:17 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA25096 for ; Thu, 19 Jul 2001 11:05:30 -0700 (PDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id LAA22455 for ; Thu, 19 Jul 2001 11:05:19 -0700 (PDT) Received: (qmail 3308 invoked by uid 500); 19 Jul 2001 17:53:53 -0000 Date: Thu, 19 Jul 2001 10:53:53 -0700 From: Pat Calhoun To: Joe Lau Cc: aaa-wg@merit.edu, mobile-ip@sunroof.eng.sun.com, pcalhoun@diameter.org Subject: [mobile-ip] Re: Proposed Text for Issue 91 (KDC) Message-ID: <20010719105352.F30610@charizard.diameter.org> Mail-Followup-To: Joe Lau , aaa-wg@merit.edu, mobile-ip@sunroof.eng.sun.com, pcalhoun@diameter.org References: <200107191804.LAA10942@strtio1.cup.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200107191804.LAA10942@strtio1.cup.hp.com>; from jlau@cup.hp.com on Thu, Jul 19, 2001 at 11:04:53AM -0700 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 Thu, Jul 19, 2001 at 11:04:53AM -0700, Joe Lau wrote: > Pat, > > I have a question on your recent proposed text for Issue 91 (KDC) > > > Below is my proposed text for this issue. > > ... > > > > 6.1 MIP-FA-to-MN-Key AVP > > > > ... > > > > MIP-FA-to-MN-Key ::== > > { MIP-Peer-SPI } > > { MIP-Algorithm-Type } > > { MIP-Session-Key } > > * [ AVP] > > > > 6.5 MIP-MN-to-FA-Key AVp > > > > ... > > > > MIP-MN-to-FA-Key ::== > > { MIP-Algorithm-Type } > > { MIP-Replay-Mode } > > { MIP-Session-Key } > > * [ AVP] > > How come MIP-FA-to-MN-Key, unlike MIP-MN-to-FA-Key, has no > MIP-Replay-Mode AVP? > > Similar problem for the "6.2 MIP-FA-to-HA-Key AVP". RFC 2002 provides MN-HA replay protection only, via either timestamps or nonces. The protocol doesn't provide such replay protection between MN-FA and FA-HA. The Challenge extension provides the MN-FA replay protection, but that is well before the registration request has even been sent, so sending this info in AAA is pointless. PatC > > Thanks for the clarification. > > Joe > From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 19 14:22:25 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA03601 for ; Thu, 19 Jul 2001 14:22:24 -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 LAA09621; Thu, 19 Jul 2001 11:22: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 LAA21681; Thu, 19 Jul 2001 11:22:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6JIKnL03080 for mobile-ip-dist; Thu, 19 Jul 2001 11:20:49 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6JIKj003073 for ; Thu, 19 Jul 2001 11:20:45 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA28912 for ; Thu, 19 Jul 2001 11:20:57 -0700 (PDT) Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAB02568 for ; Thu, 19 Jul 2001 11:20:56 -0700 (PDT) Received: from strtio1.cup.hp.com (strtio1.cup.hp.com [15.13.129.245]) by palrel1.hp.com (Postfix) with ESMTP id 24CA51BA2; Thu, 19 Jul 2001 11:20:56 -0700 (PDT) Received: (from jlau@localhost) by strtio1.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) id LAA11087; Thu, 19 Jul 2001 11:22:44 -0700 (PDT) Date: Thu, 19 Jul 2001 11:22:44 -0700 (PDT) From: Joe Lau Message-Id: <200107191822.LAA11087@strtio1.cup.hp.com> To: pcalhoun@diameter.org Subject: [mobile-ip] Re: [AAA-WG]: Re: Proposed Text for Issue 91 (KDC) Cc: aaa-wg@merit.edu, jlau@cup.hp.com, mobile-ip@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset=X-roman8 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 Pat, > RFC 2002 provides MN-HA replay protection only, via either timestamps > or nonces. The protocol doesn't provide such replay protection > between MN-FA and FA-HA. But then why MIP-MN-to-FA-Key had a MIP-Replay-Mode AVP? Similar problem on MIP-HA-to-FA-Key AVP. > > > MIP-MN-to-FA-Key ::== > > > { MIP-Algorithm-Type } > > > { MIP-Replay-Mode } <=========== Here > > > { MIP-Session-Key } > > > * [ AVP] I am still puzzled. Thanks in advance for the clarification again. Joe ---------------------- Origial email ------------------------ > > I have a question on your recent proposed text for Issue 91 (KDC) > > > > > Below is my proposed text for this issue. > > > ... > > > > > > 6.1 MIP-FA-to-MN-Key AVP > > > > > > ... > > > > > > MIP-FA-to-MN-Key ::== > > > { MIP-Peer-SPI } > > > { MIP-Algorithm-Type } > > > { MIP-Session-Key } > > > * [ AVP] > > > > > > 6.5 MIP-MN-to-FA-Key AVp > > > > > > ... > > > > > > MIP-MN-to-FA-Key ::== > > > { MIP-Algorithm-Type } > > > { MIP-Replay-Mode } > > > { MIP-Session-Key } > > > * [ AVP] > > > > How come MIP-FA-to-MN-Key, unlike MIP-MN-to-FA-Key, has no > > MIP-Replay-Mode AVP? > > > > Similar problem for the "6.2 MIP-FA-to-HA-Key AVP". > > RFC 2002 provides MN-HA replay protection only, via either timestamps > or nonces. The protocol doesn't provide such replay protection > between MN-FA and FA-HA. The Challenge extension provides the MN-FA > replay protection, but that is well before the registration request > has even been sent, so sending this info in AAA is pointless. > > PatC > > > > Thanks for the clarification. > > > > Joe > > > From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 19 14:23:09 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA03849 for ; Thu, 19 Jul 2001 14:23:08 -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 MAA03371; Thu, 19 Jul 2001 12: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 LAA21841; Thu, 19 Jul 2001 11:22:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6JILjG03101 for mobile-ip-dist; Thu, 19 Jul 2001 11:21:45 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6JILg003094 for ; Thu, 19 Jul 2001 11:21:42 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA06825 for ; Thu, 19 Jul 2001 11:21:53 -0700 (PDT) From: Franck.Le@nokia.com Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA03021 for ; Thu, 19 Jul 2001 11:21:50 -0700 (PDT) Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f6JIMNI25949 for ; Thu, 19 Jul 2001 13:22:24 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Thu, 19 Jul 2001 13:21:35 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.1600); Thu, 19 Jul 2001 13:21:35 -0500 content-class: urn:content-classes:message Subject: RE: [mobile-ip] Dynamic Home Agent Address Discovery mechanism Date: Thu, 19 Jul 2001 13:21:35 -0500 Message-ID: <57A26D272F67A743952F6B4371B8F81106AD81@daebe007.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 Thread-Topic: [mobile-ip] Dynamic Home Agent Address Discovery mechanism Thread-Index: AcEQWzse8GcNtnxNEdWJUgAIx6TWpQAI39Rg To: X-OriginalArrivalTime: 19 Jul 2001 18:21:35.0930 (UTC) FILETIME=[A51089A0:01C1107F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f6JILg003095 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 completely agree with you and am not against the use of IPsec; on the contrary I agree that IPsec should be possible. But it seems that in the last version of the MIPv6 specifiaction, the authentication data is embedded in the BU; using AH will therefore be redundant. To come back to the Home agent discovery, that is true that IPsec with anycast had not yet been defined, but in that case we do not have to use IPsec to secure the ICMP Home Agent address discovery messages: as you said, MN and HA can have a pre-established key they will use for authentication. Instead of using AH, an authentication data field will carry the authentication information. -----Original Message----- From: ext Hesham Soliman (ERA) [mailto:Hesham.Soliman@era.ericsson.se] Sent: 19 July, 2001 8:58 AM To: 'mobile-ip@sunroof.eng.sun.com' Subject: RE: [mobile-ip] Dynamic Home Agent Address Discovery mechanism > As Mobile IPv6 defines its own built-in security mechanism (please see > the Binding Update format of the last version of the draft - section > 5.1), we do not have to use IPsec but, in the same way, the ICMP Home > Agent address Discovery Request message could embed some own specific > security mechanism. > => I believe IPsec is needed and will work for the HA. The problems highlighted for MIPv6 / IPsec are not really applicable for the HA. In particular the key exchange mechanism. This can be preconfigured in the MN. Strong authentication to the HA should be supprted IMHO. Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 19 14:38:15 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07724 for ; Thu, 19 Jul 2001 14:38: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 MAA15443; Thu, 19 Jul 2001 12:38: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 LAA29422; Thu, 19 Jul 2001 11:38:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6JIawt03193 for mobile-ip-dist; Thu, 19 Jul 2001 11:36:58 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.88.31]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6JIat003186 for ; Thu, 19 Jul 2001 11:36:55 -0700 (PDT) Received: from locked (locked.Eng.Sun.COM [129.146.85.189]) by jurassic.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with SMTP id f6JIb6h637326 for ; Thu, 19 Jul 2001 11:37:06 -0700 (PDT) Message-Id: <200107191837.f6JIb6h637326@jurassic.eng.sun.com> Date: Thu, 19 Jul 2001 11:35:40 -0700 (PDT) From: Mohan Parthasarathy Subject: RE: [mobile-ip] Dynamic Home Agent Address Discovery mechanism To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: hUFx5K0kDgMoYqZ+mCZZlw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 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: > > I completely agree with you and am not against the use of IPsec; on the > contrary I agree that IPsec should be possible. > > But it seems that in the last version of the MIPv6 specifiaction, the > authentication data is embedded in the BU; using AH will therefore be > redundant. > The draft is not clear about when IPsec would be used and what these fields in BU would be if IPsec is used. Also, section 4.4 does not include the sender's "key". Without, this it cannot provide sender authentication in the absence of IPsec. Obviously, you would not need this if IPsec is used. -mohan > To come back to the Home agent discovery, that is true that IPsec with > anycast had not yet been defined, but in that case we do not have to use > IPsec to secure the ICMP Home Agent address discovery messages: as you > said, MN and HA can have a pre-established key they will use for > authentication. Instead of using AH, an authentication data field will > carry the authentication information. > > -----Original Message----- > From: ext Hesham Soliman (ERA) [mailto:Hesham.Soliman@era.ericsson.se] > Sent: 19 July, 2001 8:58 AM > To: 'mobile-ip@sunroof.eng.sun.com' > Subject: RE: [mobile-ip] Dynamic Home Agent Address Discovery mechanism > > > > As Mobile IPv6 defines its own built-in security mechanism (please see > > the Binding Update format of the last version of the draft - section > > 5.1), we do not have to use IPsec but, in the same way, the ICMP Home > > Agent address Discovery Request message could embed some own specific > > security mechanism. > > > => I believe IPsec is needed and will work for the HA. > The problems highlighted for MIPv6 / IPsec are not really > applicable for the HA. In particular the key exchange mechanism. > This can be preconfigured in the MN. Strong authentication > to the HA should be supprted IMHO. > > Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 19 14:42:01 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA08753 for ; Thu, 19 Jul 2001 14:42:00 -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 MAA18539; Thu, 19 Jul 2001 12:42: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 LAA00512; Thu, 19 Jul 2001 11:42:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6JIf0Y03258 for mobile-ip-dist; Thu, 19 Jul 2001 11:41:00 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6JIev003251 for ; Thu, 19 Jul 2001 11:40:57 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA03774 for ; Thu, 19 Jul 2001 11:41:08 -0700 (PDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id LAA15795 for ; Thu, 19 Jul 2001 11:41:07 -0700 (PDT) Received: (qmail 5183 invoked by uid 500); 19 Jul 2001 18:29:55 -0000 Date: Thu, 19 Jul 2001 11:29:54 -0700 From: Pat Calhoun To: Joe Lau Cc: pcalhoun@diameter.org, aaa-wg@merit.edu, mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Re: [AAA-WG]: Re: Proposed Text for Issue 91 (KDC) Message-ID: <20010719112953.G30610@charizard.diameter.org> Mail-Followup-To: Joe Lau , pcalhoun@diameter.org, aaa-wg@merit.edu, mobile-ip@sunroof.eng.sun.com References: <200107191822.LAA11087@strtio1.cup.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200107191822.LAA11087@strtio1.cup.hp.com>; from jlau@cup.hp.com on Thu, Jul 19, 2001 at 11:22:44AM -0700 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: An oversight. This will have to be taken care of during the last call phase. Thanks, PatC On Thu, Jul 19, 2001 at 11:22:44AM -0700, Joe Lau wrote: > Pat, > > > RFC 2002 provides MN-HA replay protection only, via either timestamps > > or nonces. The protocol doesn't provide such replay protection > > between MN-FA and FA-HA. > > > But then why MIP-MN-to-FA-Key had a MIP-Replay-Mode AVP? > Similar problem on MIP-HA-to-FA-Key AVP. > > > > > MIP-MN-to-FA-Key ::== > > > > { MIP-Algorithm-Type } > > > > { MIP-Replay-Mode } <=========== Here > > > > { MIP-Session-Key } > > > > * [ AVP] > > I am still puzzled. > Thanks in advance for the clarification again. > > Joe > > ---------------------- Origial email ------------------------ > > > > I have a question on your recent proposed text for Issue 91 (KDC) > > > > > > > Below is my proposed text for this issue. > > > > ... > > > > > > > > 6.1 MIP-FA-to-MN-Key AVP > > > > > > > > ... > > > > > > > > MIP-FA-to-MN-Key ::== > > > > { MIP-Peer-SPI } > > > > { MIP-Algorithm-Type } > > > > { MIP-Session-Key } > > > > * [ AVP] > > > > > > > > 6.5 MIP-MN-to-FA-Key AVp > > > > > > > > ... > > > > > > > > MIP-MN-to-FA-Key ::== > > > > { MIP-Algorithm-Type } > > > > { MIP-Replay-Mode } > > > > { MIP-Session-Key } > > > > * [ AVP] > > > > > > How come MIP-FA-to-MN-Key, unlike MIP-MN-to-FA-Key, has no > > > MIP-Replay-Mode AVP? > > > > > > Similar problem for the "6.2 MIP-FA-to-HA-Key AVP". > > > > RFC 2002 provides MN-HA replay protection only, via either timestamps > > or nonces. The protocol doesn't provide such replay protection > > between MN-FA and FA-HA. The Challenge extension provides the MN-FA > > replay protection, but that is well before the registration request > > has even been sent, so sending this info in AAA is pointless. > > > > PatC > > > > > > Thanks for the clarification. > > > > > > Joe > > > > > From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 19 14:47:02 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10038 for ; Thu, 19 Jul 2001 14:46:59 -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 MAA22296; Thu, 19 Jul 2001 12:47: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 LAA01778; Thu, 19 Jul 2001 11:47:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6JIk5E03327 for mobile-ip-dist; Thu, 19 Jul 2001 11:46:05 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6JIk2003317 for ; Thu, 19 Jul 2001 11:46:02 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA26942 for ; Thu, 19 Jul 2001 11:46:13 -0700 (PDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA24526 for ; Thu, 19 Jul 2001 11:46:13 -0700 (PDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f6JIkCN14083 for ; Thu, 19 Jul 2001 20:46:12 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Thu Jul 19 20:46:11 2001 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 19 Jul 2001 20:40:08 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008B26@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Dynamic Home Agent Address Discovery mechanism Date: Thu, 19 Jul 2001 20:46:06 +0200 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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > I completely agree with you and am not against the use of IPsec; on the > contrary I agree that IPsec should be possible. > => Great ! > But it seems that in the last version of the MIPv6 specifiaction, the > authentication data is embedded in the BU; using AH will therefore be > redundant. > => I have NO idea why this was done. I haven't had time to review it carefully but I never saw a consensus call on this or any recommendation made by the MIPv6 security design team. Even the requirements have not yet been agreed on by the WG. > To come back to the Home agent discovery, that is true that IPsec with > anycast had not yet been defined, but in that case we do not have to use > IPsec to secure the ICMP Home Agent address discovery messages: as you > said, MN and HA can have a pre-established key they will use for > authentication. Instead of using AH, an authentication data field will > carry the authentication information. > => You mean define something new in the RS/ RA ? Everything is possible but I don't see a benefit here. Everyone will certainly know your home prefix, address and you HA's address if they want to. So is it really worth it ? Cheers, Hesham > -----Original Message----- > From: ext Hesham Soliman (ERA) [mailto:Hesham.Soliman@era.ericsson.se] > Sent: 19 July, 2001 8:58 AM > To: 'mobile-ip@sunroof.eng.sun.com' > Subject: RE: [mobile-ip] Dynamic Home Agent Address Discovery mechanism > > > > As Mobile IPv6 defines its own built-in security mechanism (please see > > the Binding Update format of the last version of the draft - section > > 5.1), we do not have to use IPsec but, in the same way, the ICMP Home > > Agent address Discovery Request message could embed some own specific > > security mechanism. > > > => I believe IPsec is needed and will work for the HA. > The problems highlighted for MIPv6 / IPsec are not really > applicable for the HA. In particular the key exchange mechanism. > This can be preconfigured in the MN. Strong authentication > to the HA should be supprted IMHO. > > Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 19 14:48:59 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10717 for ; Thu, 19 Jul 2001 14:48:58 -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 MAA23599; Thu, 19 Jul 2001 12:49: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 LAA02276; Thu, 19 Jul 2001 11:49:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6JIm0S03377 for mobile-ip-dist; Thu, 19 Jul 2001 11:48:00 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6JIlv003370 for ; Thu, 19 Jul 2001 11:47:57 -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 LAA05616 for ; Thu, 19 Jul 2001 11:48:08 -0700 (PDT) Received: from hotmail.com (f156.law7.hotmail.com [216.33.237.156]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA22719 for ; Thu, 19 Jul 2001 12:48:06 -0600 (MDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 19 Jul 2001 11:48:07 -0700 Received: from 206.170.35.222 by lw7fd.law7.hotmail.msn.com with HTTP; Thu, 19 Jul 2001 18:48:07 GMT X-Originating-IP: [206.170.35.222] From: "Hemant Chaskar" To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] draft-tkn-mobileip-qosbinding-mipv6-00.txt Date: Thu, 19 Jul 2001 18:48:07 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 19 Jul 2001 18:48:07.0947 (UTC) FILETIME=[59FB0DB0:01C11083] 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 Hesham: Something like that can be made to work. I have seen a scheme that transfers PATH and RESV State Blocks both for uplink and downlink data to new AR. New AR can do proxy RSVP to MAP using transferred uplink PATH State Block. Assuming that MAP has PATH and RESV State Blocks for downlink data, it can do proxy RSVP to new AR to set up the downlink path. It may not be good idea to tie everything to BU, but indeed the scheme like above generates heck of a signaling. Another option to isolate these things from BU is to include them in normal data packets as h-b-h option. By the way, does uplink data necessarily go through MAP? If not, then including h-b-h QoS object for uplink data in local BU does not work in the first place. May be the authors of the draft can clarify this point. Hemant >From: "Hesham Soliman (ERA)" >Reply-To: mobile-ip@sunroof.eng.sun.com >To: "'mobile-ip@sunroof.eng.sun.com'" >Subject: RE: [mobile-ip] draft-tkn-mobileip-qosbinding-mipv6-00.txt >Date: Thu, 19 Jul 2001 19:16:27 +0200 > > Hello Hemant, > > > > > > > > You draft says that the QoS object can be transferred from old AR to >new > > >AR > > > > by context tranfer framework. In that case, who sends BU to MAP? In > > >other > > > > words, it is not possible that the MN sends BU and AR "fills in" the >QoS > > > > object h-b-h option as it changes IP packet length and disturbs the > > > > authentication calculation. > > > > > > > => This is one way of doing it and we are puttnig it in the appendix > > > of HMIPv6: > > > > > > - oAR triggers the handover by sending a Prrtradv > > > - In the mean time the oAR does the CT. Note that the oAR should >already > > > have the QoS objects/attributes. > > > - The MN sends a BU, not to the oAR but to the MAP before > > > it moves. This BU can include a H-B-H option. > > > > > > > [Hemant] This BU MUST go through new AR towards MAP, so that it follows >the > > same path as the packets would follow from the new AR. Is this satisfied >in > > the above scheme? > > > => No. If you want it to go through the nAR then you can use the Network > determined model in the Fast Handoffs draft and send the BU to the > MAP after you move. > However, this goes back to my question about the use of the router > alert option. Would something like the following work: > > - oAR sends Prrtradv > - oAR does the CT to nAR > - MN sends a normal BU to the MAP (no QoS) > - nAR does a proxy RSVP to the MAP to set the outbound link > - For inbound traffic it is more difficult, perhaps one handwaving idea > would be to get oAR to do transfer the QoS context to the MAP as well ? > > I'm just not sure whether linking everything to the BU is useful. > > Hesham > _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 19 14:50:12 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA11157 for ; Thu, 19 Jul 2001 14:50: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 MAA24594; Thu, 19 Jul 2001 12:50: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 LAA02505; Thu, 19 Jul 2001 11:50:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6JInAD03411 for mobile-ip-dist; Thu, 19 Jul 2001 11:49:10 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6JIn6003404 for ; Thu, 19 Jul 2001 11:49:06 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA02290 for ; Thu, 19 Jul 2001 11:49:18 -0700 (PDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA20715 for ; Thu, 19 Jul 2001 11:49:13 -0700 (PDT) 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 f6JIkoG23702 for ; Thu, 19 Jul 2001 11:46:51 -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 AAG01811; Thu, 19 Jul 2001 11:47:58 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA08813; Thu, 19 Jul 2001 11:47:58 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15191.11102.58968.361859@thomasm-u1.cisco.com> Date: Thu, 19 Jul 2001 11:47:58 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Dynamic Home Agent Address Discovery mechanism In-Reply-To: <200107191837.f6JIb6h637326@jurassic.eng.sun.com> References: <200107191837.f6JIb6h637326@jurassic.eng.sun.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 Indeed. The way the draft reads right now, there would need to be a separate IKE DOI which I'll assume wasn't intended. Mike Mohan Parthasarathy writes: > > > > I completely agree with you and am not against the use of IPsec; on the > > contrary I agree that IPsec should be possible. > > > > But it seems that in the last version of the MIPv6 specifiaction, the > > authentication data is embedded in the BU; using AH will therefore be > > redundant. > > > The draft is not clear about when IPsec would be used and what > these fields in BU would be if IPsec is used. > > Also, section 4.4 does not include the sender's "key". Without, this > it cannot provide sender authentication in the absence of IPsec. > Obviously, you would not need this if IPsec is used. > > -mohan > > > > To come back to the Home agent discovery, that is true that IPsec with > > anycast had not yet been defined, but in that case we do not have to use > > IPsec to secure the ICMP Home Agent address discovery messages: as you > > said, MN and HA can have a pre-established key they will use for > > authentication. Instead of using AH, an authentication data field will > > carry the authentication information. > > > > -----Original Message----- > > From: ext Hesham Soliman (ERA) [mailto:Hesham.Soliman@era.ericsson.se] > > Sent: 19 July, 2001 8:58 AM > > To: 'mobile-ip@sunroof.eng.sun.com' > > Subject: RE: [mobile-ip] Dynamic Home Agent Address Discovery mechanism > > > > > > > As Mobile IPv6 defines its own built-in security mechanism (please see > > > the Binding Update format of the last version of the draft - section > > > 5.1), we do not have to use IPsec but, in the same way, the ICMP Home > > > Agent address Discovery Request message could embed some own specific > > > security mechanism. > > > > > => I believe IPsec is needed and will work for the HA. > > The problems highlighted for MIPv6 / IPsec are not really > > applicable for the HA. In particular the key exchange mechanism. > > This can be preconfigured in the MN. Strong authentication > > to the HA should be supprted IMHO. > > > > Hesham > From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 19 15:01:04 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14671 for ; Thu, 19 Jul 2001 15:01:04 -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 MAA28486; Thu, 19 Jul 2001 12:01:34 -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 MAA04992; Thu, 19 Jul 2001 12:01:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6JIxg203511 for mobile-ip-dist; Thu, 19 Jul 2001 11:59:42 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6JIxc003504 for ; Thu, 19 Jul 2001 11:59:38 -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 LAA00063 for ; Thu, 19 Jul 2001 11:59:50 -0700 (PDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA01955 for ; Thu, 19 Jul 2001 12:59:47 -0600 (MDT) Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f6JIxmO03728 for ; Thu, 19 Jul 2001 20:59:48 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Thu Jul 19 20:59:47 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Thu, 19 Jul 2001 20:59:47 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008B27@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] draft-tkn-mobileip-qosbinding-mipv6-00.txt Date: Thu, 19 Jul 2001 20:59:43 +0200 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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: hi Hemant, > Something like that can be made to work. I have seen a scheme that transfers > PATH and RESV State Blocks both for uplink and downlink data to new AR. New > AR can do proxy RSVP to MAP using transferred uplink PATH State Block. > Assuming that MAP has PATH and RESV State Blocks for downlink data, it can > do proxy RSVP to new AR to set up the downlink path. > > It may not be good idea to tie everything to BU, but indeed the scheme like > above generates heck of a signaling. Another option to isolate these things > from BU is to include them in normal data packets as h-b-h option. > => That should work also. > By the way, does uplink data necessarily go through MAP? If not, then > including h-b-h QoS object for uplink data in local BU does not work in the > first place. May be the authors of the draft can clarify this point. > => Actually no, it doesn't go through the MAP, unless the network uses the MAP as a border router as well. Which eliminates the point of my earlier proposal about using the BUs to the MAP. I think I need more caffeine :))) Hesham > >From: "Hesham Soliman (ERA)" > >Reply-To: mobile-ip@sunroof.eng.sun.com > >To: "'mobile-ip@sunroof.eng.sun.com'" > >Subject: RE: [mobile-ip] draft-tkn-mobileip-qosbinding-mipv6-00.txt > >Date: Thu, 19 Jul 2001 19:16:27 +0200 > > > > Hello Hemant, > > > > > > > > > > > You draft says that the QoS object can be transferred from old AR to > >new > > > >AR > > > > > by context tranfer framework. In that case, who sends BU to MAP? In > > > >other > > > > > words, it is not possible that the MN sends BU and AR "fills in" the > >QoS > > > > > object h-b-h option as it changes IP packet length and disturbs the > > > > > authentication calculation. > > > > > > > > > => This is one way of doing it and we are puttnig it in the appendix > > > > of HMIPv6: > > > > > > > > - oAR triggers the handover by sending a Prrtradv > > > > - In the mean time the oAR does the CT. Note that the oAR should > >already > > > > have the QoS objects/attributes. > > > > - The MN sends a BU, not to the oAR but to the MAP before > > > > it moves. This BU can include a H-B-H option. > > > > > > > > > > [Hemant] This BU MUST go through new AR towards MAP, so that it follows > >the > > > same path as the packets would follow from the new AR. Is this satisfied > >in > > > the above scheme? > > > > > => No. If you want it to go through the nAR then you can use the Network > > determined model in the Fast Handoffs draft and send the BU to the > > MAP after you move. > > However, this goes back to my question about the use of the router > > alert option. Would something like the following work: > > > > - oAR sends Prrtradv > > - oAR does the CT to nAR > > - MN sends a normal BU to the MAP (no QoS) > > - nAR does a proxy RSVP to the MAP to set the outbound link > > - For inbound traffic it is more difficult, perhaps one handwaving idea > > would be to get oAR to do transfer the QoS context to the MAP as well ? > > > > I'm just not sure whether linking everything to the BU is useful. > > > > Hesham > > > > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 19 16:01:27 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA03422 for ; Thu, 19 Jul 2001 16:01:27 -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 NAA23316; Thu, 19 Jul 2001 13:01: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 NAA16918; Thu, 19 Jul 2001 13:01:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6JJx4H03683 for mobile-ip-dist; Thu, 19 Jul 2001 12:59:04 -0700 (PDT) Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6JJx1003676 for ; Thu, 19 Jul 2001 12:59:01 -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 PAA02259 for ; Thu, 19 Jul 2001 15:59:12 -0400 (EDT) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id PAA01196 for mobile-ip@sunroof.eng.sun.com; Thu, 19 Jul 2001 15:59:37 -0400 (EDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6IL51N28553 for ; Wed, 18 Jul 2001 14:05: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 OAA19898 for ; Wed, 18 Jul 2001 14:05:14 -0700 (PDT) Received: from birch.ee.vt.edu (birch.ee.vt.edu [128.173.88.34]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA18918 for ; Wed, 18 Jul 2001 15:06:31 -0600 (MDT) Received: from eagle.ee.vt.edu (eagle.ee.vt.edu [128.173.88.147]) by birch.ee.vt.edu (8.9.3/8.9.3) with ESMTP id RAA15837; Wed, 18 Jul 2001 17:03:50 -0400 (EDT) Received: (from wells@localhost) by eagle.ee.vt.edu (8.9.3+Sun/8.9.3) id RAA08632; Wed, 18 Jul 2001 17:02:29 -0400 (EDT) Date: Wed, 18 Jul 2001 17:02:29 -0400 From: John Wells @eagle.ee.vt.edu@eagle.ee.vt.edu To: mobile-ip@sunroof.eng.sun.com Cc: ipsec@lists.tislabs.com Subject: [mobile-ip] Solution for using MIP6 for client location hiding Message-ID: <20010718170229.A8608@horus.imag.fr> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="/04w6evG8XlLl3ft" Content-Disposition: inline User-Agent: Mutt/1.2.5i 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: --/04w6evG8XlLl3ft Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello all, I've just finished a report on using Mobile IPv6 to hide the true IP address of a mobile node from its correspondant, though the technique is general to all IPv6 and also IPv4 nodes.=20 The paper and associated presentation slides are available on this web site: http://www.ee.vt.edu/~wells. Here is the abstract: Cloaking is a technique whereby a source can hide its location from a receiver under IPv6. Relying on other standardized protocols, in particular IPsec, Mobile IP, and HMIPv6, to provide encryption and a large part of the implementation for the machines implicated, cloaking solves this problem in an extremely lightweight manner. Conceived for IPv6, it delicately avoids solving problems already solved in that domain. That is, it only hides its location and identity from the receiver; it makes no attempt to hide its identity from intermediate observers; several privacy extensions already provide this capability.=20 mercredi, le 18 juil 2001 =E0 10h45 -0400, Hongyi Li a =E9crit : > Hi, > I submitted a LMM framework draft to MIP group last week. As > I am not going to attend the London meeting, I would to like to > have some discussions / feedback about the draft on the mailing > list. >=20 > Here it the link to the draft: > http://www.ietf.org/internet-drafts/draft-li-mobileip-lmm-framework-00.txt >=20 > Regards >=20 > Hongyi >=20 >=20 >=20 > =20 >=20 > > -----Original Message----- > > From: Phil Roberts [mailto:PRoberts@MEGISTO.com] > > Sent: Tuesday, July 17, 2001 2:35 PM > > To: 'mobile-ip@sunroof.eng.sun.com' > > Subject: [mobile-ip] proposed agenda > >=20 > >=20 > >=20 > > Hi folks, > >=20 > > here's a new version of the agenda. Although the history=20 > > of the working > > group has been > > to allow presentations of as many drafts as possible, this meeting > > represents a departure > > from tradition. Essentially we're going to use the time only=20 > > for discussing > > those things > > which seem to indicate a need for face-to-face discussion=20 > > time. We would > > prefer to discuss > > and resolve most of the working group issues on the mailing=20 > > list. If you > > believe there > > is an issue that needs to be discussed that is not covered by=20 > > the agenda, > > please post to > > the mailing list describing what it is and why. If you have=20 > > a draft with an > > interesting > > idea that the working group should consider for standardization or > > documentation, please > > attempt to generate a discussion on the mailing list. > >=20 > > Phil and Raj > >=20 > > Agenda Phil 5 minutes > > Update on WG docs Phil 10 minutes > >=20 > > This slot is for last minute updates. Here is the current=20 > > status of docs > > that are in last call or submitted to Abha. > >=20 > > draft-ietf-mobileip-mier-07.txt (submitted) > > draft-ietf-mobileip-gnaie-04.txt (submitted) > > draft-ietf-mobileip-3g wireless-ext-06.txt (being updated=20 > > based on IESG > > feedback) > > draft-ietf-mobileip-rfc2002-bis-06.txt (being updated based on IESG > > feedback) > > draft-ietf-mobileip-gen-key-00.txt (wg last call expires=20 > > Friday 7/20 > > hopefully submitted) > > draft-ietf-mobileip-aaa-key-07.txt (to be submitted Friday 7/20) > > draft-ietf-mobileip-qos-requirements-00.txt (wg last call=20 > > expires 7/25) > > draft-ietf-mobileip-reg-tunnel-04.txt (being updated) > > draft-ietf-mobileip-optim-10.txt (past wg last call,=20 > > sitting on it until > > MIP v6 > > issues resolved) > >=20 > > Moving MIPv4 to draft standard Charlie 10 minutes > >=20 > > Mobile IP v6 security update ?=20 > > draft-team-mobileip-mipv6-sec-reqts-00.txt > > 15 minutes > > Mobile IP v6 other changes in -14 Charlie 5 minutes > > draft-ietf-mobileip-ipv6-14.txt > >=20 > > v4 Low Latency Handover Karim 5 minutes > > draft-ietf-mobileip-lowlatency-handoffs-v4-01.txt > > Is there anyone who can share implementation experiences? > > Is this doc ready for last call? > >=20 > > v6 Fast Handover draft-ietf-mobileip-fast-mipv6-01.txt > > BETH addition? James 10 minutes draft-kempf-beth-ipv6-01.txt > > Implementation experience report Rajeev Koodli 10 minutes > >=20 > > Mobile Network Support Thierry Ernst 15 minutes > > Mobile IP Component Redundancy Gopal 10 minutes > >=20 > > LMM Requirements Carl Williams 15 minutes > > (draft-ietf-mobileip-lmm-requirements-00.txt) > >=20 > > Issues from the list Raj 15 minutes > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 --=20 John WELLS INRIA Rh=F4ne-Alpes, Plan=E8te Project - ENSIMAG 3A/T=E9l=E9comm et R=E9sea= ux Virginia Tech Networking and Visualization Lab PGP Public key: http://www.inrialpes.fr/planete/people/wells/pgpkey.txt --/04w6evG8XlLl3ft Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (SunOS) Comment: For info see http://www.gnupg.org iD8DBQE7VflktvPFKAfa3SIRAlPWAKCAJmGJrFH98FR9dOwGphX0EnwhEwCfW8zH kL22x9R32Ku5ElCPtDCsNTE= =Ncxf -----END PGP SIGNATURE----- --/04w6evG8XlLl3ft-- From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 19 16:05:21 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA04109 for ; Thu, 19 Jul 2001 16:05:20 -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 NAA24924; Thu, 19 Jul 2001 13:05: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 NAA17718; Thu, 19 Jul 2001 13:04:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6JK3lt03806 for mobile-ip-dist; Thu, 19 Jul 2001 13:03:48 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6JK3h003792 for ; Thu, 19 Jul 2001 13:03:43 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA20051 for ; Thu, 19 Jul 2001 13:03:55 -0700 (PDT) From: Basavaraj.Patil@nokia.com Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA27155 for ; Thu, 19 Jul 2001 13:03:51 -0700 (PDT) Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f6JK3qi03937 for ; Thu, 19 Jul 2001 15:03:52 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Thu, 19 Jul 2001 15:03:50 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.1600); Thu, 19 Jul 2001 15:03:50 -0500 content-class: urn:content-classes:message Subject: RE: [mobile-ip] re:draft-ohnishi-mobileip-mbg-00.txt Date: Thu, 19 Jul 2001 15:03:49 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF440967D1@daebe007.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [mobile-ip] re:draft-ohnishi-mobileip-mbg-00.txt X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 Thread-Index: AcEPD82eWxSp7Hr/EdWxLgAIx6TWeABfackA To: , , Cc: X-OriginalArrivalTime: 19 Jul 2001 20:03:50.0141 (UTC) FILETIME=[ED56DAD0:01C1108D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f6JK3i003793 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, With MBG you are introducing another new mobility agent to achieve IP mobility and I am not sure if the benefit outweighs the simplicity of just having H/FAs and triangle routing. The ideal solution would be to achieve route optimization using only the end-points of the communication (MN-CN). But in view of such a solution being difficult to deploy for IPv4, other approaches may need to be considered, but I would like to get a sense of greater consensus in the WG on this. >Glenn Morrow wrote: > >Hiroyuki and Yasushi, > >In reference to your draft: > >http://www.ietf.org/internet-drafts/draft-ohnishi-mobileip-mbg-00.txt > >I have a few questions and comments: > >Would the MGBs be similar or perhaps even the same border routers >between autonomous systems of 2 ISPs such as two cellular ISPs? > >What signaling protocol are you looking at to distribute the fact that >the address ranges are mobile address from the HA to the MGBs: BGP, >OSPF, IS-IS or do you feel that this can be done with simple >configuration? > >It seems to me that the conveyance of this information would also >constitute an IP roaming agreement. An automatic, routing >protocol-based way of setting these up would be of benefit >IMO. Furthurmore, I believe some similar work should be done to >identify geographical adjacency for handoff purposes. > >Question to the chairs and/or ADs: > >Would this work fall under MIP WG or routing WGs? > Route optimization is within the scope of the MIP WG. However the aspect of updating MBGs with addresses of MNs is probably outside the scope of MIP. Especially if you are planning on using some form of signaling or using routing protocols (as you suggest). >Are you planning any follow-up work on this? > >The expect that the antagonists to this draft may complain about the >number of per-node routes and what this will do to the routing table >size. Last time I checked route lookups were pretty fast in most of >the newer products - even with fairly large routing tables; >nevertheless, I expect there to be some contention on this. Has there >been any analysis on this? > It would be good to see some results of analysis/simulations of this proposal. >Some positive comments I have on this is that it does indeed seem to >be a very realistic deployment method for route optimization. I have >not heard of any plans to support route optimization on IPv4 hosts by >any of the major OS vendors. It makes sense to me to distribute the >fact that certain addresses are mobile to portions of the network. I >honestly believe that there are other reasons such as location privacy >to maintain the mobile bindings in routers as well. I believe that >such functions are better left in purpose built machines that handle >handle fast lookups on relatively large route tables. Some analysis on >this aspect would also be useful? > >Another thing I would like to bring up to folks on the list is that >even in IPv6, there is no MUST that CN hosts support the binding >functions of MIPv6. With this in mind, I expect there will be nodes >out there that don't do it. So even in IPv6, the ubiquity of route >optimization is still in question. This gives credence to the >reasoning for the solution in IPv6 as well. > But that's not the point. IPv6 nodes are capable of supporting route optimization and if they choose not to, then I guess you just live with triangle routing. But I do not see this as a reason to apply MBG to IPv6. Also note that it is quite possible that a CN which supports route optimization is still very much capable of rejecting a binding update from the MN (for any number of reasons). >Another thing I would like to point out that the signaling methodology >seems quite similar, as far as the MGP querying the HA for the >binding, to some the initial work on the GES, 8+8 concepts. You seem >to be doing the query without having to changing the IP header or mess >with the addressing schemas - a bonus IMHO. The fact that you are >using the mobile IP HA instead of something like DNS is also a good >idea IMO due to speed and an already overloaded DNS. > >It also seems to me that this would allow IPv4 ISPs to offer the >service without having to fork-lift all of their clients' host >operating systems. A money saving and realistic idea. > >On the analysis questions - are there any papers available which >explore these topics you could point us to? > >Thanks, > >Glenn Cheers, -Basavaraj From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 19 16:46:40 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA11008 for ; Thu, 19 Jul 2001 16:46:39 -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 OAA16508; Thu, 19 Jul 2001 14:47: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 NAA06889; Thu, 19 Jul 2001 13:46:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6JKjaw04020 for mobile-ip-dist; Thu, 19 Jul 2001 13:45:36 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6JKjX004013 for ; Thu, 19 Jul 2001 13:45:33 -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 NAA06685 for ; Thu, 19 Jul 2001 13:45:46 -0700 (PDT) From: Basavaraj.Patil@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 OAA28940 for ; Thu, 19 Jul 2001 14:47:03 -0600 (MDT) Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f6JKjfi09607 for ; Thu, 19 Jul 2001 15:45:46 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Thu, 19 Jul 2001 15:45:38 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.1600); Thu, 19 Jul 2001 15:45:38 -0500 content-class: urn:content-classes:message Subject: [mobile-ip] Please do not attach drafts to emails Date: Thu, 19 Jul 2001 15:45:38 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF44086078@daebe007.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 Thread-Topic: [mobile-ip] New draft on NAT-VPN traversal for Mobile IPv4 Thread-Index: AcEPqufG9QU18XucEdWBSQBQi2X+DwA6FHmA To: X-OriginalArrivalTime: 19 Jul 2001 20:45:38.0438 (UTC) FILETIME=[C4669A60:01C11093] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f6JKjX004014 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 If you have submitted a draft via the standard process, please wait for the announcement to come out to inform the WG about the availability of the I-D. Do not clutter inboxes by sending the draft as an attachment. If you really want to or have to inform the discussion list of an I-D that is not in the standard repository, just send an URL to where it can be found. -Basavaraj From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 19 17:16:14 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15045 for ; Thu, 19 Jul 2001 17:16:13 -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 OAA24228; Thu, 19 Jul 2001 14:16:44 -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 OAA05953; Thu, 19 Jul 2001 14:16:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6JLEiT04102 for mobile-ip-dist; Thu, 19 Jul 2001 14:14:44 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6JLEf004095 for ; Thu, 19 Jul 2001 14:14:41 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA28569 for ; Thu, 19 Jul 2001 14:14:54 -0700 (PDT) From: Franck.Le@nokia.com Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA26505 for ; Thu, 19 Jul 2001 14:14:53 -0700 (PDT) Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f6JLEsi14115 for ; Thu, 19 Jul 2001 16:14:54 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Thu, 19 Jul 2001 16:14:52 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.1600); Thu, 19 Jul 2001 16:14:51 -0500 content-class: urn:content-classes:message Subject: RE: [mobile-ip] Dynamic Home Agent Address Discovery mechanism Date: Thu, 19 Jul 2001 16:14:51 -0500 Message-ID: <57A26D272F67A743952F6B4371B8F81106AD90@daebe007.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 Thread-Topic: [mobile-ip] Dynamic Home Agent Address Discovery mechanism Thread-Index: AcEQgz7H/GW1y3x1EdWJUgAIx6TWpQAE8XiA To: X-OriginalArrivalTime: 19 Jul 2001 21:14:51.0965 (UTC) FILETIME=[D99596D0:01C11097] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f6JLEf004096 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 Hesham, > To come back to the Home agent discovery, that is true that IPsec with > anycast had not yet been defined, but in that case we do not have to use > IPsec to secure the ICMP Home Agent address discovery messages: as you > said, MN and HA can have a pre-established key they will use for > authentication. Instead of using AH, an authentication data field will > carry the authentication information. > => You mean define something new in the RS/ RA ? Everything is possible but I don't see a benefit here. Everyone will certainly know your home prefix, address and you HA's address if they want to. So is it really worth it ? I completely agree with you on the BU format and for the proposal we made, some enhancements were suggested in order to improve the Dynamic Home Agent assignment procedure: the ICMP Home Agent Address Discovery Request messages were suggested to be optionally authenticated and the Home Agent Discovery reply messages optionally encrypted. As described in a previous e-mail, "the reason for authenticating a Discovery request is to ensure that only valid MNs obtain the list of HAs serving a subnet or network. Obviously there are other ways that an attacker can learn about the HAs in a network, but this approach at least puts in some barriers to having information about HAs in a network being publicly available (via the ICMP discovery request). We believe that operators would like to some extent protect the identity of the HAs in their network. So the mechanism suggested helps such cases. If a network wants to be open, then yes you do not need to have the authentication of the discovery message." "But as we mentioned, it's an option that needs to be supported in the spec." Using the Binding Update messages, "an attacker only learns about a single HA being used by some user as opposed to getting information about all HAs in a network via the current ICMP Home Agent address discovery messages. I guess it's a matter of making it harder for the attackers to discover information on HAs. Many different kinds of attacks could be launched targeting HAs in a network and this could be at least to some extent made harder if the info about HAs was not readily available. Only the attackers on the MN-HA paths would be able to get the serving HA address which reduces the potential number of attackers significantly." Best Regards, Franck From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 19 18:38:56 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA04269 for ; Thu, 19 Jul 2001 18:38:55 -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 PAA26488; Thu, 19 Jul 2001 15:39:28 -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 PAA29446; Thu, 19 Jul 2001 15:38:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6JMbMS04261 for mobile-ip-dist; Thu, 19 Jul 2001 15:37:22 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6JMbJ004254 for ; Thu, 19 Jul 2001 15:37:19 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA04186 for ; Thu, 19 Jul 2001 15:37:31 -0700 (PDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA00800 for ; Thu, 19 Jul 2001 15:37:30 -0700 (PDT) Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f6JMbTO23926 for ; Fri, 20 Jul 2001 00:37:29 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Fri Jul 20 00:37:29 2001 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 20 Jul 2001 00:31:25 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008B29@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Dynamic Home Agent Address Discovery mechanism Date: Fri, 20 Jul 2001 00:37:25 +0200 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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Franck, > => You mean define something new in the RS/ RA ? > Everything is possible but I don't see a benefit here. > Everyone will certainly know your home prefix, address and > you HA's address if they want to. So is it really worth it ? > > I completely agree with you on the BU format and for the proposal we > made, some enhancements were suggested in order to improve the Dynamic > Home Agent assignment procedure: the ICMP Home Agent Address Discovery > Request messages were suggested to be optionally authenticated and the > Home Agent Discovery reply messages optionally encrypted. > > As described in a previous e-mail, "the reason for authenticating a > Discovery request is to ensure that only valid MNs obtain the list of > HAs serving a subnet or network. Obviously > there are other ways that an attacker can learn about the HAs in a > network, but this approach at least puts in some barriers to having > information about HAs in a network being publicly available (via the > ICMP discovery request). We believe that operators would like to some > extent protect the identity of the HAs in their network. So the > mechanism suggested helps such cases. If a network wants to be open, > then yes you do not need to have the authentication of the discovery > message." > > "But as we mentioned, it's an option that needs to be supported in the > spec." > > Using the Binding Update messages, "an attacker only learns about a > single HA being used by some user as opposed to getting information > about all HAs in a network via the current ICMP Home Agent address > discovery messages. I guess it's a matter of making it harder for the > attackers to discover information on HAs. Many different kinds of > attacks could be launched targeting HAs in a network and this could be > at least to some extent made harder if the info about HAs was not > readily available. > Only the attackers on the MN-HA paths would be able to get the serving > HA address which reduces the potential number of attackers > significantly." > => Understood, but I was wondering whether there is a great advantage in hiding one HA vs many. Anyway, when you talk about your proposal are you referring to the DIAMETER extensions draft ? I have some comments on it. I suppose I can send them to the list after the draft deadline. If you're referring to another proposal I'd appreciate a pointer. Regards, Hesham From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 20 01:34:50 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA19903 for ; Fri, 20 Jul 2001 01:34:50 -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 WAA16699; Thu, 19 Jul 2001 22:35: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 WAA01889; Thu, 19 Jul 2001 22:35:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6K5Y8S04571 for mobile-ip-dist; Thu, 19 Jul 2001 22:34:08 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6K5Y5004564 for ; Thu, 19 Jul 2001 22:34:05 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA23140 for ; Thu, 19 Jul 2001 22:34:18 -0700 (PDT) Received: from mail.n016.co.kr ([203.229.169.4]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA13479 for ; Thu, 19 Jul 2001 22:34:12 -0700 (PDT) Received: from freenet.ktf.co.kr (freenet.ktf.com [203.229.169.83]) by mail.n016.co.kr (v3smtp 8.11.4 Copyright (c) 1998-2001 Sendmail, Inc. All rights reserved.Copyright (c) 1988, 1993 The Regents of the University of California. All rights reserved./8.11.1) with ESMTP id f6K5TdA17720 for ; Fri, 20 Jul 2001 14:29:39 +0900 (KST) Received: from words ([10.6.10.175]) by freenet.ktf.co.kr (8.9.3/8.9.3) with SMTP id OAA16685 for ; Fri, 20 Jul 2001 14:31:31 +0900 (KST) Message-ID: <02b601c110dd$49f3dd20$af0a060a@words> From: "Jiwoong Lee" To: Subject: [mobile-ip] Subnet vs Link Date: Fri, 20 Jul 2001 14:31:55 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 8bit 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: 8bit I just found that mipv6-sec-reqts-00.txt uses terminology both 'subnet' and 'link' in one document. In some sense, I regard they are different. In other sense, I don't see any difference. By the way, I didn't know that IPv6 also has the concept of 'subnet'. Can anyone give me clear explanation? Thank you Jiwoong From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 20 03:26:18 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA03998 for ; Fri, 20 Jul 2001 03:26:17 -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 AAA04585; Fri, 20 Jul 2001 00:26: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 AAA10882; Fri, 20 Jul 2001 00:26:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6K7PUM04814 for mobile-ip-dist; Fri, 20 Jul 2001 00:25:30 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6K7PR004807 for ; Fri, 20 Jul 2001 00:25: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 AAA02717 for ; Fri, 20 Jul 2001 00:25:39 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA16244 for ; Fri, 20 Jul 2001 01:25:37 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f6K7Pbr21077 for ; Fri, 20 Jul 2001 09:25:37 +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 JAA12075 for ; Fri, 20 Jul 2001 09:25:36 +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 f6K7PaO83048 for ; Fri, 20 Jul 2001 09:25:36 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200107200725.f6K7PaO83048@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Subnet vs Link In-reply-to: Your message of Fri, 20 Jul 2001 14:31:55 +0900. <02b601c110dd$49f3dd20$af0a060a@words> Date: Fri, 20 Jul 2001 09:25:36 +0200 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: In your previous mail you wrote: I just found that mipv6-sec-reqts-00.txt uses terminology both 'subnet' and 'link' in one document. In some sense, I regard they are different. In other sense, I don't see any difference. By the way, I didn't know that IPv6 also has the concept of 'subnet'. Can anyone give me clear explanation? => this seems to be just a mistake: I believe only the word 'link' should be used because only the word 'link' is clearly defined in IPv6 documents. The word 'subnet' (subnetwork in fact) is the generic 'OSI ISO' term but its meaning for IPv4 is a bit different so it can be ambiguous. Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 20 03:33:14 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA05518 for ; Fri, 20 Jul 2001 03:33:13 -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 AAA06066; Fri, 20 Jul 2001 00:33: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 AAA11606; Fri, 20 Jul 2001 00:33:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6K7WKR04870 for mobile-ip-dist; Fri, 20 Jul 2001 00:32:20 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6K7WH004863 for ; Fri, 20 Jul 2001 00:32:17 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA21773 for ; Fri, 20 Jul 2001 00:32:29 -0700 (PDT) Received: from mail.zrz.tu-berlin.de (mail.zrz.TU-Berlin.DE [130.149.4.15]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA19342 for ; Fri, 20 Jul 2001 00:32:28 -0700 (PDT) Received: from ftsu07.ee.tu-berlin.de ([130.149.49.87] helo=ftmail.ee.tu-berlin.de) by mail.zrz.tu-berlin.de with esmtp (exim-3.31) for id 15NUlu-0001FF-00; Fri, 20 Jul 2001 09:32:26 +0200 Received: from ee.tu-berlin.de (fu@sinope.ee.TU-Berlin.DE [130.149.49.127]) by ftmail.ee.tu-berlin.de (8.11.3/8.11.3) with ESMTP id f6K7WQh14589 for ; Fri, 20 Jul 2001 09:32:26 +0200 Message-ID: <3B57DE8A.E10FFA96@ee.tu-berlin.de> Date: Fri, 20 Jul 2001 09:32:26 +0200 From: Xiaoming Fu Organization: Telecommunication Networks Group, TU-Berlin X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.14 i686) X-Accept-Language: en-US, de, zh-CN MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] draft-tkn-mobileip-qosbinding-mipv6-00.txt References: Content-Type: text/plain; charset=gb2312 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 Hemant, Hemant Chaskar wrote: > > Hi Xiaoming: > > Regarding D bit: The natural question is what happens if the two way paths > are assymetric? Though the case of assymetric paths are not studied in this draft (see goals & assum. 6- "provided that both uplink and downlink data travels along the same route"), we think it may possible to use a non-MIP-specific QoS mechanism for uplink data traffic, since it does't involve MIP-based re-routing. However this needs further investigation. > I think there is a more efficient way to refresh the QoS states if any, > after QoS object is included in the first BU. One can assign a small ID to > QoS object calculated as, for example, the hash of QoS object by MN-specific > (and private) key such as password. Then we only send this ID as h-b-h > options in some data packets at regular intervals. That way it will refresh > the state and not waste wireless bandwidth for refresh. Yes, we agreed that using ID as the refreshing option may reduce the size of message size, as this refreshing won't bring up QoS change in the existing path. And this may introduce new option type (so we keep the current version for the moment.) > > You draft says that the QoS object can be transferred from old AR to new AR > by context tranfer framework. In that case, who sends BU to MAP? In other > words, it is not possible that the MN sends BU and AR "fills in" the QoS > object h-b-h option as it changes IP packet length and disturbs the > authentication calculation. The nAR should be now responsible for sending BU (to be more exact, re-assembling it by adding QoS object getting from the oAR). Hereby the AR should be aware of CT and able to assemble a QoS-aware BU. > > Hemant > > >From: Xiaoming Fu > >Reply-To: mobile-ip@sunroof.eng.sun.com > >To: "mobile-ip@sunroof.eng.sun.com" > >Subject: [mobile-ip] draft-tkn-mobileip-qosbinding-mipv6-00.txt > >Date: Thu, 19 Jul 2001 13:09:46 +0200 > > > >Hi, > > > >Recently we have proposed a new idea on QoS for MIP. This > >work is based on HMIPv6 and follows the concept of the QoS > >option presented by draft-chaskar-mobileip-qos-01.txt > >(H. Chaskar, etc). The difference lies on that we update a > >binding status only when QoS requirements are met, > >i.e., QoS-conditionalized. > > > >We also compared it with the WG draft "Requirements of a > >QoS Solution for Mobile IP". > > > >Any comments, suggestions, or critics are welcome. > > > >Xiaoming Fu > > > > > >A New Internet-Draft is available from the on-line Internet-Drafts > >directories. > > > > > > Title : QoS-Conditionalized Binding Update in Mobile > >IPv6 > > Author(s) : A. Festag et al. > > Filename : draft-tkn-mobileip-qosbinding-mipv6-00.txt > > Pages : 29 > > Date : 16-Jul-01 > > > >Abstract > > This draft presents a scheme for QoS support in Mobile IPv6 based on > > the architecture of Hierarchical Mobile IPv6. A QoS option, a hop- > > by-hop header extension option first presented by Chaskar et al. > > [6], is carried in the message containing the Binding Update (BU) > > option to the mobility anchor point (MAP). Handoffs are > >conditionalized > > upon the availability of sufficient resources in the route between MN > > and MAP to meet QoS requirements. When sufficient resources are not > > available and there is more than one new access router, the procedure > > can be reiterated. > > > >A URL for this Internet-Draft is: > >http://www.ietf.org/internet-drafts/draft-tkn-mobileip-qosbinding-mipv6-00.txt > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp -- From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 20 03:54:05 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA10576 for ; Fri, 20 Jul 2001 03:54:05 -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 BAA27943; Fri, 20 Jul 2001 01:54: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 AAA13251; Fri, 20 Jul 2001 00:53:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6K7qFH04923 for mobile-ip-dist; Fri, 20 Jul 2001 00:52:15 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6K7qB004916 for ; Fri, 20 Jul 2001 00:52: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 AAA23425 for ; Fri, 20 Jul 2001 00:52:24 -0700 (PDT) Received: from mail.zrz.tu-berlin.de (mail.zrz.TU-Berlin.DE [130.149.4.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA26919 for ; Fri, 20 Jul 2001 01:52:22 -0600 (MDT) Received: from ftsu07.ee.tu-berlin.de ([130.149.49.87] helo=ftmail.ee.tu-berlin.de) by mail.zrz.tu-berlin.de with esmtp (exim-3.31) for id 15NV5C-0001tT-00; Fri, 20 Jul 2001 09:52:22 +0200 Received: from ee.tu-berlin.de (fu@sinope.ee.TU-Berlin.DE [130.149.49.127]) by ftmail.ee.tu-berlin.de (8.11.3/8.11.3) with ESMTP id f6K7qMh15692 for ; Fri, 20 Jul 2001 09:52:22 +0200 Message-ID: <3B57E336.31BA1DF2@ee.tu-berlin.de> Date: Fri, 20 Jul 2001 09:52:22 +0200 From: Xiaoming Fu Organization: Telecommunication Networks Group, TU-Berlin X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.14 i686) X-Accept-Language: en-US, de, zh-CN MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] draft-tkn-mobileip-qosbinding-mipv6-00.txt References: <034BEFD03799D411A59F00508BDF754603008B21@esealnt448.al.sw.ericsson.se> Content-Type: text/plain; charset=gb2312 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, > On another note, I'd like to ask you and the authors a stupid question :) why can't we > reuse the router alert option for this instead of having a new option ? The router alert option allows only a 2-octet value field in addition to the type field. To notify the nodes in the new path should be notified with a certain list of QoS requirements which cannot fulfiled by the router alert option. Regards, Xiaoming From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 20 05:36:08 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA05727 for ; Fri, 20 Jul 2001 05:36:08 -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 CAA04564; Fri, 20 Jul 2001 02:36: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 CAA22784; Fri, 20 Jul 2001 02:36:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6K9Z9Y05188 for mobile-ip-dist; Fri, 20 Jul 2001 02:35:09 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6K9Z4005181 for ; Fri, 20 Jul 2001 02:35:04 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA12819 for ; Fri, 20 Jul 2001 02:35:18 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA06705 for ; Fri, 20 Jul 2001 02:35:18 -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 FAA05014; Fri, 20 Jul 2001 05:34:20 -0400 (EDT) Message-Id: <200107200934.FAA05014@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-mier-07.txt Date: Fri, 20 Jul 2001 05:34:19 -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 Extensions Rationalization (MIER) Author(s) : M. Khalil, R. Narayanan, H. Akhtar, E. Qaddoura Filename : draft-ietf-mobileip-mier-07.txt Pages : 8 Date : 19-Jul-01 It is in the interest of the Mobile IP WG to conserve the usage of the type field since we see many drafts proposing new extensions for Mobile IP. Therefore there is a real need to find ways to limit the usage of the type field in the extensions structure. MIER describes a new extension structure to Mobile IP to make the extensions far more extensible. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-mier-07.txt 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-mier-07.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-mier-07.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: <20010719145612.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-mier-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-mier-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010719145612.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 20 05:36:31 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA05968 for ; Fri, 20 Jul 2001 05:36:30 -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 CAA04767; Fri, 20 Jul 2001 02:36:51 -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 CAA22806; Fri, 20 Jul 2001 02:36:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6K9Z4V05179 for mobile-ip-dist; Fri, 20 Jul 2001 02:35:04 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6K9Z0005172 for ; Fri, 20 Jul 2001 02:35:00 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA22673 for ; Fri, 20 Jul 2001 02:35:13 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA06689 for ; Fri, 20 Jul 2001 02:35:13 -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 FAA04984; Fri, 20 Jul 2001 05:34:15 -0400 (EDT) Message-Id: <200107200934.FAA04984@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-gnaie-04.txt Date: Fri, 20 Jul 2001 05:34:15 -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 : Generalized NAI (GNAIE) Extension Author(s) : M. Khalil, E. Qaddoura, H. Akhtar, P. Calhoun Filename : draft-ietf-mobileip-gnaie-04.txt Pages : 6 Date : 19-Jul-01 The Mobile IP Extensions Rationalization (MIER) specification defines a new extension header format, that is intended to extend the Mobile IP extension address space. This document defines the Generalized Network Access Identifier (NAI) extension, which SHOULD be used by any Mobile IP extension specifying an extension containing an NAI. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-gnaie-04.txt 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-gnaie-04.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-gnaie-04.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: <20010719145603.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-gnaie-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-gnaie-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010719145603.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 20 05:47:25 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA10775 for ; Fri, 20 Jul 2001 05:47:24 -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 DAA19268; Fri, 20 Jul 2001 03:47: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 CAA23829; Fri, 20 Jul 2001 02:47:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6K9kgT05334 for mobile-ip-dist; Fri, 20 Jul 2001 02:46:42 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6K9kb005327 for ; Fri, 20 Jul 2001 02:46:37 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA13644 for ; Fri, 20 Jul 2001 02:46:51 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA05449 for ; Fri, 20 Jul 2001 02:46:50 -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 FAA10229; Fri, 20 Jul 2001 05:45:53 -0400 (EDT) Message-Id: <200107200945.FAA10229@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-elmalki-mobileip-bicasting-v6-00.txt Date: Fri, 20 Jul 2001 05:45:52 -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. Title : Simultaneous Bindings for Mobile IPv6 Fast Handoffs Author(s) : K. Malki, H. Soliman Filename : draft-elmalki-mobileip-bicasting-v6-00.txt Pages : 10 Date : 18-Jul-01 Fast Handover for Mobile IPv6 [Fastv6] describes a protocol to minimise the amount of service disruption when performing layer-3 handoffs. This draft extends this protocol by adding the simultaneous bindings functionality as a handoff smoothing technique. Traffic for the MN is therefore bicast or n-cast for a short period to its current location and to one or more locations where the MN is expected to move to shortly. This removes the timing ambiguity regarding when to start sending traffic for the MN to its new point of attachment and allows the decoupling of layer-2 and layer-3 handoffs. It also saves the MN periods of service disruption in the case of ping-pong movement. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-elmalki-mobileip-bicasting-v6-00.txt 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-elmalki-mobileip-bicasting-v6-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-elmalki-mobileip-bicasting-v6-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: <20010718142141.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-elmalki-mobileip-bicasting-v6-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-elmalki-mobileip-bicasting-v6-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010718142141.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 20 08:17:12 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA13834 for ; Fri, 20 Jul 2001 08:17: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 GAA22189; Fri, 20 Jul 2001 06:17: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 FAA14264; Fri, 20 Jul 2001 05:17:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6KCFsU05773 for mobile-ip-dist; Fri, 20 Jul 2001 05:15:54 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6KCFn005766 for ; Fri, 20 Jul 2001 05:15:49 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA25813 for ; Fri, 20 Jul 2001 05:16:02 -0700 (PDT) Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA17706 for ; Fri, 20 Jul 2001 05:16:01 -0700 (PDT) Received: from Gioconda (c2.local.ipunplugged.com [192.168.4.201]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with ESMTP id OAA27441 for ; Fri, 20 Jul 2001 14:17:46 +0200 From: "Henrik Levkowetz" To: Subject: RE: [mobile-ip] New draft on NAT-VPN traversal for Mobile IPv4 Date: Fri, 20 Jul 2001 14:15:56 +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: <4148FEAAD879D311AC5700A0C969E890049A3019@orsmsx35.jf.intel.com> Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 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 This draft (draft-adrangi-mipv4-midbox-traversal-00.txt) seems to have been announced on the IETF-Announce list, but not on the Mobile IP list. Anyway, I've read through it with interest, and the first thing to hit me was that section 4 provides detailed requirements for the proposed MIP proxy, but I find little functional description to help me understand what exactly the MIP proxy does, and what benefits it has, especially compared with the recent drafts draft-levkowetz-mobileip-nat-tunnel-00.txt and draft-vaarala-mobileip-nat-traversal-00.txt . Some better understanding appears gradually as I read the rest of the draft, but this still seems a bit backwards. Coming to section 5, it seems that the scheme described is very much more complex than the scheme described by the earlier drafts mentioned. Does it add any functionality to offset the added complexity? In section 6, it seems to me that you are solving IPsec problems which are solved in much simpler manner by the aforementioned drafts, too. Maybe we could get together in London and see if we have missed any of your capabilities in the simpler solutions described in draft-vaarala-mobileip- nat-traversal-00.txt and draft-levkowetz-mobileip-nat-tunnel-00.txt? Best regards, Henrik > > > This draft was submitted last week but has'nt made it out of the queue yet. > Posting a preview copy. > > -Prakash > <> > From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 20 10:19:19 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA16172 for ; Fri, 20 Jul 2001 10:19:18 -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 HAA13119; Fri, 20 Jul 2001 07:19: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 HAA07464; Fri, 20 Jul 2001 07:19:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6KEI2V06010 for mobile-ip-dist; Fri, 20 Jul 2001 07:18:02 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6KEHx006003 for ; Fri, 20 Jul 2001 07:17:59 -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 HAA15916 for ; Fri, 20 Jul 2001 07:18:10 -0700 (PDT) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA11890 for ; Fri, 20 Jul 2001 08:19:30 -0600 (MDT) Received: by megisto-sql1.megisto.com with Internet Mail Service (5.5.2650.21) id ; Fri, 20 Jul 2001 10:16:49 -0400 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] proposed agenda Date: Fri, 20 Jul 2001 10:16:49 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) 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: Hi, the draft has now appeared in the directories. It would be good to start a dialog on the draft stating what you'd like to do with it, why it is important, and why the working group should take action on it. Everyone can go read it and if there is sufficient interest and need some time may be allocated to discuss it in London. Phil > -----Original Message----- > From: Karim El-Malki (ERA) [mailto:Karim.El-Malki@era.ericsson.se] > Sent: Wednesday, July 18, 2001 1:15 PM > To: 'mobile-ip@sunroof.eng.sun.com' > Subject: RE: [mobile-ip] proposed agenda > > > Hello Phil > > > v6 Fast Handover draft-ietf-mobileip-fast-mipv6-01.txt > > BETH addition? James 10 minutes draft-kempf-beth-ipv6-01.txt > > Implementation experience report Rajeev Koodli 10 minutes > > This round there are 2 proposals for addition to v6 fast handoffs > which are BETH (which also addresses BET w/bicasting: BETB) and a > bicasting addition to the current fastv6 draft: > draft-elmalki-mobileip-bicasting-v6-00.txt. > Why is the bicasting draft not in the agenda? It is an unsolved issue > from the v6 design team which we had planned to get WG feedback on > as it did not make it into the draft. > > Rgds > /Karim > From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 20 10:38:47 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA21753 for ; Fri, 20 Jul 2001 10:38:46 -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 HAA20160; Fri, 20 Jul 2001 07:39: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 HAA22931; Fri, 20 Jul 2001 07:38:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6KEbd706105 for mobile-ip-dist; Fri, 20 Jul 2001 07:37:39 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6KEba006098 for ; Fri, 20 Jul 2001 07:37:36 -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 HAA22805 for ; Fri, 20 Jul 2001 07:37:48 -0700 (PDT) From: Franck.Le@nokia.com Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA22777 for ; Fri, 20 Jul 2001 08:37:46 -0600 (MDT) Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f6KEbni26180 for ; Fri, 20 Jul 2001 09:37:49 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Fri, 20 Jul 2001 09:37:46 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.1600); Fri, 20 Jul 2001 09:37:46 -0500 content-class: urn:content-classes:message Subject: RE: [mobile-ip] Dynamic Home Agent Address Discovery mechanism Date: Fri, 20 Jul 2001 09:37:46 -0500 Message-ID: <57A26D272F67A743952F6B4371B8F81108C1E0@daebe007.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 Thread-Topic: [mobile-ip] Dynamic Home Agent Address Discovery mechanism Thread-Index: AcEQo7FmPWm0Z3yUEdWBSQBQi2X+DwAhIXBQ To: X-OriginalArrivalTime: 20 Jul 2001 14:37:46.0654 (UTC) FILETIME=[8B0163E0:01C11129] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f6KEba006099 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 => Understood, but I was wondering whether there is a great advantage in hiding one HA vs many. Anyway, when you talk about your proposal are you referring to the DIAMETER extensions draft ? I have some comments on it. I suppose I can send them to the list after the draft deadline. If you're referring to another proposal I'd appreciate a pointer. Hello Hesham, Well the question is "Can you really hide the identity of your HAs?" And from the current spec, that is not totally possible. But it should also be made more difficult to obtain the identity of the HAs in a network. The current discovery mechanism allows just about anyone to send the ICMP discovery request and obtain a list of all HAs in the network. So it really boils down to making it a little more difficult to learn the identity of HAs. And again to emphasize, the suggestion is to have security parameters in the discovery message be optional. The suggestion above does not have anything to do with the Diameter for MIPv6 draft. The proposal being discussed here is to include this option in the MIPv6 spec. Best Regards, Franck From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 20 10:57:42 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA27304 for ; Fri, 20 Jul 2001 10:57:42 -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 HAA27371; Fri, 20 Jul 2001 07:58:16 -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 HAA26182; Fri, 20 Jul 2001 07:58:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6KEuxg06183 for mobile-ip-dist; Fri, 20 Jul 2001 07:56:59 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6KEut006176 for ; Fri, 20 Jul 2001 07:56:55 -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 HAA23734 for ; Fri, 20 Jul 2001 07:57:07 -0700 (PDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA08316 for ; Fri, 20 Jul 2001 08:57:04 -0600 (MDT) Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f6KEv5O13050 for ; Fri, 20 Jul 2001 16:57:05 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Fri Jul 20 16:57:01 2001 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 20 Jul 2001 16:51:00 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008B32@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] proposed agenda Date: Fri, 20 Jul 2001 16:57:00 +0200 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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hello Phil, I agree that it is important to discuss this issue on the mailing list and I hope that people will express their opinions on the draft so we can resolve this long lasting open issue. However, I believe that there is a valid point being raised here regarding the inclusion of this draft in the agenda. - The draft is not a new idea that was developed recently. The idea was presented in Adelaide last year for MIPv6, and was included in the original versions of the Fast Handoffs draft (the personal one from Karim and myself and the first design team draft). - The idea was discussed several times on the mailing list with some support and some criticism, but no clear conensus. - In the last design team meeting in Minneapolis it was agreed that due to lack of consensus on the issue, bicasting was removed from the draft and it was agreed by all members of the design team that 1. A separate draft will be written 2. There is a problem with the current draft in the support of ping pong. Finally, the exact same concept is being used in MIPv4 and the low latency draft. Now that other new solutions are being proposed to improve the Fast Handoffs for MIPv6 (like BETH which also supports a certain mode of bicasting) and are being included in the agenda, I must question why this draft isn't ? I believe there is clearly an open issue here for some months that needs to be resolved. So why is it not prioritised in the agenda ? Regards, Hesham > -----Original Message----- > From: Phil Roberts [SMTP:PRoberts@MEGISTO.com] > Sent: Friday, 20 July 2001 4:17 > To: 'mobile-ip@sunroof.eng.sun.com' > Subject: RE: [mobile-ip] proposed agenda > > Hi, > > the draft has now appeared in the directories. It would be good to > start a dialog on the draft stating what you'd like to do with it, > why it is important, and why the working group > should take action on it. Everyone can go read it and if there is > sufficient interest and need some time may be allocated to discuss > it in London. > Phil > > > > -----Original Message----- > > From: Karim El-Malki (ERA) [mailto:Karim.El-Malki@era.ericsson.se] > > Sent: Wednesday, July 18, 2001 1:15 PM > > To: 'mobile-ip@sunroof.eng.sun.com' > > Subject: RE: [mobile-ip] proposed agenda > > > > > > Hello Phil > > > > > v6 Fast Handover draft-ietf-mobileip-fast-mipv6-01.txt > > > BETH addition? James 10 minutes draft-kempf-beth-ipv6-01.txt > > > Implementation experience report Rajeev Koodli 10 minutes > > > > This round there are 2 proposals for addition to v6 fast handoffs > > which are BETH (which also addresses BET w/bicasting: BETB) and a > > bicasting addition to the current fastv6 draft: > > draft-elmalki-mobileip-bicasting-v6-00.txt. > > Why is the bicasting draft not in the agenda? It is an unsolved issue > > from the v6 design team which we had planned to get WG feedback on > > as it did not make it into the draft. > > > > Rgds > > /Karim > > From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 20 11:01:08 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA27970 for ; Fri, 20 Jul 2001 11:01:07 -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 IAA28790; Fri, 20 Jul 2001 08:01:39 -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 IAA26844; Fri, 20 Jul 2001 08:01:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6KF0BJ06229 for mobile-ip-dist; Fri, 20 Jul 2001 08:00:11 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6KF07006222 for ; Fri, 20 Jul 2001 08:00:07 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA24269 for ; Fri, 20 Jul 2001 08:00:20 -0700 (PDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA28699 for ; Fri, 20 Jul 2001 08:00:18 -0700 (PDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f6KF0GN26415 for ; Fri, 20 Jul 2001 17:00:16 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Fri Jul 20 17:00:15 2001 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 20 Jul 2001 16:54:11 +0200 Message-ID: <795A014AF92DD21182AF0008C7A404320C520477@esealnt117> From: "Karim El-Malki (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] WG feedback on bicasting Date: Fri, 20 Jul 2001 17:00: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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hello folks We'd like to have feedback on the following draft: http://www.ietf.org/internet-drafts/draft-elmalki-mobileip-bicasting-v6-00.txt This describes a technique to reduce packet loss during the handover (i.e. smoothing) and to support l2-handover failure or ping-pong. This is meant for addition to the fast handover v6 draft. It was discussed in the fast handover mipv6 design team and it was decided to ask the WG for feedback on whether to include this in the fastv6 draft. The equivalent draft for MIPv4 (low latency v4) already includes this technique so we're proposing to include this optional function in v6 as well. What do people think about this? Regards /Karim > -----Original Message----- > From: Phil Roberts [mailto:PRoberts@MEGISTO.com] > Sent: den 20 juli 2001 16:17 > To: 'mobile-ip@sunroof.eng.sun.com' > Subject: RE: [mobile-ip] proposed agenda > > > Hi, > > the draft has now appeared in the directories. It would be good to > start a dialog on the draft stating what you'd like to do with it, > why it is important, and why the working group > should take action on it. Everyone can go read it and if there is > sufficient interest and need some time may be allocated to discuss > it in London. > > Phil > > > > -----Original Message----- > > From: Karim El-Malki (ERA) [mailto:Karim.El-Malki@era.ericsson.se] > > Sent: Wednesday, July 18, 2001 1:15 PM > > To: 'mobile-ip@sunroof.eng.sun.com' > > Subject: RE: [mobile-ip] proposed agenda > > > > > > Hello Phil > > > > > v6 Fast Handover draft-ietf-mobileip-fast-mipv6-01.txt > > > BETH addition? James 10 minutes draft-kempf-beth-ipv6-01.txt > > > Implementation experience report Rajeev Koodli 10 minutes > > > > This round there are 2 proposals for addition to v6 fast handoffs > > which are BETH (which also addresses BET w/bicasting: BETB) and a > > bicasting addition to the current fastv6 draft: > > draft-elmalki-mobileip-bicasting-v6-00.txt. > > Why is the bicasting draft not in the agenda? It is an > unsolved issue > > from the v6 design team which we had planned to get WG feedback on > > as it did not make it into the draft. > > > > Rgds > > /Karim > > > From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 20 11:14:28 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA00178 for ; Fri, 20 Jul 2001 11:14:27 -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 JAA25617; Fri, 20 Jul 2001 09:15: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 IAA29596; Fri, 20 Jul 2001 08:14:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6KFDer06318 for mobile-ip-dist; Fri, 20 Jul 2001 08:13:40 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6KFDb006311 for ; Fri, 20 Jul 2001 08:13:37 -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 IAA29348 for ; Fri, 20 Jul 2001 08:13:49 -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 JAA24373 for ; Fri, 20 Jul 2001 09:13:47 -0600 (MDT) Received: by megisto-sql1.megisto.com with Internet Mail Service (5.5.2650.21) id ; Fri, 20 Jul 2001 11:12:30 -0400 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] proposed agenda Date: Fri, 20 Jul 2001 11:12:28 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) 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: Your history is correct and the issue seems to need some face time. Would like some WG feedback on the draft which just became available. Would also like to know whether you intend for it to be added to the FMIP draft, the V6 draft, both, or as a separate specification that could be used in either or both. > -----Original Message----- > From: Hesham Soliman (ERA) [mailto:Hesham.Soliman@era.ericsson.se] > Sent: Friday, July 20, 2001 10:57 AM > To: 'mobile-ip@sunroof.eng.sun.com' > Subject: RE: [mobile-ip] proposed agenda > > > Hello Phil, > > I agree that it is important to discuss this issue on the > mailing list and I hope that people will express their > opinions on the draft so we can resolve this long lasting > open issue. > > However, I believe that there is a valid point being raised > here regarding the inclusion of this draft in the agenda. > > - The draft is not a new idea that was developed recently. > The idea was presented in Adelaide last year for MIPv6, > and was included in the original versions of the Fast > Handoffs draft (the personal one from Karim and myself and > the first design team draft). > > - The idea was discussed several times on the mailing list > with some support and some criticism, but no clear > conensus. > > - In the last design team meeting in Minneapolis it was > agreed that due to lack of consensus on the issue, > bicasting was removed from the draft and it was agreed > by all members of the design team that > 1. A separate draft will be written > 2. There is a problem with the current draft in the support > of ping pong. > > Finally, the exact same concept is being used in MIPv4 > and the low latency draft. > > Now that other new solutions are being proposed to improve > the Fast Handoffs for MIPv6 (like BETH which also > supports a certain mode of bicasting) and are being included > in the agenda, I must question why this draft isn't ? > I believe there is clearly an open issue here for some months > that needs to be resolved. So why is it not prioritised in > the agenda ? > > > Regards, > Hesham > > > > -----Original Message----- > > From: Phil Roberts [SMTP:PRoberts@MEGISTO.com] > > Sent: Friday, 20 July 2001 4:17 > > To: 'mobile-ip@sunroof.eng.sun.com' > > Subject: RE: [mobile-ip] proposed agenda > > > > Hi, > > > > the draft has now appeared in the directories. It would > be good to > > start a dialog on the draft stating what you'd like to do with it, > > why it is important, and why the working group > > should take action on it. Everyone can go read it and if there is > > sufficient interest and need some time may be allocated to discuss > > it in London. > > Phil > > > > > > > -----Original Message----- > > > From: Karim El-Malki (ERA) [mailto:Karim.El-Malki@era.ericsson.se] > > > Sent: Wednesday, July 18, 2001 1:15 PM > > > To: 'mobile-ip@sunroof.eng.sun.com' > > > Subject: RE: [mobile-ip] proposed agenda > > > > > > > > > Hello Phil > > > > > > > v6 Fast Handover draft-ietf-mobileip-fast-mipv6-01.txt > > > > BETH addition? James 10 minutes draft-kempf-beth-ipv6-01.txt > > > > Implementation experience report Rajeev Koodli 10 minutes > > > > > > This round there are 2 proposals for addition to v6 fast handoffs > > > which are BETH (which also addresses BET w/bicasting: BETB) and a > > > bicasting addition to the current fastv6 draft: > > > draft-elmalki-mobileip-bicasting-v6-00.txt. > > > Why is the bicasting draft not in the agenda? It is an > unsolved issue > > > from the v6 design team which we had planned to get WG feedback on > > > as it did not make it into the draft. > > > > > > Rgds > > > /Karim > > > > From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 20 11:20:03 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA01135 for ; Fri, 20 Jul 2001 11:20: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 JAA01474; Fri, 20 Jul 2001 09:20: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 IAA00469; Fri, 20 Jul 2001 08:20:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6KFJGw06371 for mobile-ip-dist; Fri, 20 Jul 2001 08:19:16 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6KFJD006364 for ; Fri, 20 Jul 2001 08:19:13 -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 IAA00277 for ; Fri, 20 Jul 2001 08:19:25 -0700 (PDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA23147 for ; Fri, 20 Jul 2001 09:20:42 -0600 (MDT) Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f6KFJHO20242 for ; Fri, 20 Jul 2001 17:19:17 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Fri Jul 20 17:19:17 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Fri, 20 Jul 2001 17:19:17 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008B34@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] proposed agenda Date: Fri, 20 Jul 2001 17:19:10 +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: > Your history is correct and the issue seems to need some > face time. Would like some WG feedback on the draft which just > became available. Would also like to know whether you intend > for it to be added to the FMIP draft, the V6 draft, both, or > as a separate specification that could be used in either or both. > => The draft is intended to be part of the FMIPv6 draft. Hesham > > -----Original Message----- > > From: Hesham Soliman (ERA) [mailto:Hesham.Soliman@era.ericsson.se] > > Sent: Friday, July 20, 2001 10:57 AM > > To: 'mobile-ip@sunroof.eng.sun.com' > > Subject: RE: [mobile-ip] proposed agenda > > > > > > Hello Phil, > > > > I agree that it is important to discuss this issue on the > > mailing list and I hope that people will express their > > opinions on the draft so we can resolve this long lasting > > open issue. > > > > However, I believe that there is a valid point being raised > > here regarding the inclusion of this draft in the agenda. > > > > - The draft is not a new idea that was developed recently. > > The idea was presented in Adelaide last year for MIPv6, > > and was included in the original versions of the Fast > > Handoffs draft (the personal one from Karim and myself and > > the first design team draft). > > > > - The idea was discussed several times on the mailing list > > with some support and some criticism, but no clear > > conensus. > > > > - In the last design team meeting in Minneapolis it was > > agreed that due to lack of consensus on the issue, > > bicasting was removed from the draft and it was agreed > > by all members of the design team that > > 1. A separate draft will be written > > 2. There is a problem with the current draft in the support > > of ping pong. > > > > Finally, the exact same concept is being used in MIPv4 > > and the low latency draft. > > > > Now that other new solutions are being proposed to improve > > the Fast Handoffs for MIPv6 (like BETH which also > > supports a certain mode of bicasting) and are being included > > in the agenda, I must question why this draft isn't ? > > I believe there is clearly an open issue here for some months > > that needs to be resolved. So why is it not prioritised in > > the agenda ? > > > > > > Regards, > > Hesham > > > > > > > -----Original Message----- > > > From: Phil Roberts [SMTP:PRoberts@MEGISTO.com] > > > Sent: Friday, 20 July 2001 4:17 > > > To: 'mobile-ip@sunroof.eng.sun.com' > > > Subject: RE: [mobile-ip] proposed agenda > > > > > > Hi, > > > > > > the draft has now appeared in the directories. It would > > be good to > > > start a dialog on the draft stating what you'd like to do with it, > > > why it is important, and why the working group > > > should take action on it. Everyone can go read it and if there is > > > sufficient interest and need some time may be allocated to discuss > > > it in London. > > > Phil > > > > > > > > > > -----Original Message----- > > > > From: Karim El-Malki (ERA) [mailto:Karim.El-Malki@era.ericsson.se] > > > > Sent: Wednesday, July 18, 2001 1:15 PM > > > > To: 'mobile-ip@sunroof.eng.sun.com' > > > > Subject: RE: [mobile-ip] proposed agenda > > > > > > > > > > > > Hello Phil > > > > > > > > > v6 Fast Handover draft-ietf-mobileip-fast-mipv6-01.txt > > > > > BETH addition? James 10 minutes draft-kempf-beth-ipv6-01.txt > > > > > Implementation experience report Rajeev Koodli 10 minutes > > > > > > > > This round there are 2 proposals for addition to v6 fast handoffs > > > > which are BETH (which also addresses BET w/bicasting: BETB) and a > > > > bicasting addition to the current fastv6 draft: > > > > draft-elmalki-mobileip-bicasting-v6-00.txt. > > > > Why is the bicasting draft not in the agenda? It is an > > unsolved issue > > > > from the v6 design team which we had planned to get WG feedback on > > > > as it did not make it into the draft.> > > > > > > > > Rgds > > > > /Karim > > > > > > From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 20 11:22:07 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA01708 for ; Fri, 20 Jul 2001 11:22:05 -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 JAA04265; Fri, 20 Jul 2001 09:22: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 IAA01008; Fri, 20 Jul 2001 08:22:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6KFLc306413 for mobile-ip-dist; Fri, 20 Jul 2001 08:21:38 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6KFLZ006406 for ; Fri, 20 Jul 2001 08:21: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 IAA00853 for ; Fri, 20 Jul 2001 08:21:47 -0700 (PDT) Received: from mail.zrz.tu-berlin.de (mail.zrz.TU-Berlin.DE [130.149.4.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA03204 for ; Fri, 20 Jul 2001 09:21:45 -0600 (MDT) Received: from ftsu07.ee.tu-berlin.de ([130.149.49.87] helo=ftmail.ee.tu-berlin.de) by mail.zrz.tu-berlin.de with esmtp (exim-3.31) for id 15Nc64-0006NW-00; Fri, 20 Jul 2001 17:21:44 +0200 Received: from ee.tu-berlin.de (fu@sinope.ee.TU-Berlin.DE [130.149.49.127]) by ftmail.ee.tu-berlin.de (8.11.3/8.11.3) with ESMTP id f6KFLih26706 for ; Fri, 20 Jul 2001 17:21:44 +0200 Message-ID: <3B584C88.73BC7007@ee.tu-berlin.de> Date: Fri, 20 Jul 2001 17:21:44 +0200 From: Xiaoming Fu Organization: Telecommunication Networks Group, TU-Berlin X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.14 i686) X-Accept-Language: en-US, de, zh-CN MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] draft-tkn-mobileip-qosbinding-mipv6-00.txt References: <034BEFD03799D411A59F00508BDF754603008B22@esealnt448.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: > > Hello Hemant, > > > > > > > > You draft says that the QoS object can be transferred from old AR to new > > >AR > > > > by context tranfer framework. In that case, who sends BU to MAP? In > > >other > > > > words, it is not possible that the MN sends BU and AR "fills in" the QoS > > > > object h-b-h option as it changes IP packet length and disturbs the > > > > authentication calculation. > > > > > > > => This is one way of doing it and we are puttnig it in the appendix > > > of HMIPv6: > > > > > > - oAR triggers the handover by sending a Prrtradv > > > - In the mean time the oAR does the CT. Note that the oAR should already > > > have the QoS objects/attributes. > > > - The MN sends a BU, not to the oAR but to the MAP before > > > it moves. This BU can include a H-B-H option. > > > > > > > [Hemant] This BU MUST go through new AR towards MAP, so that it follows the > > same path as the packets would follow from the new AR. Is this satisfied in > > the above scheme? > > > => No. If you want it to go through the nAR then you can use the Network > determined model in the Fast Handoffs draft and send the BU to the > MAP after you move. > However, this goes back to my question about the use of the router > alert option. Would something like the following work: > > - oAR sends Prrtradv - What's Prrtradv? Prefix Router Renumbering advertisement or...? - To whom? If I'm right you're intending to use this message to notify nAR to pre-configure its operation for upcoming CT? Why not CT protocol do it upon the nAR's request? > - oAR does the CT to nAR > - MN sends a normal BU to the MAP (no QoS) > - nAR does a proxy RSVP to the MAP to set the outbound link > - For inbound traffic it is more difficult, perhaps one handwaving idea > would be to get oAR to do transfer the QoS context to the MAP as well ? Using bi-directional QoS objects only once from nAR to MAP (whether via CT or not) is enough, since we can setup the QoS status for downlink (as well as uplink) traffic while the QoS option travels towards the MAP. > > I'm just not sure whether linking everything to the BU is useful. Agreed. But we think BU+QoS is a nice feature to atomize the operation. And when multiple hirarchies of MAPs are used - if QoS check failed somewhere the closest next MAP may reject this binding. Xiaoming From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 20 11:31:57 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA03417 for ; Fri, 20 Jul 2001 11:31: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 JAA14575; Fri, 20 Jul 2001 09:32:20 -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 IAA22469; Fri, 20 Jul 2001 08:32:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6KFUbP06483 for mobile-ip-dist; Fri, 20 Jul 2001 08:30:37 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6KFUX006476 for ; Fri, 20 Jul 2001 08:30:33 -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 IAA00498 for ; Fri, 20 Jul 2001 08:30:42 -0700 (PDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA12780 for ; Fri, 20 Jul 2001 09:30:40 -0600 (MDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f6KFUeN05578 for ; Fri, 20 Jul 2001 17:30:40 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Fri Jul 20 17:30:39 2001 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 20 Jul 2001 17:24:35 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008B36@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] draft-tkn-mobileip-qosbinding-mipv6-00.txt Date: Fri, 20 Jul 2001 17:30:33 +0200 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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > > > => This is one way of doing it and we are puttnig it in the appendix > > > > of HMIPv6: > > > > > > > > - oAR triggers the handover by sending a Prrtradv > > > > - In the mean time the oAR does the CT. Note that the oAR should already > > > > have the QoS objects/attributes. > > > > - The MN sends a BU, not to the oAR but to the MAP before > > > > it moves. This BU can include a H-B-H option. > > > > > > > > > > [Hemant] This BU MUST go through new AR towards MAP, so that it follows the > > > same path as the packets would follow from the new AR. Is this satisfied in > > > the above scheme? > > > > > => No. If you want it to go through the nAR then you can use the Network > > determined model in the Fast Handoffs draft and send the BU to the > > MAP after you move. > > However, this goes back to my question about the use of the router > > alert option. Would something like the following work: > > > > - oAR sends Prrtradv > - What's Prrtradv? Prefix Router Renumbering advertisement or...? > => Proxy router advertisement (in the Fast Handoffs draft).. > - To whom? If I'm right you're intending to use this message to notify > nAR to pre-configure its operation for upcoming CT? Why not CT > protocol =>It's sent to the MN to notify it that a handover is about to occur. > > - oAR does the CT to nAR > > - MN sends a normal BU to the MAP (no QoS) > > - nAR does a proxy RSVP to the MAP to set the outbound link > > - For inbound traffic it is more difficult, perhaps one handwaving idea > > would be to get oAR to do transfer the QoS context to the MAP as well ? > Using bi-directional QoS objects only once from nAR to MAP (whether via > CT or > not) is enough, since we can setup the QoS status for downlink (as well > as uplink) > traffic while the QoS option travels towards the MAP. > => OK. I haven't read your draft in detail but I was assuming an asymmetric RSVP-like model. > > > > I'm just not sure whether linking everything to the BU is useful. > Agreed. But we think BU+QoS is a nice feature to atomize the operation. > And when multiple hirarchies of MAPs are used - if QoS check failed > somewhere > the closest next MAP may reject this binding. > > => Ok but you should consider the Fast Handoffs case where the BU is sent through the old AR. Can the CT be done between the oAR and the MAP as well so that the MAP can setup the down link somehow ? Hesham From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 20 12:03:10 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13541 for ; Fri, 20 Jul 2001 12:03:09 -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 JAA25186; Fri, 20 Jul 2001 09:03: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 JAA29694; Fri, 20 Jul 2001 09:03:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6KG26b06600 for mobile-ip-dist; Fri, 20 Jul 2001 09:02:06 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6KG22006593 for ; Fri, 20 Jul 2001 09:02:02 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id JAA12062; Fri, 20 Jul 2001 09:02:15 -0700 (PDT) Message-Id: <200107201602.JAA12062@heliopolis.eng.sun.com> Date: Fri, 20 Jul 2001 09:02:15 -0700 (PDT) From: James Kempf Subject: RE: [seamoby] Re: [mobile-ip] Comments on: I-D ACTION:draft-many folks-l2-mobilereq-00.txt To: mobile-ip@sunroof.eng.sun.com, seamoby@cdma-2000.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: EJf47Ekc2LIIGpqHUeHnZg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 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: George, >The AP *may* have an IP address if it is engaged in, say, IAPP like >traffic to propogate L2 trigger information. At that point, it >is acting like an IP host. > >I agree that, on a particular IP entity identified as a target, >the IP stack is the recepient of the trigger. > >Does this correspond to what you are saying? > >GT> Hmmm...you see that is what I do not like about this...I would much >better prefer not to refer to APs in this way...The L2 triggers always go to >an IP router or a host as you said...if one wants to implement an IP host in >an AP then as far as this mechanism goes this is an IP host (not an AP!). >The reason I am fussy about this is that any IETF mechanism/protocol should >be designed for the clear architectural case so it is correct...then it can >be implemented in whatever way fits the specific scenario. The other way >never works quit so well...So, lets just define the API and let people >implement it the way they need...you can even give the AP case as an >example... > I agree that the trigger ends up on the IP stack of the AR. The AP is the generating agent for the trigger, not the recipient. The table is confusing, I'll change it. >GT> I fully agree that CT should not be tight to one single mobility >protocol but I also think the API described in this spec should not be >either...these are *generic* triggers "I am coming from there"...or "I am >going there"...some of them not even mobility specific i.e.: "link up", >"link down"....These have nothing to do with any particular mobility >protocol and some of them can be used by non mobility protocols...So, I >think we should start the opposite way...assume they are the same triggers >until you find a strong reason why CT needs its own specific triggers. >Otherwise protocol X will also come later on and demand its own specific >triggers => no good.... > Actually, the spec is not describing an API, it is describing requirements. There is a separate spec in preparation for the API. As such, the requirements in Section 6.2 reflect those that come out of the CT discussion. The requirements are formulated as descriptions of abstract triggers. I agree that an API should consolodate the trigger descriptions so that only a single set appears, but they reflect the requirements from all the areas. One area that wasn't discussed in the paper is header compression. There may also be requirements for header compression, I hope perhaps to have an opportunity to speak with the ROHC folks in London on it. >P.S.: BTW, I am a bit confused with the seamoby list...you use the >seamoby@cdma-2000.org address...but when I go to though this is >seamoby@diameter.org...is this an alias of the same list? It's the same alias. jak From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 20 12:06:26 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14470 for ; Fri, 20 Jul 2001 12:06: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 KAA18157; Fri, 20 Jul 2001 10:06: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 JAA10802; Fri, 20 Jul 2001 09:06:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6KG5ie06634 for mobile-ip-dist; Fri, 20 Jul 2001 09:05:44 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6KG5e006627 for ; Fri, 20 Jul 2001 09:05:40 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA10601 for ; Fri, 20 Jul 2001 09:05:53 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA09345 for ; Fri, 20 Jul 2001 09:05:51 -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 MAA14030; Fri, 20 Jul 2001 12:04:51 -0400 (EDT) Message-Id: <200107201604.MAA14030@ietf.org> To: IETF-Announce: ; Cc: mobile-ip@sunroof.eng.sun.com From: The IESG Subject: [mobile-ip] Last Call: Generalized NAI (GNAIE) Extension to Proposed Standard Date: Fri, 20 Jul 2001 12:04:51 -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: The IESG has received a request from the IP Routing for Wireless/Mobile Hosts Working Group to consider Generalized NAI (GNAIE) Extension as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by August 17, 2001. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mobileip-gnaie-04.txt From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 20 12:08:14 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14934 for ; Fri, 20 Jul 2001 12:08:14 -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 KAA20073; Fri, 20 Jul 2001 10:08: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 JAA11230; Fri, 20 Jul 2001 09:08:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6KG7a406672 for mobile-ip-dist; Fri, 20 Jul 2001 09:07:36 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6KG7W006665 for ; Fri, 20 Jul 2001 09:07:32 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA00695 for ; Fri, 20 Jul 2001 09:07:45 -0700 (PDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA11368 for ; Fri, 20 Jul 2001 09:07: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.11.0/8.11.0/WIREfire-1.3) with SMTP id f6KG7hN13893 for ; Fri, 20 Jul 2001 18:07:43 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Fri Jul 20 18:07:43 2001 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 20 Jul 2001 18:01:39 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008B38@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Dynamic Home Agent Address Discovery mechanism Date: Fri, 20 Jul 2001 18:07:37 +0200 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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Franck, > Well the question is "Can you really hide the identity of your HAs?" And > from the current spec, that is not totally possible. But it should also > be made more difficult to obtain the identity of the HAs in a network. > The current discovery mechanism allows just about anyone to send the > ICMP discovery request and obtain a list of all HAs in the network. > So it really boils down to making it a little more difficult to learn > the identity of HAs. > => I understand your concern and appreciate the aim, but my point is that you will never by able to hide the home subnet's prefix. Granted that you can make it more difficult to find all the HAs on the link, for a price. Until we see a proposal for securing the HA discovery mechanism it is difficult to know what that price is. > And again to emphasize, the suggestion is to have security parameters in > the discovery message be optional. > => Understood, but since IPsec is not really an option here we need to evaluate the method for securing the discovery. That's why I asked if you had a proposal. Simply adding text to say it should be secure is not enough. Perhaps when the final solution comes out for securing BUs we could see if it can be reused. But so far, the solutions proposed for key exchange don't seem to work for an anycast address either, unless I missed something. Regs, Hesham From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 20 12:18:53 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17099 for ; Fri, 20 Jul 2001 12:18:53 -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 JAA01458; Fri, 20 Jul 2001 09:19:29 -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 JAA13391; Fri, 20 Jul 2001 09:19:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6KGHk406769 for mobile-ip-dist; Fri, 20 Jul 2001 09:17:46 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6KGHh006762 for ; Fri, 20 Jul 2001 09:17:43 -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 JAA11261 for ; Fri, 20 Jul 2001 09:17:56 -0700 (PDT) Received: from mail.zrz.tu-berlin.de (mail.zrz.TU-Berlin.DE [130.149.4.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA28367 for ; Fri, 20 Jul 2001 10:17:53 -0600 (MDT) Received: from ftsu07.ee.tu-berlin.de ([130.149.49.87] helo=ftmail.ee.tu-berlin.de) by mail.zrz.tu-berlin.de with esmtp (exim-3.31) for id 15NcyQ-0007gj-00; Fri, 20 Jul 2001 18:17:54 +0200 Received: from ee.tu-berlin.de (fu@sinope.ee.TU-Berlin.DE [130.149.49.127]) by ftmail.ee.tu-berlin.de (8.11.3/8.11.3) with ESMTP id f6KGHsh27775 for ; Fri, 20 Jul 2001 18:17:54 +0200 Message-ID: <3B5859B2.1C30CEE5@ee.tu-berlin.de> Date: Fri, 20 Jul 2001 18:17:54 +0200 From: Xiaoming Fu Organization: Telecommunication Networks Group, TU-Berlin X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.14 i686) X-Accept-Language: en-US, de, zh-CN MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] draft-tkn-mobileip-qosbinding-mipv6-00.txt References: <034BEFD03799D411A59F00508BDF754603008B36@esealnt448.al.sw.ericsson.se> Content-Type: text/plain; charset=gb2312 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: > > > - oAR sends Prrtradv > > - What's Prrtradv? Prefix Router Renumbering advertisement or...? > > > => Proxy router advertisement (in the Fast Handoffs draft).. > > > - To whom? If I'm right you're intending to use this message to notify > > nAR to pre-configure its operation for upcoming CT? Why not CT > > protocol > =>It's sent to the MN to notify it that a handover is about to occur. ok. Thanks for clarification. > => Ok but you should consider the Fast Handoffs case where the BU is sent > through the old AR. Can the CT be done between the oAR and the > MAP as well so that the MAP can setup the down link somehow ? We didn't consider the case of Fast Handoff - in this case I agree to do CT(oAR->MAP) when BU is sent through oAR. Xiaoming From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 20 12:35:38 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA21355 for ; Fri, 20 Jul 2001 12:35: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 KAA15271; Fri, 20 Jul 2001 10:36: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 JAA17157; Fri, 20 Jul 2001 09:35:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6KGYs006868 for mobile-ip-dist; Fri, 20 Jul 2001 09:34:54 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6KGYo006861 for ; Fri, 20 Jul 2001 09:34:50 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA07473 for ; Fri, 20 Jul 2001 09:35:03 -0700 (PDT) Received: from tama5.ecl.ntt.co.jp (tama5.ecl.ntt.co.jp [129.60.39.102]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA27336 for ; Fri, 20 Jul 2001 09:35:03 -0700 (PDT) Received: from nttmail3.ecl.ntt.co.jp (nttmail3.ecl.ntt.co.jp [129.60.39.100]) by tama5.ecl.ntt.co.jp (8.9.3+3.2W/3.7W/01/21/00) with ESMTP id BAA25383 for ; Sat, 21 Jul 2001 01:34:57 +0900 (JST) (envelope-from ohnishi.hiroyuki@lab.ntt.co.jp) Received: from eclscan3.m.ecl.ntt.co.jp by nttmail3.ecl.ntt.co.jp (8.9.3+3.2W/3.7W/03/21/01) with ESMTP id BAA24911 for ; Sat, 21 Jul 2001 01:34:56 +0900 (JST) (envelope-from ohnishi.hiroyuki@lab.ntt.co.jp) Received: from imd.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id BAA20763 for ; Sat, 21 Jul 2001 01:34:56 +0900 (JST) Received: from ohnishi-dyna ([129.60.5.144]) by imd.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id BAA08138 for ; Sat, 21 Jul 2001 01:34:54 +0900 (JST) Date: Sat, 21 Jul 2001 01:37:31 +0900 From: Hiroyuki OHNISHI To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] re:draft-ohnishi-mobileip-mbg-00.txt In-Reply-To: <697DAA22C5004B4596E033803A7CEF440967D1@daebe007.NOE.Nokia.com> References: <697DAA22C5004B4596E033803A7CEF440967D1@daebe007.NOE.Nokia.com> Message-Id: <20010721001455.4BC7.OHNISHI.HIROYUKI@lab.ntt.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.00.03 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, On Thu, 19 Jul 2001 15:03:49 -0500 Basavaraj.Patil@nokia.com wrote: > Hello, > > With MBG you are introducing another new mobility agent to achieve IP > mobility and I am not sure if the benefit outweighs the simplicity of > just having H/FAs and triangle routing. > The ideal solution would be to achieve route optimization using only > the end-points of the communication (MN-CN). But in view of such a > solution being difficult to deploy for IPv4, other approaches may need > to be considered, but I would like to get a sense of greater consensus > in the WG on this. > I agree with you. I think it is better to prepare another method which can coexist with the original route optimization. > >Glenn Morrow wrote: > > > >Hiroyuki and Yasushi, > > > >In reference to your draft: > > > >http://www.ietf.org/internet-drafts/draft-ohnishi-mobileip-mbg-00.txt > > > >I have a few questions and comments: > > > >Would the MGBs be similar or perhaps even the same border routers > >between autonomous systems of 2 ISPs such as two cellular ISPs? > > > >What signaling protocol are you looking at to distribute the fact that > >the address ranges are mobile address from the HA to the MGBs: BGP, > >OSPF, IS-IS or do you feel that this can be done with simple > >configuration? > > > >It seems to me that the conveyance of this information would also > >constitute an IP roaming agreement. An automatic, routing > >protocol-based way of setting these up would be of benefit > >IMO. Furthurmore, I believe some similar work should be done to > >identify geographical adjacency for handoff purposes. > > > >Question to the chairs and/or ADs: > > > >Would this work fall under MIP WG or routing WGs? > > > > Route optimization is within the scope of the MIP WG. However the > aspect of updating MBGs with addresses of MNs is probably outside the > scope of MIP. Especially if you are planning on using some form of > signaling or using routing protocols (as you suggest). > > >Are you planning any follow-up work on this? > > > >The expect that the antagonists to this draft may complain about the > >number of per-node routes and what this will do to the routing table > >size. Last time I checked route lookups were pretty fast in most of > >the newer products - even with fairly large routing tables; > >nevertheless, I expect there to be some contention on this. Has there > >been any analysis on this? > > > > It would be good to see some results of analysis/simulations of this > proposal. > The paper can be found at the following URL as "Mobile IP route optimization method for a carrier-scale IP network". http://www.geocities.co.jp/SiliconValley-Cupertino/8477/ In our laboratories, we made a prototype using this method to confirm the behaviors. > >Some positive comments I have on this is that it does indeed seem to > >be a very realistic deployment method for route optimization. I have > >not heard of any plans to support route optimization on IPv4 hosts by > >any of the major OS vendors. It makes sense to me to distribute the > >fact that certain addresses are mobile to portions of the network. I > >honestly believe that there are other reasons such as location privacy > >to maintain the mobile bindings in routers as well. I believe that > >such functions are better left in purpose built machines that handle > >handle fast lookups on relatively large route tables. Some analysis on > >this aspect would also be useful? > > > >Another thing I would like to bring up to folks on the list is that > >even in IPv6, there is no MUST that CN hosts support the binding > >functions of MIPv6. With this in mind, I expect there will be nodes > >out there that don't do it. So even in IPv6, the ubiquity of route > >optimization is still in question. This gives credence to the > >reasoning for the solution in IPv6 as well. > > > > But that's not the point. IPv6 nodes are capable of supporting route > optimization and if they choose not to, then I guess you just live > with triangle routing. But I do not see this as a reason to apply MBG > to IPv6. Also note that it is quite possible that a CN which supports > route optimization is still very much capable of rejecting a binding > update from the MN (for any number of reasons). > > > >Another thing I would like to point out that the signaling methodology > >seems quite similar, as far as the MGP querying the HA for the > >binding, to some the initial work on the GES, 8+8 concepts. You seem > >to be doing the query without having to changing the IP header or mess > >with the addressing schemas - a bonus IMHO. The fact that you are > >using the mobile IP HA instead of something like DNS is also a good > >idea IMO due to speed and an already overloaded DNS. > > > >It also seems to me that this would allow IPv4 ISPs to offer the > >service without having to fork-lift all of their clients' host > >operating systems. A money saving and realistic idea. > > > >On the analysis questions - are there any papers available which > >explore these topics you could point us to? > > > >Thanks, > > > >Glenn > > Cheers, > -Basavaraj > > Thanks, Hiroyuki From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 20 12:36:00 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA21429 for ; Fri, 20 Jul 2001 12:35:59 -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 JAA07950; Fri, 20 Jul 2001 09:35:37 -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 JAA16860; Fri, 20 Jul 2001 09:35:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6KGXtQ06850 for mobile-ip-dist; Fri, 20 Jul 2001 09:33:55 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6KGXq006843 for ; Fri, 20 Jul 2001 09:33:52 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA16614 for ; Fri, 20 Jul 2001 09:34:05 -0700 (PDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA26514 for ; Fri, 20 Jul 2001 09:34:04 -0700 (PDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f6KGY3N19396 for ; Fri, 20 Jul 2001 18:34:03 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Fri Jul 20 18:34:02 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Fri, 20 Jul 2001 18:34:02 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008B39@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] draft-tkn-mobileip-qosbinding-mipv6-00.txt Date: Fri, 20 Jul 2001 18:33:58 +0200 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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > => Ok but you should consider the Fast Handoffs case where the BU is sent > > through the old AR. Can the CT be done between the oAR and the > > MAP as well so that the MAP can setup the down link somehow ? > We didn't consider the case of Fast Handoff - in this case I agree to > do CT(oAR->MAP) when BU is sent through oAR. > => Ok that should work I think. If you want a detailed description of the Fast Handoffs / HMIPv6 operation have a look at Appendix A of the HMIPv6 draft (rev 04) which will be submitted today. I'll send a URL to the list. Hesham From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 20 12:37:41 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA21867 for ; Fri, 20 Jul 2001 12:37:41 -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 KAA17224; Fri, 20 Jul 2001 10:38:17 -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 JAA17805; Fri, 20 Jul 2001 09:38:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6KGbAZ06906 for mobile-ip-dist; Fri, 20 Jul 2001 09:37:10 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6KGb7006895 for ; Fri, 20 Jul 2001 09:37:07 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id JAA13718; Fri, 20 Jul 2001 09:37:18 -0700 (PDT) Message-Id: <200107201637.JAA13718@heliopolis.eng.sun.com> Date: Fri, 20 Jul 2001 09:37:18 -0700 (PDT) From: James Kempf Subject: RE: [mobile-ip] draft-ietf-mobileip-lmm-requirements-00.txt To: carlw@jurassic.Eng.Sun.COM, mobile-ip@sunroof.eng.sun.com Cc: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 557tWVlpXce3ltEgOXu3lw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 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: >> 3.4.4 Optimized signaling within the administrative domain >> By its very nature, LMM reintroduces triangle routing into Mobile IPv6 >> in that all traffic must go through the LMM agent. There is no way >> to avoid this. The LMM framework SHOULD be designed in such a way >> that as to reduce the length of the unwanted triangle leg. > >I would suggest to change this paragraph as following: > >"By its very nature, LMM MAY reintroduce triangle routing into Mobile IPv6 >in that all traffic must go through the LMM agent. The LMM framework >SHOULD be designed in such a way that as to reduce the length of the >unwanted triangle leg." > >The reason for the change is that a network provider can avoid >re-introducing >triangle routing by designing its LMM domain with a single gateway and >deploying >one LMM agent per domain at the gateway. This is only one example to avoid >triangular routing. There might be other ways. > > Actually, I'm not sure I follow. Even if there is one LMM agent per domain, there will still be triangle routing - one leg from the CN to the agent, another from the agent to the MN. jak From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 20 12:55:56 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA27102 for ; Fri, 20 Jul 2001 12:55:55 -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 KAA03144; Fri, 20 Jul 2001 10:56: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 JAA23020; Fri, 20 Jul 2001 09:56:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6KGtCi07061 for mobile-ip-dist; Fri, 20 Jul 2001 09:55:12 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6KGt8007054 for ; Fri, 20 Jul 2001 09:55:08 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA23088 for ; Fri, 20 Jul 2001 09:55:21 -0700 (PDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA08446 for ; Fri, 20 Jul 2001 09:55:16 -0700 (PDT) Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f6KGtFO10974 for ; Fri, 20 Jul 2001 18:55:15 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Fri Jul 20 18:55:11 2001 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 20 Jul 2001 18:49:10 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008B3A@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] draft-ietf-mobileip-lmm-requirements-00.txt Date: Fri, 20 Jul 2001 18:55:09 +0200 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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: James, > > > >I would suggest to change this paragraph as following: > > > >"By its very nature, LMM MAY reintroduce triangle routing into Mobile IPv6 > >in that all traffic must go through the LMM agent. The LMM framework > >SHOULD be designed in such a way that as to reduce the length of the > >unwanted triangle leg." > > > >The reason for the change is that a network provider can avoid > >re-introducing > >triangle routing by designing its LMM domain with a single gateway and > >deploying > >one LMM agent per domain at the gateway. This is only one example to avoid > >triangular routing. There might be other ways. > > > > > > Actually, I'm not sure I follow. Even if there is one LMM agent > per domain, there will still be triangle routing - one leg from the CN > to the agent, another from the agent to the MN. > => The MN can be aware of whether a CN is in the same site or not (not only the same link but site). Based on this awareness it can choose to send a BU directly to the CN or the LMM agent. Hesham From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 20 13:56:07 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11960 for ; Fri, 20 Jul 2001 13:56:06 -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 LAA20862; Fri, 20 Jul 2001 11:55: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 KAA08858; Fri, 20 Jul 2001 10:55:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6KHsWq07313 for mobile-ip-dist; Fri, 20 Jul 2001 10:54:32 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6KHsS007306 for ; Fri, 20 Jul 2001 10:54:28 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA26675 for ; Fri, 20 Jul 2001 10:54:42 -0700 (PDT) Received: from zcars0m9.ca.nortel.com ([47.129.242.157]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA09175 for ; Fri, 20 Jul 2001 10:54:41 -0700 (PDT) Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f6KHsL910242 for ; Fri, 20 Jul 2001 13:54:21 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.ca.nortel.com; Fri, 20 Jul 2001 13:54:27 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 20 Jul 2001 13:54:28 -0400 Message-ID: From: "Hongyi Li" To: "'mobile-ip@sunroof.eng.sun.com'" , carlw@jurassic.Eng.Sun.COM Subject: RE: [mobile-ip] draft-ietf-mobileip-lmm-requirements-00.txt Date: Fri, 20 Jul 2001 13:54:25 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C11145.03B936D0" X-Orig: 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_01C11145.03B936D0 Content-Type: text/plain; charset="iso-8859-1" > -----Original Message----- > From: James Kempf [mailto:James.Kempf@Sun.COM] > Sent: Friday, July 20, 2001 12:37 PM > To: carlw@jurassic.eng.sun.com; mobile-ip@sunroof.eng.sun.com > Cc: mobile-ip@sunroof.eng.sun.com > Subject: RE: [mobile-ip] draft-ietf-mobileip-lmm-requirements-00.txt > > > >> 3.4.4 Optimized signaling within the administrative domain > >> By its very nature, LMM reintroduces triangle routing into > Mobile IPv6 > >> in that all traffic must go through the LMM agent. There is no way > >> to avoid this. The LMM framework SHOULD be designed in such a way > >> that as to reduce the length of the unwanted triangle leg. > > > >I would suggest to change this paragraph as following: > > > >"By its very nature, LMM MAY reintroduce triangle routing > into Mobile IPv6 > >in that all traffic must go through the LMM agent. The LMM framework > >SHOULD be designed in such a way that as to reduce the length of the > >unwanted triangle leg." > > > >The reason for the change is that a network provider can avoid > >re-introducing > >triangle routing by designing its LMM domain with a single > gateway and > >deploying > >one LMM agent per domain at the gateway. This is only one > example to avoid > >triangular routing. There might be other ways. > > > > > > Actually, I'm not sure I follow. Even if there is one LMM agent > per domain, there will still be triangle routing - one leg from the CN > to the agent, another from the agent to the MN. [hyli]If the CN is outside the LMM domain, CN<-> LMM agent <-> MN is the optimal route in this network configuration. If CN is inside the LMM domain, Hesham's example can provide optimal route. Another way is that LMM agent can send a binding update to the CN if it realizes the CN and MN is in the same domain. -Hongyi > > jak > > ------_=_NextPart_001_01C11145.03B936D0 Content-Type: text/html; charset="iso-8859-1" RE: [mobile-ip] draft-ietf-mobileip-lmm-requirements-00.txt

> -----Original Message-----
> From: James Kempf [mailto:James.Kempf@Sun.COM]
> Sent: Friday, July 20, 2001 12:37 PM
> To: carlw@jurassic.eng.sun.com; mobile-ip@sunroof.eng.sun.com
> Cc: mobile-ip@sunroof.eng.sun.com
> Subject: RE: [mobile-ip] draft-ietf-mobileip-lmm-requirements-00.txt
>
>
> >> 3.4.4 Optimized signaling within the administrative domain
> >> By its very nature, LMM reintroduces triangle routing into
> Mobile IPv6
> >> in that all traffic must go through the LMM agent. There is no way
> >> to avoid this. The LMM framework SHOULD be designed in such a way
> >> that as to reduce the length of the unwanted triangle leg.
> >
> >I would suggest to change this paragraph as following:
> >
> >"By its very nature, LMM MAY reintroduce triangle routing
> into Mobile IPv6
> >in that all traffic must go through the LMM agent. The LMM framework
> >SHOULD be designed in such a way that as to reduce the length of the
> >unwanted triangle leg."
> >
> >The reason for the change is that a network provider can avoid
> >re-introducing
> >triangle routing by designing its LMM domain with a single
> gateway and
> >deploying
> >one LMM agent per domain at the gateway. This is only one
> example to avoid
> >triangular routing. There might be other ways.
> >
> >
>
> Actually, I'm not sure I follow. Even if there is one LMM agent
> per domain, there will still be triangle routing - one leg from the CN
> to the agent, another from the agent to the MN.

[hyli]If the CN is outside the LMM domain, CN<-> LMM agent <-> MN is the
        optimal route in this network configuration.
        If CN is inside the LMM domain, Hesham's example can provide
        optimal route. Another way is that LMM agent can send a binding
        update to the CN if it realizes the CN and MN is in the same
        domain.

        -Hongyi



>
>               jak
>
>

------_=_NextPart_001_01C11145.03B936D0-- From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 20 14:26:22 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA21439 for ; Fri, 20 Jul 2001 14:26: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 MAA14227; Fri, 20 Jul 2001 12:26: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 LAA17072; Fri, 20 Jul 2001 11:26:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6KIPYi07409 for mobile-ip-dist; Fri, 20 Jul 2001 11:25:34 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6KIPU007402 for ; Fri, 20 Jul 2001 11:25:30 -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 LAA16821 for ; Fri, 20 Jul 2001 11:25:42 -0700 (PDT) Received: from zcars0m9.ca.nortel.com ([47.129.242.157]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA20962 for ; Fri, 20 Jul 2001 12:26:27 -0600 (MDT) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f6KIOj914087 for ; Fri, 20 Jul 2001 14:24:45 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Fri, 20 Jul 2001 14:24:48 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 20 Jul 2001 14:24:50 -0400 Message-ID: From: "Muhammad Jaseemuddin" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] draft-ietf-mobileip-lmm-requirements-00.txt Date: Fri, 20 Jul 2001 14:24:15 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C11149.2ED54C60" X-Orig: 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_01C11149.2ED54C60 Content-Type: text/plain See my comments in-line. - Muhammad Jaseemuddin > -----Original Message----- > From: Li, Hongyi [WDLN2:AN22:EXCH] > Sent: Friday, July 20, 2001 1:54 PM > To: 'mobile-ip@sunroof.eng.sun.com'; carlw@jurassic.eng.sun.com > Subject: RE: [mobile-ip] draft-ietf-mobileip-lmm-requirements-00.txt > > > > > -----Original Message----- > > From: James Kempf [ ] > > Sent: Friday, July 20, 2001 12:37 PM > > To: carlw@jurassic.eng.sun.com; mobile-ip@sunroof.eng.sun.com > > Cc: mobile-ip@sunroof.eng.sun.com > > Subject: RE: [mobile-ip] draft-ietf-mobileip-lmm-requirements-00.txt > > > > > > >> 3.4.4 Optimized signaling within the administrative domain > > >> By its very nature, LMM reintroduces triangle routing into > > Mobile IPv6 > > >> in that all traffic must go through the LMM agent. There is no way > > >> to avoid this. The LMM framework SHOULD be designed in such a way > > >> that as to reduce the length of the unwanted triangle leg. > > > > > >I would suggest to change this paragraph as following: > > > > > >"By its very nature, LMM MAY reintroduce triangle routing > > into Mobile IPv6 > > >in that all traffic must go through the LMM agent. The LMM framework > > >SHOULD be designed in such a way that as to reduce the length of the > > >unwanted triangle leg." > > > > > >The reason for the change is that a network provider can avoid > > >re-introducing > > >triangle routing by designing its LMM domain with a single > > gateway and > > >deploying > > >one LMM agent per domain at the gateway. This is only one > > example to avoid > > >triangular routing. There might be other ways. > > > > > > > > > > Actually, I'm not sure I follow. Even if there is one LMM agent > > per domain, there will still be triangle routing - one leg from the CN > > to the agent, another from the agent to the MN. > > [hyli]If the CN is outside the LMM domain, CN<-> LMM agent <-> MN is the > optimal route in this network configuration. > If CN is inside the LMM domain, Hesham's example can provide > optimal route. Another way is that LMM agent can send a binding > update to the CN if it realizes the CN and MN is in the same > domain. > > -Hongyi > > [MJ] I don't think that LMM agent will have necessary SA with CN to send BU on behalf of MN. Most likely MN will end-up sending BU directly to CN once it discovers that CN is in the same site. My understanding is MN will update CN with its LCOA. Now, LCOA changes everytime MN changes its subnet. Though this approach to route optimization is obvious and simple, it may be expensive if the MN is interacting with many on-site CNs and making lots of handovers. Now, back to James original question on Hongyi's remarks. My understanding from Hongyi's original comment is that if the LMM agent and Border Gateway Router are co-located and the CNs are located outside and there is one BGR and LMM agent, then for all the CNs outside the domain every packet will pass the BGR and LMM agent, hence there is no issue with route optimization in that case. > > > > jak > > > > > ------_=_NextPart_001_01C11149.2ED54C60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] = draft-ietf-mobileip-lmm-requirements-00.txt

See my = comments in-line.

- Muhammad = Jaseemuddin

    -----Original Message-----
    From:   Li, Hongyi [WDLN2:AN22:EXCH]
    Sent:   Friday, July 20, 2001 1:54 PM
    To:     'mobile-ip@sunroof.eng.sun.com'; = carlw@jurassic.eng.sun.com
    Subject:       = RE: [mobile-ip] = draft-ietf-mobileip-lmm-requirements-00.txt



    > -----Original = Message-----
    > From: James Kempf [ = <mailto:James.Kempf@Sun.COM>]
    > Sent: Friday, July 20, 2001 = 12:37 PM
    > To: = carlw@jurassic.eng.sun.com; mobile-ip@sunroof.eng.sun.com
    > Cc: = mobile-ip@sunroof.eng.sun.com
    > Subject: RE: [mobile-ip] = draft-ietf-mobileip-lmm-requirements-00.txt
    >
    >
    > >> 3.4.4 Optimized signaling = within the administrative domain
    > >> By its very nature, = LMM reintroduces triangle routing into
    > Mobile IPv6
    > >> in that all traffic = must go through the LMM agent. There is no way
    > >> to avoid this. The = LMM framework SHOULD be designed in such a way
    > >> that as to reduce the = length of the unwanted triangle leg.
    > >
    > >I would suggest to change = this paragraph as following:
    > >
    > >"By its very nature, = LMM MAY reintroduce triangle routing
    > into Mobile IPv6
    > >in that all traffic must = go through the LMM agent. The LMM framework
    > >SHOULD be designed in = such a way that as to reduce the length of the
    > >unwanted triangle = leg."
    > >
    > >The reason for the change = is that a network provider can avoid
    > = >re-introducing
    > >triangle routing by = designing its LMM domain with a single
    > gateway and
    > >deploying
    > >one LMM agent per domain = at the gateway. This is only one
    > example to avoid
    > >triangular routing. There = might be other ways.
    > >
    > >
    >
    > Actually, I'm not sure I follow. = Even if there is one LMM agent
    > per domain, there will still = be triangle routing - one leg from the CN
    > to the agent, another from = the agent to the MN.

    [hyli]If the CN is outside the LMM = domain, CN<-> LMM agent <-> MN is the
    =A0=A0=A0=A0=A0=A0=A0     optimal = route in this network configuration.
    =A0=A0=A0=A0=A0=A0=A0     If CN is = inside the LMM domain, Hesham's example can provide
    =A0=A0=A0=A0=A0=A0=A0     optimal = route. Another way is that LMM agent can send a binding
    =A0=A0=A0=A0=A0=A0=A0     update to = the CN if it realizes the CN and MN is in the same
    =A0=A0=A0=A0=A0=A0=A0     domain.

    =A0=A0=A0=A0=A0=A0=A0 -Hongyi


    [MJ]  I don't think that LMM agent will have necessary = SA with CN to send BU on behalf of MN. Most likely MN will end-up = sending BU directly to CN once it discovers that CN is in the same = site. My understanding is MN will update CN with its LCOA. Now, LCOA = changes everytime MN changes its subnet. Though this approach to route = optimization is obvious and simple, it may be expensive if the MN is = interacting with many on-site CNs and making lots of = handovers.

    Now, back to = James original question on Hongyi's remarks. My understanding from = Hongyi's original comment is that if the LMM agent and Border Gateway = Router are co-located and the CNs are located outside and there is one = BGR and LMM agent, then for all the CNs outside the domain every packet = will pass the BGR and LMM agent, hence there is no issue with route = optimization in that case.



    >
    > =A0=A0=A0=A0=A0 = =A0=A0=A0=A0=A0=A0=A0 jak
    >
    >=20

------_=_NextPart_001_01C11149.2ED54C60-- From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 20 14:33:18 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA23566 for ; Fri, 20 Jul 2001 14:33: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 LAA07832; Fri, 20 Jul 2001 11:33:47 -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 LAA18888; Fri, 20 Jul 2001 11:33:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6KIWXm07470 for mobile-ip-dist; Fri, 20 Jul 2001 11:32:33 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6KIWT007463 for ; Fri, 20 Jul 2001 11:32:29 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA06098 for ; Fri, 20 Jul 2001 11:32:41 -0700 (PDT) Received: from hotmail.com (f189.law7.hotmail.com [216.33.237.189]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA01524 for ; Fri, 20 Jul 2001 11:32:41 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 20 Jul 2001 11:32:40 -0700 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Fri, 20 Jul 2001 18:32:40 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] draft-tkn-mobileip-qosbinding-mipv6-00.txt Date: Fri, 20 Jul 2001 18:32:40 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 20 Jul 2001 18:32:40.0867 (UTC) FILETIME=[5BCF9F30:01C1114A] 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: Why do we need CT(oldAR to MAP)? Since downlink data flows thorugh MAP and assuming that QoS was established using h-b-h option, MAP can just store that object along with mobility bindings. So when it receives BU from whaterver router (old or new) for this binding, it knows how to and where to send h-b-h option in BA. Doing CT from AR to MAP will open up can of worms each worm trying to do CT between AR and its application proxy. Hemant >From: "Hesham Soliman (ERA)" >Reply-To: mobile-ip@sunroof.eng.sun.com >To: "'mobile-ip@sunroof.eng.sun.com'" >Subject: RE: [mobile-ip] draft-tkn-mobileip-qosbinding-mipv6-00.txt >Date: Fri, 20 Jul 2001 18:33:58 +0200 > > > > => Ok but you should consider the Fast Handoffs case where the >BU is sent > > > through the old AR. Can the CT be done between the oAR and the > > > MAP as well so that the MAP can setup the down link somehow ? > > We didn't consider the case of Fast Handoff - in this case I agree to > > do CT(oAR->MAP) when BU is sent through oAR. > > > => Ok that should work I think. If you want a detailed description > of the Fast Handoffs / HMIPv6 operation have a look at Appendix A > of the HMIPv6 draft (rev 04) which will be submitted today. I'll send > a URL to the list. > > Hesham _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 20 14:49:47 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA28488 for ; Fri, 20 Jul 2001 14:49:46 -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 LAA16299; Fri, 20 Jul 2001 11:50:21 -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 LAA19379; Fri, 20 Jul 2001 11:49:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6KImRj07593 for mobile-ip-dist; Fri, 20 Jul 2001 11:48:27 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6KImN007586 for ; Fri, 20 Jul 2001 11:48:23 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA19085 for ; Fri, 20 Jul 2001 11:48:36 -0700 (PDT) From: Basavaraj.Patil@nokia.com Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA10196 for ; Fri, 20 Jul 2001 11:48:29 -0700 (PDT) Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f6KImVi24800 for ; Fri, 20 Jul 2001 13:48:32 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Fri, 20 Jul 2001 13:48:29 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.1600); Fri, 20 Jul 2001 13:48:29 -0500 content-class: urn:content-classes:message Subject: RE: [mobile-ip] Subnet vs Link Date: Fri, 20 Jul 2001 13:48:29 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF44086098@daebe007.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [mobile-ip] Subnet vs Link X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 Thread-Index: AcEQ7Vc6gEyYd3zeEdWxLgAIx6TWeAAXy/Tw To: Cc: X-OriginalArrivalTime: 20 Jul 2001 18:48:29.0245 (UTC) FILETIME=[91169ED0:01C1114C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f6KImO007587 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 Thanks for pointing it out. We will take into account in the next revision of the draft. > -----Original Message----- > From: ext Francis Dupont [mailto:Francis.Dupont@enst-bretagne.fr] > Sent: Friday, July 20, 2001 2:26 AM > To: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Subnet vs Link > > > I just found that mipv6-sec-reqts-00.txt uses terminology > both 'subnet' and > 'link' in one document. > > In some sense, I regard they are different. In other > sense, I don't see any > difference. By the way, I didn't know that IPv6 also has > the concept of > 'subnet'. > > Can anyone give me clear explanation? > > => this seems to be just a mistake: I believe only the word > 'link' should > be used because only the word 'link' is clearly defined in > IPv6 documents. > The word 'subnet' (subnetwork in fact) is the generic 'OSI > ISO' term but > its meaning for IPv4 is a bit different so it can be ambiguous. > > Regards > > Francis.Dupont@enst-bretagne.fr > From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 20 15:09:47 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA04041 for ; Fri, 20 Jul 2001 15:09:46 -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 NAA16036; Fri, 20 Jul 2001 13:10:18 -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 MAA23332; Fri, 20 Jul 2001 12:09:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6KJ88907692 for mobile-ip-dist; Fri, 20 Jul 2001 12:08:08 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6KJ85007685 for ; Fri, 20 Jul 2001 12:08:05 -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 MAA13582 for ; Fri, 20 Jul 2001 12:08:17 -0700 (PDT) Received: from zcars0m9.ca.nortel.com ([47.129.242.157]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA14669 for ; Fri, 20 Jul 2001 13:08:15 -0600 (MDT) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f6KJ7u919901 for ; Fri, 20 Jul 2001 15:07:56 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Fri, 20 Jul 2001 15:07:55 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 20 Jul 2001 15:07:58 -0400 Message-ID: From: "Muhammad Jaseemuddin" To: "'mobile-ip@sunroof.eng.sun.com'" Cc: carlw@jurassic.Eng.Sun.COM Subject: [mobile-ip] some more comments on draft-ietf-mobileip-lmm-requirements-00.txt Date: Fri, 20 Jul 2001 15:07:53 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1114F.47544C40" X-Orig: 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_01C1114F.47544C40 Content-Type: text/plain Hi Carl: Thanks for putting together a well-written draft. Please find my comments below. 1. Section 1.0 I am not sure whether the user can gain the benefit of smoother hand-off through LMM. I think it is the handover scheme (e.g. Fast Handover) that provides smoot handoff. And also smoother in comparison with what? perhaps MIPv6. May be it should be stated in intro section that reference point for all comparisons is MIPv6. 2. There is a dangling reference [SubnetMobPro] in Section 3.1. 3. The section of Section 3.3.2 should be re-written as follows: "LMM-aware agents MUST be able to inter-operate with non-LMM-aware routers, hosts, home agents, and mobile nodes" This reversal of statement is necessary because it is the LMM-agent design that should incorporate necessary changes to inter-operate, not the other devices make an effort to interoperate with LMM-agents. 4. If we read 3.3.4, 3.5.2, and 3.10.1 together, then it seems that there is an inconsistency in describing reliability. Section 3.10.1 is a very soft requirement on recovery from failure, while 3.3.4 and 3.5.2 on maintaining connectivity in the presence of LMM-agent failure and service disruptio respectively. I think all three requirements should be changed to SHOULD. Because recovery from failure is essential for minimizing service disruption and maximizing connectivity. However, in case of failure of serving LMM agent, there will be some service disruption that may not be there if vanilla MIPv6 is used. Considering zero-time recovery from failure is hard to imagine. 5. I agree with Hesham that the first paragraph fo section 3.4.4 should be struck. I also suggest that "for tunnels" should be removed from the second paragraph of section 3.4.3, because it makes the sentence too solution specific. Muhammad Jaseemuddin Wireless Technology Lab Nortel Networks email: jaseem@nortelnetworks.com Phone: 613 765-7520 (ESN 395) Fax: 613 763-2686 ------_=_NextPart_001_01C1114F.47544C40 Content-Type: text/html Content-Transfer-Encoding: quoted-printable some more comments on = draft-ietf-mobileip-lmm-requirements-00.txt

Hi Carl:

 Thanks for putting together a = well-written draft. Please find my comments below.

1. Section 1.0
    I am not sure = whether the user can gain the benefit of smoother hand-off through LMM. = I think it is the handover scheme (e.g. Fast Handover) that provides = smoot handoff. And also smoother in comparison with what? perhaps = MIPv6. May be it should be stated in intro section that reference point = for all comparisons is MIPv6.

2. There is a dangling reference = [SubnetMobPro] in Section 3.1.

3. The section of Section 3.3.2 should = be re-written as follows:

"LMM-aware agents MUST be able to = inter-operate with non-LMM-aware routers, hosts, home agents, and = mobile nodes"

This reversal of statement is = necessary because it is the LMM-agent design that should incorporate = necessary changes to inter-operate, not the other devices make an = effort to interoperate with LMM-agents.

4. If we read 3.3.4, 3.5.2, and 3.10.1 = together, then it seems that there is an inconsistency in describing = reliability. Section 3.10.1 is a very soft requirement on recovery from = failure, while 3.3.4 and 3.5.2 on maintaining connectivity in the = presence of LMM-agent failure and service disruptio respectively. I = think all three requirements should be changed to SHOULD. Because = recovery from failure is essential for minimizing service disruption = and maximizing connectivity. However, in case of failure of serving LMM = agent, there will be some service disruption that may not be there if = vanilla MIPv6 is used. Considering zero-time recovery from failure is = hard to imagine.

5. I agree with Hesham that the first = paragraph fo section 3.4.4 should be struck. I also suggest that = "for tunnels" should be removed from the second paragraph of = section 3.4.3, because it makes the sentence too solution = specific.

Muhammad Jaseemuddin    =        =20
 Wireless = Technology Lab        =        
Nortel = Networks
email:   = jaseem@nortelnetworks.com
Phone:  613 = 765-7520 (ESN 395)
Fax:      613 763-2686

------_=_NextPart_001_01C1114F.47544C40-- From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 20 15:49:53 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA20235 for ; Fri, 20 Jul 2001 15:49:51 -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 NAA10353; Fri, 20 Jul 2001 13:50: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 MAA03316; Fri, 20 Jul 2001 12:50:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6KJmga07804 for mobile-ip-dist; Fri, 20 Jul 2001 12:48:42 -0700 (PDT) Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6KJmd007797 for ; Fri, 20 Jul 2001 12:48:40 -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 PAA13456 for ; Fri, 20 Jul 2001 15:48:51 -0400 (EDT) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id PAA06155 for mobile-ip@sunroof.eng.sun.com; Fri, 20 Jul 2001 15:49:15 -0400 (EDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6KCYh005831 for ; Fri, 20 Jul 2001 05:34:43 -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 FAA07007 for ; Fri, 20 Jul 2001 05:34:56 -0700 (PDT) Received: from newman.gte.com ([132.197.8.26]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA01815 for ; Fri, 20 Jul 2001 06:34:54 -0600 (MDT) Received: from rcmppc2.gte.com (rcmppc2.gte.com [132.197.73.30]) by newman.gte.com (8.9.1/8.9.1) with ESMTP id IAA12387; Fri, 20 Jul 2001 08:34:55 -0400 (EDT) Message-Id: <5.1.0.14.2.20010720082247.00acb610@pophost.gte.com> X-Sender: sjj0/pophost.gte.com@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 20 Jul 2001 08:33:54 -0400 To: mobile-ip@sunroof.eng.sun.com From: Stuart Jacobs Subject: [mobile-ip] A public key authenticated MIPv4 available 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: We are submitting, as soon as the submission window reopens, the file draft-jacobs-mobileip-pki-auth-02.txt for consideration by the IP Routing for Wireless/Mobile Hosts (mobileip) WG. This draft describes a set of extensions made to MIP for IPv4 that allows MNs, HAs, and FAs to use public key digital signatures for authenticating MIP control messages. This code will work with self signed certificates as well as CA signed certificates. Consequently a full PKI is NOT necessary. We have developed a companion security service middle-ware set of functions (pkail) that provides the encryption and certificate management functions for this version of MIP code. The pkail code includes functionality for creating X.509 certificates that are self signed or allows you to create one or more CA hierarchies. Both sets of code are available under the GNU copy left. To obtain this code just send us an Email. Available, via Email, is a tgz file which contains a user space MIPv4 that does public key authentication between mobile nodes, home and foreign agents. The readme.txt file provides a description of what is in the distribution, how to install it, how to configure it and how to rebuild it. Also available is a .tgz file with a version of our public key middleware code upon which the MIP release is based. You must independently acquire the RSA Security B-Safe library and in have this library installed before installing the pkail code. Both sets of code build and execute on Red Hat distributions using linux 2.0.x and 2.2.x kernels. ========================== Stuart Jacobs CISSP Sr. Technologist Verizon Laboratories 40 Sylvan Road Waltham, MA 02451-1128 USA telephone: (781) 466-3076 fax: (781) 466-2838 stu.jacobs@verizon.com sjj0@gte.com ========================== From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 20 15:54:09 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA21950 for ; Fri, 20 Jul 2001 15:54:04 -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 NAA12737; Fri, 20 Jul 2001 13:54:34 -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 MAA04131; Fri, 20 Jul 2001 12:54:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6KJr2x07858 for mobile-ip-dist; Fri, 20 Jul 2001 12:53:02 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6KJqx007851 for ; Fri, 20 Jul 2001 12:52:59 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA04726 for ; Fri, 20 Jul 2001 12:53:11 -0700 (PDT) From: haihong.zheng@nokia.com Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA29969 for ; Fri, 20 Jul 2001 12:53:11 -0700 (PDT) Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f6KJrCi03621 for ; Fri, 20 Jul 2001 14:53:12 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Fri, 20 Jul 2001 14:53:10 -0500 Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.1600); Fri, 20 Jul 2001 14:53:10 -0500 content-class: urn:content-classes:message Subject: [mobile-ip] draft-shen-rsvp-mobileipv6-interop-00.txt Date: Fri, 20 Jul 2001 14:53:09 -0500 Message-ID: <748E8123D183394982E32A511DB3E7360C807C@daebe005.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: Latest revision of the Internet-Draft X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 Thread-Index: AcELjL0HiGF8GXd+EdWBSQBQi2X+DwAJpzlAAWglX1A= To: X-OriginalArrivalTime: 20 Jul 2001 19:53:10.0332 (UTC) FILETIME=[9A657FC0:01C11155] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f6KJqx007852 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 Hi, We recently submit a new ID titled "An Interoperation Framework for Using RSVP in Mobile IPv6 Networks". This draft proposes a Mobile IPv6 and RSVP interoperation scheme. In this scheme, the underlying mobility support mechanism is required to provide a unique flow identity regardless of node mobility, making the node mobility transparent to flow QoS handling mechanisms. Thus QoS signaling delay as well as data packet delays and losses during handoff can be reduced. You can find the draft at http://www.ietf.org/internet-drafts/draft-shen-rsvp-mobileipv6-interop-0 0.txt. Comments and suggestions are very welcome. BR, Haihong -- Haihong Zheng Mobile Networks Laboratory Nokia Research Center, Irving, Texas, USA From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 20 17:06:06 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17850 for ; Fri, 20 Jul 2001 17:06:05 -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 PAA01810; Fri, 20 Jul 2001 15:06: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 OAA15067; Fri, 20 Jul 2001 14:06:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6KL4lg08148 for mobile-ip-dist; Fri, 20 Jul 2001 14:04:47 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6KL4h008141 for ; Fri, 20 Jul 2001 14:04:43 -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 OAA17606 for ; Fri, 20 Jul 2001 14:04:57 -0700 (PDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id PAA00787 for ; Fri, 20 Jul 2001 15:04:54 -0600 (MDT) Received: (qmail 31456 invoked by uid 500); 20 Jul 2001 20:53:56 -0000 Date: Fri, 20 Jul 2001 13:53:56 -0700 From: Pat Calhoun To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: mobile-ip] WG last call: draft-ietf-mobileip-gen-key-00.txt Message-ID: <20010720135356.W14672@charizard.diameter.org> References: <20010718115752.A689@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010718115752.A689@cisco.com>; from mchandra@cisco.com on Wed, Jul 18, 2001 at 11:57:52AM -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: On Wed, Jul 18, 2001 at 11:57:52AM -0400, Madhavi W. Chandra wrote: > Hi Charlie and Pat, > > We've just started following this draft and are trying to grasp its > intent. We have a few questions/comments: > > 1. Since it is not specified, can the 'Reply' Key extensions be > appended to both RPYs and RRQs? No. Request goes in Registration Request, while Reply goes in the Registration Reply. > > 2. Section 7, 'FA-FA Key Reply Subtype Data' sounds like a > description for MN-HA Reply. I think you mean FA-HA, and the text is incorrect. > > 3. Are the 'Reply' Key extensions in Sections 6 and 7 sent > unsolicited by a mobility agent (MA)? Actually, who is sending these > extensions and how do they even know to send these extension? Also, > in what MIP messages are these being sent? Please explain this a bit. AS far as section 6, its use depends upon the context. As far as AAA is concerned, it isn't used because AAA transfers the keying information instead of within MIP. However, I presume that there are cases where the FA and/or HA wish to exchange keying information. We decided that it made sense to include this case, since it will most likely be needed sometime in the future. As far as section 7, it could be useful in hierarchical scenarios. > > 4. Can the 'Reply' Key extensions in Sections 3 and 5 be sent > unsolicited to the MN...meaning, not in response to a 'Request' Key > extension. if it is requested, then it is returned. However, it *could* be unsolicited. > 5. Curious...why separate Types for each message? Why not > Type = Key Distribution message, > Subtype = MN-HA, MN-FA, FA-HA, etc > First byte of Subtype = serve purpose of current Subtype? We thought that a separate type for each peer set made sense. We don't use that many, and even if a subtype wasn't recognized, you'd still have an idea whether you need the key or not (and return the appropriate error). Example. Let's assume an FA receives a packet with one of these mumbo extensions you mention above. If the subtype isn't recognized, it doesn't know whether the key is destined for it or not. Perhaps the key is really for the mobile node instead. Make sense? > 6. When MN sends 'MN-HA Key Request' extension in RRQ, does it append > MN-AAA AE since no MHAE? So, AAA is doing proxy authentication of MN > for the HA? Then, HA sends RPY with 'MN-HA Key Reply' > extension...what AE is used to secure the RPY? They are independent. If the MN includes the MN-HA Key Request with the AAA subtype (see AAA keys draft), then it really should include the MN-AAA extension. However, these are separate drafts, and it makes sense to leave it that way. You are correct, though, that the HA would include the MN-HA Key Reply extenion in the reply message, with the MN-HA auth ext generated using the newly distributed key. > > 7. We would like a mobility agent, say MA-1, to pass key to MA-2 for > MA-2 to use with MN. If MAs are FAs, then probably the FA-FA Key > Reply Extension would be used...appended to what MIP message? What if > the MAs are HAs? Since this behavior hasn't been defined, I cannot claim to know. This draft only defines the generalized extensions, but separate extension documents would describe how they are used. aaa keys is one such example. > 8. Section on user scenarios would be helpful...mention that the AAA > Registration Keys draft is an instantiation of this draft. A simple > user scenario would illustrate the intent of the draft. We had decided NOT to create a double link list. The AAA keys draft already points to this draft, and the other way around doesn't make a whole lot of sense. The AAA draft, which describes subtypes, provides the needed illustration. I would hate to have to copy that text into this simple draft, because it is so AAA specific. Thanks, PatC > > Thanks, > Madhavi > > On Fri, Jul 06, 2001 at 01:55:02PM -0400, Phil Roberts wrote: > > > > This is a Mobile IP WG last call for the I-D > > draft-ietf-mobileip-gen-key-00.txt > > Generalized Key Extensions for Mobile IP. This draft will be sent to the > > IESG > > requesting a proposed standard status to be associated with it at the end of > > the last call period. Please send your comments to the WG discussion list. > > > > WG Last call issued on : Jul 5, 2001 > > Expires on : Jun 20, 2001 > > > > Basavaraj Patil > > Phil Roberts From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 20 18:35:46 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA17621 for ; Fri, 20 Jul 2001 18:35: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 QAA25596; Fri, 20 Jul 2001 16:36:16 -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 PAA09943; Fri, 20 Jul 2001 15:36:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6KMYv408349 for mobile-ip-dist; Fri, 20 Jul 2001 15:34:57 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6KMYr008342 for ; Fri, 20 Jul 2001 15:34:53 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA24494 for ; Fri, 20 Jul 2001 15:35:05 -0700 (PDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA29121 for ; Fri, 20 Jul 2001 15:35:05 -0700 (PDT) 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 f6KMXKi19676 for ; Fri, 20 Jul 2001 15:33:20 -0700 (PDT) Received: from alpesh-u5.cisco.com (alpesh-u5.cisco.com [128.107.162.126]) by mira-sjcm-2.cisco.com (Mirapoint) with SMTP id ABZ00283; Fri, 20 Jul 2001 15:35:03 -0700 (PDT) Message-Id: <200107202235.ABZ00283@mira-sjcm-2.cisco.com> Date: Fri, 20 Jul 2001 15:35:03 -0700 (PDT) From: Alpesh Patel Subject: Re: [mobile-ip] Re: mobile-ip] WG last call: draft-ietf-mobileip-gen-key-00.txt To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: iwAIueG/KeM3QzsmlB7b0Q== X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 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: Pat, Please see my questions below: > > We've just started following this draft and are trying to grasp its > > intent. We have a few questions/comments: > > > > 1. Since it is not specified, can the 'Reply' Key extensions be > > appended to both RPYs and RRQs? > > No. Request goes in Registration Request, while Reply goes in the Registration > Reply. Why this restriction? This essentially supports the request response or uninitiated response model. We envison a situation where we would need a push model to configure the keys at an entity which has not yet taken part in mobile ip signaling. We can potentially achieve the equivalent of 'push' model, but that would require two round trip worth of signaling effort. > > > > > 2. Section 7, 'FA-FA Key Reply Subtype Data' sounds like a > > description for MN-HA Reply. > > I think you mean FA-HA, and the text is incorrect. > > > > > 3. Are the 'Reply' Key extensions in Sections 6 and 7 sent > > unsolicited by a mobility agent (MA)? Actually, who is sending these > > extensions and how do they even know to send these extension? Also, > > in what MIP messages are these being sent? Please explain this a bit. > > AS far as section 6, its use depends upon the context. As far as AAA > is concerned, it isn't used because AAA transfers the keying information > instead of within MIP. However, I presume that there are cases where > the FA and/or HA wish to exchange keying information. We decided that it > made sense to include this case, since it will most likely be needed > sometime in the future. > > As far as section 7, it could be useful in hierarchical scenarios. > > > > > 4. Can the 'Reply' Key extensions in Sections 3 and 5 be sent > > unsolicited to the MN...meaning, not in response to a 'Request' Key > > extension. > > if it is requested, then it is returned. However, it *could* be unsolicited. Can you add a note in the draft/rfc that reply messages could be sent unsolicited? This will probably avert confusion - either way. We need the scenario where keys can be pushed without solicitation. > > > 5. Curious...why separate Types for each message? Why not > > Type = Key Distribution message, > > Subtype = MN-HA, MN-FA, FA-HA, etc > > First byte of Subtype = serve purpose of current Subtype? > > We thought that a separate type for each peer set made sense. We don't > use that many, and even if a subtype wasn't recognized, you'd still have > an idea whether you need the key or not (and return the appropriate error). > > Example. Let's assume an FA receives a packet with one of these mumbo > extensions you mention above. If the subtype isn't recognized, it doesn't > know whether the key is destined for it or not. Perhaps the key is really > for the mobile node instead. > > Make sense? Hmm, but wouldn't the location of this extension in the registration request/reply take care of this? If the extension if located before MHAE then it is for MN and after MHAE and optionally before FHAE, the FA is supposed to interpret it. I am just trying to conserve the numbering space here - no intention to be picky. > > > 6. When MN sends 'MN-HA Key Request' extension in RRQ, does it append > > MN-AAA AE since no MHAE? So, AAA is doing proxy authentication of MN > > for the HA? Then, HA sends RPY with 'MN-HA Key Reply' > > extension...what AE is used to secure the RPY? > > They are independent. If the MN includes the MN-HA Key Request with the > AAA subtype (see AAA keys draft), then it really should include the > MN-AAA extension. However, these are separate drafts, and it makes sense > to leave it that way. I think I am not clear - if the MN is requesting the key, then it essentially does not have the key to HA. Thus, it cannot use MHAE to authenticate the message. The original question was what AE is used to authenticate the message. We know MN-AAA extension is a separate extension and are speculating if that extension is used to authenticate the MN? > > You are correct, though, that the HA would include the MN-HA Key Reply > extenion in the reply message, with the MN-HA auth ext generated using the > newly distributed key. A note in this regard would help clarify processing at the receiving entity - that the just generated key should be used to authenticate the received message. > > > > > 7. We would like a mobility agent, say MA-1, to pass key to MA-2 for > > MA-2 to use with MN. If MAs are FAs, then probably the FA-FA Key > > Reply Extension would be used...appended to what MIP message? What if > > the MAs are HAs? > > Since this behavior hasn't been defined, I cannot claim to know. This > draft only defines the generalized extensions, but separate extension > documents would describe how they are used. aaa keys is one such example. Can you add a section to distribute the keys between two HA's in an administrative domain? - something like HA-HA key distribution extension? Thanks Alpesh > > > 8. Section on user scenarios would be helpful...mention that the AAA > > Registration Keys draft is an instantiation of this draft. A simple > > user scenario would illustrate the intent of the draft. > > We had decided NOT to create a double link list. The AAA keys draft already > points to this draft, and the other way around doesn't make a whole lot > of sense. > > The AAA draft, which describes subtypes, provides the needed illustration. > I would hate to have to copy that text into this simple draft, because it is > so AAA specific. > > Thanks, > > PatC > > > > Thanks, > > Madhavi > > > > On Fri, Jul 06, 2001 at 01:55:02PM -0400, Phil Roberts wrote: > > > > > > This is a Mobile IP WG last call for the I-D > > > draft-ietf-mobileip-gen-key-00.txt > > > Generalized Key Extensions for Mobile IP. This draft will be sent to the > > > IESG > > > requesting a proposed standard status to be associated with it at the end of > > > the last call period. Please send your comments to the WG discussion list. > > > > > > WG Last call issued on : Jul 5, 2001 > > > Expires on : Jun 20, 2001 > > > > > > Basavaraj Patil > > > Phil Roberts -a From owner-mobile-ip@sunroof.eng.sun.com Sat Jul 21 11:42:00 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14555 for ; Sat, 21 Jul 2001 11:41:59 -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 IAA19751; Sat, 21 Jul 2001 08:42:38 -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 IAA00473; Sat, 21 Jul 2001 08:42:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6LFeoN10176 for mobile-ip-dist; Sat, 21 Jul 2001 08:40:50 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6LFek010169 for ; Sat, 21 Jul 2001 08:40:46 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA00402 for ; Sat, 21 Jul 2001 08:40:57 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA09033 for ; Sat, 21 Jul 2001 08:40:57 -0700 (PDT) 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 f6LFexg11421; Sat, 21 Jul 2001 08:40:59 -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 AAN03206; Sat, 21 Jul 2001 08:40:53 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA09543; Sat, 21 Jul 2001 08:40:53 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15193.41605.24313.336251@thomasm-u1.cisco.com> Date: Sat, 21 Jul 2001 08:40:53 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Cc: Alexis , Phil Roberts , "Basavaraj Patil (NTC/Dallas)" , Abha Ahuja , Thomas Narten , Dave Johnson , Jeff Schiller , Marcus Leech , Pekka Nikander Subject: Re: [Fwd: [mobile-ip] Mobile IPv6 clarifications] In-Reply-To: <3B448983.B50FE7AE@iprg.nokia.com> References: <3B3B2E46.50E17D25@era.ericsson.se> <3B3E90F1.3F4AC384@iprg.nokia.com> <3B4171B2.7098C705@era.ericsson.se> <3B42565B.394B91D5@iprg.nokia.com> <3B448146.5112F7C9@crm.mot.com> <3B448983.B50FE7AE@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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit [I know this is old, but probably worth restarting this before London] Charles E. Perkins writes: > If somebody in the Security area wants to tell a different story, > that will be just very fine with me. I'll try in a later note to > describe my perhaps-inadequate understanding of the reasons why. > I wish they would carry out the conversation on the [mobile-ip] > mailing list instead of telling me in person or making statements > in the face-to-face Mobile IP meetings. That way we could get it > in writing and bring into the conversation the Mobile IP experts > and IPsec experts from around the world. > > Furthermore, in no way does the current document split Mobile IP > away from security. The current Binding Update is quite secure, > as was the previous Binding Update which relied on AH. The difference > is that the current Binding Update can have _EXACTLY_ the semantics > that need to be specified for Mobile IPv6. Relying on AH, which in > my opinion SHOULD still be O.K. but that's just my opinion and not > going to matter when the IESG reviews the document, has the effect > of leaving the Mobile IPv6 vulnerable to outside forces who may claim > (and have claimed) that we have made inappropriate use of the protocol. As I recall, there were two objections to the way that -13 was using IPsec. 1) There is no way to express a SPD rule (or ingress/egress filter) for an IP packet which has multiple IP extensions. There is the ability to filter on the normal five tuple (or subset thereof) and that is it. -13's ability to piggyback a BU (which is an IP extension header) with a normal, say, TCP header would not be processed correctly by IPsec. If, however, a node were willing to _not_ piggyback BU as well as instantiate an SA either solely for the purpose of matching the BU header (where it was there alone), or with the properly formated wildcarded IPsec ID -- typically, all traffic from a particular IP address in transport mode only -- I believe that IPsec's current selector mechanism works fine. Indeed, I don't see any problem with using IPsec between the HA and MN, and with the proper restrictions, I think that can be extended for use between the MN and CN. See draft-thomas-mobileip-esp-bu-00.txt for a discussion of the problem, as well as a proposal to use ESP for BU's. 2) There was a great deal of concern about the authorization problem. Namely, that even if a random CN were able to determine the identity of a node requesting a BU (a dubious proposition in itself), that doesn't give it in and of itself the _authority_ to change the binding for a particular IP address. In order to prevent otherwise authenticated but potentially unauthorized entities from abuse, there must be some form of correlation that the CN can use to determine whether a particular identity is authorized. This is nothing new, really, and happens all of the time with PKI's, Kerberos, etc, backed by authorization correlation, say, in an LDAP database. However, the scale of of the *random* CN/MN interaction posits the *worldwide* availability of that authentication/authorization correlation which is secure, scalable, free from reptilian corruption, etc, etc. In other words, it's untenable, and unclear that it would be desirable even if. Now, that said, I do not think that rules out use of IPsec (with the restrictions from #1) in situations where the authentication/authorization correlation can be kept a local matter (eg, doesn't require IANA, or or the address registries to become a PKI root). It would be perfectly reasonable for an enterprise to run their own authentication/authorization service for their own employees, and they could use IPsec to protect the BU's after, say, IKE or KINK made a policy decision based on the security policy database rules it was provisioned with. Indeed, within some security domains, authentication is in many cases sufficient to grant authorization, and I think we should still preserve that flexibility so long as we do *not* try to extend it to the general case, which was what -13 was hoping to do. In conclusion, I do think it's worthwhile to preserve a strong crypto possibility using IPsec for both MN/HA interaction as well as MN/CN interaction within the scope that it was meant to operate (ie, without global implications). The weak authentication/authorization that is being proposed in BAKE and my Cookies draft should be more narrowly focused on the random MN/CN interaction where it is not pragmatic to have a strong crypto solution. Mike From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 23 04:25:08 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA07403 for ; Mon, 23 Jul 2001 04:25:08 -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 BAA04232; Mon, 23 Jul 2001 01:25:39 -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 BAA25316; Mon, 23 Jul 2001 01:25:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6N8Nlx13014 for mobile-ip-dist; Mon, 23 Jul 2001 01:23:47 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6N8NgY13007 for ; Mon, 23 Jul 2001 01:23:42 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA08882 for ; Mon, 23 Jul 2001 01:23:55 -0700 (PDT) Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA03364 for ; Mon, 23 Jul 2001 01:23:55 -0700 (PDT) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate4.mot.com (motgate4 2.1) with ESMTP id BAA12756 for ; Mon, 23 Jul 2001 01:23:54 -0700 (MST)] Received: [from m-il06-r3.mot.com (m-il06-r3.mot.com [129.188.137.194]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id BAA06024 for ; Mon, 23 Jul 2001 01:23:54 -0700 (MST)] Received: from [140.101.173.9] by m-il06-r3.mot.com with ESMTP for mobile-ip@sunroof.eng.sun.com; Mon, 23 Jul 2001 01:23:43 -0700 Received: (from root@localhost) by zorglub.crm.mot.com (8.8.8/8.8.8/crm-1.6) id KAA22389 for mobile-ip@sunroof.eng.sun.com.DELIVER; Mon, 23 Jul 2001 10:23:50 +0200 (METDST) Received: from test9.crm.mot.com.crm.mot.com (zfr24-sr2-04.corp.mot.com [140.101.145.4]) by zorglub.crm.mot.com (8.8.8/8.8.8/crm-1.6) with ESMTP id KAA22359 for ; Mon, 23 Jul 2001 10:23:48 +0200 (METDST) To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Subnet vs Link References: <200107200725.f6K7PaO83048@givry.rennes.enst-bretagne.fr> From: Alexandru Petrescu Date: 23 Jul 2001 10:07:37 +0200 In-Reply-To: <200107200725.f6K7PaO83048@givry.rennes.enst-bretagne.fr> Message-Id: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.0.103 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Lines: 13 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: Francis Dupont writes: > => this seems to be just a mistake: I believe only the word 'link' should > be used because only the word 'link' is clearly defined in IPv6 > documents. I think "subnet" is also extensively used in IPv6 rfc's. But if we get back to original message, why are you asking this Jiwoong? Do you think that further differentiation subnet-link should be made in the Threat Model draft with respect to security issues? Or can the draft live with the subnet-link ambiguity? Alex From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 23 04:44:47 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA07590 for ; Mon, 23 Jul 2001 04:44:45 -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 BAA09579; Mon, 23 Jul 2001 01:45:13 -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 BAA26999; Mon, 23 Jul 2001 01:44:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6N8heP13145 for mobile-ip-dist; Mon, 23 Jul 2001 01:43:40 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6N8haY13138 for ; Mon, 23 Jul 2001 01:43:37 -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 BAA10304 for ; Mon, 23 Jul 2001 01:43:50 -0700 (PDT) Received: from mail.n016.co.kr ([203.229.169.4]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA03736 for ; Mon, 23 Jul 2001 02:43:43 -0600 (MDT) Received: from freenet.ktf.co.kr (freenet.ktf.com [203.229.169.83]) by mail.n016.co.kr (v3smtp 8.11.4 Copyright (c) 1998-2001 Sendmail, Inc. All rights reserved.Copyright (c) 1988, 1993 The Regents of the University of California. All rights reserved./8.11.1) with ESMTP id f6N8bsA25920 for ; Mon, 23 Jul 2001 17:37:54 +0900 (KST) Received: from words ([10.6.10.175]) by freenet.ktf.co.kr (8.9.3/8.9.3) with SMTP id RAA10378 for ; Mon, 23 Jul 2001 17:39:50 +0900 (KST) Message-ID: <025e01c11353$1c26e950$af0a060a@words> From: "Jiwoong Lee" To: References: <200107200725.f6K7PaO83048@givry.rennes.enst-bretagne.fr> Subject: Re: [mobile-ip] Subnet vs Link Date: Mon, 23 Jul 2001 17:40:21 +0900 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.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: 8bit Alex, My question was quite a general one. As Francis's said, I do not have the concept of 'IPv6 subnet' in my mind. The authors of mipv6-sec-reqts-00 seem to use both terms intentionally. My curiosity comes from that. I felt inclined to ask the authors, if any, unstated reasons in doing so. BTW, I think the draft is well-written. Regards, Jiwoong ----- Original Message ----- From: "Alexandru Petrescu" To: Sent: Monday, July 23, 2001 5:07 PM Subject: Re: [mobile-ip] Subnet vs Link > Francis Dupont writes: > > => this seems to be just a mistake: I believe only the word 'link' should > > be used because only the word 'link' is clearly defined in IPv6 > > documents. > > I think "subnet" is also extensively used in IPv6 rfc's. > > But if we get back to original message, why are you asking this > Jiwoong? Do you think that further differentiation subnet-link should > be made in the Threat Model draft with respect to security issues? Or > can the draft live with the subnet-link ambiguity? > > Alex > > From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 23 05:38:23 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA08077 for ; Mon, 23 Jul 2001 05:38:22 -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 DAA01541; Mon, 23 Jul 2001 03:38:46 -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 CAA06875; Mon, 23 Jul 2001 02:38:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6N9axP13270 for mobile-ip-dist; Mon, 23 Jul 2001 02:36:59 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6N9auY13263 for ; Mon, 23 Jul 2001 02:36:56 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA14193 for ; Mon, 23 Jul 2001 02:37:09 -0700 (PDT) Received: from leonis.nus.edu.sg (leonis.nus.edu.sg [137.132.1.18]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA29340 for ; Mon, 23 Jul 2001 02:37:07 -0700 (PDT) Received: from cwc-ibxus8n62wn.cwc.nus.edu.sg ([137.132.31.150]) by leonis.nus.edu.sg (8.10.0/8.10.0) with ESMTP id f6N9agO21638; Mon, 23 Jul 2001 17:36:42 +0800 (SST) Message-Id: <5.1.0.14.2.20010723163720.00a9e788@postman.cwc.nus.edu.sg> X-Sender: shenqi@postman.cwc.nus.edu.sg X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 23 Jul 2001 17:43:20 +0800 To: mobile-ip@sunroof.eng.sun.com From: Charles Qi Shen Subject: Re: [mobile-ip] draft-shen-rsvp-mobileipv6-interop-00.txt Cc: siglite@cs.columbia.edu In-Reply-To: <748E8123D183394982E32A511DB3E7360C807C@daebe005.NOE.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: Hi all, With the "Requirements of a QoS Solution for Mobile IP" I-D released, it might be the time to consider (a) possible solution(s). In particular, we think it is highly important to evaluate the feasibility of forming a QoS-MIP framework based on existing QoS mechanisms, and to enhance them, where necessary. Therefore, we greatly appreciate any comments, suggestions, and critics regarding our draft on RSVP and Mobile IPv6 interoperation, http://www.ietf.org/internet-drafts/draft-shen-rsvp-mobileipv6-interop-00.txt We will also warmly welcome face-to-face comments in London next month. Best Regards, Charles At 02:53 PM 7/20/2001 -0500, you wrote: >Hi, > >We recently submit a new ID titled "An Interoperation Framework for >Using RSVP in Mobile IPv6 Networks". This draft proposes a Mobile IPv6 >and RSVP interoperation scheme. In this scheme, the underlying mobility >support mechanism is required to provide a unique flow identity >regardless of node mobility, making the node mobility transparent to >flow QoS handling mechanisms. Thus QoS signaling delay as well as data >packet delays and losses during handoff can be reduced. > >You can find the draft at >http://www.ietf.org/internet-drafts/draft-shen-rsvp-mobileipv6-interop-0 >0.txt. > >Comments and suggestions are very welcome. > >BR, > >Haihong > >-- >Haihong Zheng >Mobile Networks Laboratory >Nokia Research Center, Irving, Texas, USA From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 23 05:49:44 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA08214 for ; Mon, 23 Jul 2001 05:49:43 -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 DAA07310; Mon, 23 Jul 2001 03:50:26 -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 CAA07731; Mon, 23 Jul 2001 02:50:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6N9mdQ13351 for mobile-ip-dist; Mon, 23 Jul 2001 02:48:39 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6N9mZY13344 for ; Mon, 23 Jul 2001 02:48:35 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA07658 for ; Mon, 23 Jul 2001 02:48:49 -0700 (PDT) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA02511 for ; Mon, 23 Jul 2001 02:48:48 -0700 (PDT) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate.mot.com (motgate 2.1) with ESMTP id CAA21669 for ; Mon, 23 Jul 2001 02:48:47 -0700 (MST)] Received: [from m-il06-r3.mot.com (m-il06-r3.mot.com [129.188.137.194]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id CAA25142 for ; Mon, 23 Jul 2001 02:41:21 -0700 (MST)] Received: from [140.101.173.9] by m-il06-r3.mot.com with ESMTP for mobile-ip@sunroof.eng.sun.com; Mon, 23 Jul 2001 02:48:35 -0700 Received: (from root@localhost) by zorglub.crm.mot.com (8.8.8/8.8.8/crm-1.6) id LAA07510 for mobile-ip@sunroof.eng.sun.com.DELIVER; Mon, 23 Jul 2001 11:48:43 +0200 (METDST) Received: from test9.crm.mot.com.crm.mot.com (zfr24-sr2-04.corp.mot.com [140.101.145.4]) by zorglub.crm.mot.com (8.8.8/8.8.8/crm-1.6) with ESMTP id LAA07480 for ; Mon, 23 Jul 2001 11:48:42 +0200 (METDST) To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Subnet vs Link References: <200107200725.f6K7PaO83048@givry.rennes.enst-bretagne.fr> <025e01c11353$1c26e950$af0a060a@words> From: Alexandru Petrescu Date: 23 Jul 2001 11:43:30 +0200 Message-Id: Lines: 23 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.0.103 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: "Jiwoong Lee" writes: > BTW, I think the draft is well-written. Me too, I think it's well structured and organized. However, I'm wondering if putting requirements into it is really necessary. In my understanding a Threat Model should restrict as least as possible the solutions' space. Take for example requirement G.1. As I understand it (might not be the right understanding), it requires every AR willing to play HA role to have an SA with every visiting MN. This is so striking to me. A less heavy solution, but still using crypto, could be designed that would require the respective AR to have an SA with the MN's true HA only. Moreover, a functional-only solution (non crypto) would require the AR to probe the MN with an NS before adding a binding for it, such that if the MN responds with an NA then the AR knows it's not moved, and the received BU is spoofed. By eliminating this kinds of solutions, probably authors' intention was to avoid modifications to the base mipv6, and only add some security "salt". I don't know. Alex From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 23 05:54:36 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA08309 for ; Mon, 23 Jul 2001 05:54:36 -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 CAA01300; Mon, 23 Jul 2001 02:55: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 CAA08285; Mon, 23 Jul 2001 02:55:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6N9rwT13413 for mobile-ip-dist; Mon, 23 Jul 2001 02:53:58 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6N9rsY13406 for ; Mon, 23 Jul 2001 02:53:54 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA08198 for ; Mon, 23 Jul 2001 02:54:08 -0700 (PDT) Received: from sonne.darmstadt.gmd.de (sonne.darmstadt.gmd.de [141.12.62.20]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA04094 for ; Mon, 23 Jul 2001 02:54:07 -0700 (PDT) Received: from ipsi.fraunhofer.de (pc-morion [141.12.35.155]) by sonne.darmstadt.gmd.de (8.8.8/8.8.5) with ESMTP id LAA04370; Mon, 23 Jul 2001 11:54:06 +0200 (MET DST) Message-ID: <3B5BF533.124CAB98@ipsi.fraunhofer.de> Date: Mon, 23 Jul 2001 11:58:11 +0200 From: Wolfgang Schoenfeld Organization: FhG IPSI X-Mailer: Mozilla 4.7 [de] (WinNT; I) X-Accept-Language: en,de MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] WG feedback on bicasting 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 "Karim El-Malki (ERA)" wrote: > > Hello folks > > We'd like to have feedback on the following draft: > http://www.ietf.org/internet-drafts/draft-elmalki-mobileip-bicasting-v6-00.txt > This describes a technique to reduce packet loss during > the handover (i.e. smoothing) and to support l2-handover > failure or ping-pong. This is meant for addition to the > fast handover v6 draft. It was discussed in the fast handover > mipv6 design team and it was decided to ask the WG for feedback > on whether to include this in the fastv6 draft. The equivalent > draft for MIPv4 (low latency v4) already includes this technique > so we're proposing to include this optional function in v6 as well. > What do people think about this? > > Regards > /Karim Karim, I'm not able to comment on mobileip WG issues, but I believe that the role of bicasting for handover is not yet fully understood, both in MIPv4 and MIPv6. Considerations like the following for MIPv4 might help to decide. Obviously, bicasting makes sense only if MN is able to maintain more than one link simultaneously, say to oFA and nFA. Now assume that this is the case and consider handover without bicasting. Handover involves, among others, these events: (A) MN detects a link to nFA and issues a BU message to HA. (B) HA receives BU and updates binding of MN. (C) MN looses the link to oFA. How is a stream of packets from some CN to MN affected by handover? (A) does not affect the stream, but (B) does: Before (B), packets travel to oFA, and after (B), they travel to nFA (assume that HA buffers during (B)). Packets passing HA after (B) will reach MN, but what about those which pass HA before (B) and after (A)? Let us call them "critical" packets. If (C) happens only after all critical packets have passed the link from oFA to MN, then there is no packet loss at all. (However, the stream may be out of order.) On the other hand, if (C) happens before all critical packets have reached MN via oFA, oFA will discard some of them. (Note there are proposals to, instead, forward them to nFA.) Now, what could bicasting improve? Non-critical packets need not be bicasted - they will reach MN anyhow. And critical packets cannot be bicasted because HA is not yet aware of (A) ! (except HA is able to guess) To summarize, simultaneous use of two links to MN - if they exist - is somehow "built-in" and can happen even if simultaneous binding is switched off. Switching it on will have no effect on packet loss!!! Bicasting does not make sense. It does make sense only if HA is able to predict (A). But move prediction is, as far as I understand, not an issue for MIPv4 or for MIPv6. Regards, Wolfgang -- Wolfgang Schoenfeld, Fraunhofer IPSI, Dolivostr. 15, D-64293 Darmstadt Office: +49-6151-869-865 FAX: -6847 Mobile: +49-174-7093455 From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 23 08:26:26 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA14797 for ; Mon, 23 Jul 2001 08:26: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 GAA14225; Mon, 23 Jul 2001 06:26: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 FAA26392; Mon, 23 Jul 2001 05:26:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6NCNrh13817 for mobile-ip-dist; Mon, 23 Jul 2001 05:23:53 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6NCNoY13810 for ; Mon, 23 Jul 2001 05:23:50 -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 FAA12271 for ; Mon, 23 Jul 2001 05:24:03 -0700 (PDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA24881 for ; Mon, 23 Jul 2001 06:25:22 -0600 (MDT) Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f6NCNxO11943 for ; Mon, 23 Jul 2001 14:23:59 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Mon Jul 23 14:23:59 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Mon, 23 Jul 2001 14:23:55 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008B42@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] WG feedback on bicasting Date: Mon, 23 Jul 2001 14:23:52 +0200 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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hello Wolfgang, > I'm not able to comment on mobileip WG issues, > but I believe that the role of bicasting for handover > is not yet fully understood, both in MIPv4 and MIPv6. > Considerations like the following for MIPv4 > might help to decide. > > Obviously, bicasting makes sense only if MN is able > to maintain more than one link simultaneously, > say to oFA and nFA. > => In fact itis the opposite. Bicasting makes less sense if you can have such connectivity. The assumption in the draft (and the Fast Handoffs draft for that matter) is that anticipation and bicasting are needed if you do not have such simultaneous connectivity. This is the basis of the Fast Handoffs draft for v6 and the low lateny draft for v4. > Now assume that this is the case > and consider handover without bicasting. > Handover involves, among others, these events: > > (A) MN detects a link to nFA and issues a BU message to HA. > (B) HA receives BU and updates binding of MN. > (C) MN looses the link to oFA. > => You seem to be assuming a make before break handover as you stated above. This is not the scenario that fast handoffs are aimed at. Hence the rest of the analysis would not apply. Regards, Hesham From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 23 08:41:02 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA15865 for ; Mon, 23 Jul 2001 08:41: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 GAA22555; Mon, 23 Jul 2001 06:41: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 FAA13145; Mon, 23 Jul 2001 05:41:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6NCeFd13882 for mobile-ip-dist; Mon, 23 Jul 2001 05:40:15 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6NCeBY13875 for ; Mon, 23 Jul 2001 05:40:11 -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 FAA13066 for ; Mon, 23 Jul 2001 05:40:24 -0700 (PDT) From: Basavaraj.Patil@nokia.com Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA01064 for ; Mon, 23 Jul 2001 06:41:44 -0600 (MDT) Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f6NCf9I07690 for ; Mon, 23 Jul 2001 07:41:09 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Mon, 23 Jul 2001 07:40:07 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.1600); Mon, 23 Jul 2001 07:40:07 -0500 content-class: urn:content-classes:message Subject: RE: [mobile-ip] Subnet vs Link Date: Mon, 23 Jul 2001 07:40:06 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF440860A7@daebe007.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [mobile-ip] Subnet vs Link X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 Thread-Index: AcETXQNk0sejKn9PEdWrwwAIx6S5QwAF590A To: Cc: X-OriginalArrivalTime: 23 Jul 2001 12:40:07.0412 (UTC) FILETIME=[9A9BCB40:01C11374] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f6NCeBY13876 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 > >However, I'm wondering if putting requirements into it is really >necessary. We believe the requirements are a critical part of the I-D. If you only have scenarios that depict threats, and do not necessarily derive what it means in terms of requirements for Mobile IPv6, it is not very useful for developing a solution. The document now captures requirements that should be considered in the design of a solution. -Basavaraj > >Alex > > From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 23 09:14:17 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA18206 for ; Mon, 23 Jul 2001 09:14:12 -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 HAA10681; Mon, 23 Jul 2001 07:14: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 GAA16149; Mon, 23 Jul 2001 06:14:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6NDCvP13994 for mobile-ip-dist; Mon, 23 Jul 2001 06:12:57 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6NDCrY13987 for ; Mon, 23 Jul 2001 06:12:53 -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 GAA16068 for ; Mon, 23 Jul 2001 06:13:06 -0700 (PDT) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA09720 for ; Mon, 23 Jul 2001 07:13:04 -0600 (MDT) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate.mot.com (motgate 2.1) with ESMTP id GAA03683 for ; Mon, 23 Jul 2001 06:13:04 -0700 (MST)] Received: [from m-il06-r4.mot.com (m-il06-r4.mot.com [129.188.137.196]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id GAA15293 for ; Mon, 23 Jul 2001 06:05:38 -0700 (MST)] Received: from [140.101.173.9] by m-il06-r4.mot.com with ESMTP for mobile-ip@sunroof.eng.sun.com; Mon, 23 Jul 2001 06:13:03 -0700 Received: (from root@localhost) by zorglub.crm.mot.com (8.8.8/8.8.8/crm-1.6) id PAA09016 for mobile-ip@sunroof.eng.sun.com.DELIVER; Mon, 23 Jul 2001 15:13:00 +0200 (METDST) Received: from test9.crm.mot.com.crm.mot.com (zfr24-sr2-04.corp.mot.com [140.101.145.4]) by zorglub.crm.mot.com (8.8.8/8.8.8/crm-1.6) with ESMTP id PAA08969; Mon, 23 Jul 2001 15:12:58 +0200 (METDST) To: Cc: Basavaraj.Patil@nokia.com Subject: Re: [mobile-ip] Subnet vs Link References: <697DAA22C5004B4596E033803A7CEF440860A7@daebe007.NOE.Nokia.com> From: Alexandru Petrescu Date: 23 Jul 2001 15:07:45 +0200 In-Reply-To: <697DAA22C5004B4596E033803A7CEF440860A7@daebe007.NOE.Nokia.com> Message-Id: Lines: 13 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.0.103 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: Basavaraj.Patil@nokia.com writes: > We believe the requirements are a critical part of the I-D. If you > only have scenarios that depict threats, and do not necessarily > derive what it means in terms of requirements for Mobile IPv6, it is > not very useful for developing a solution. The document now captures > requirements that should be considered in the design of a solution. Aha, thanks for clarification. I'm also wondering if another goal behind those requirements was to avoid as much as possible modifications to Mobile IPv6 as is today? Alex From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 23 09:26:30 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA18998 for ; Mon, 23 Jul 2001 09:26:29 -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 GAA27258; Mon, 23 Jul 2001 06:26:36 -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 GAA17214; Mon, 23 Jul 2001 06:26:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6NDP0j14093 for mobile-ip-dist; Mon, 23 Jul 2001 06:25:00 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6NDOvY14086 for ; Mon, 23 Jul 2001 06:24:57 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA23652 for ; Mon, 23 Jul 2001 06:25:10 -0700 (PDT) From: Basavaraj.Patil@nokia.com Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA19257 for ; Mon, 23 Jul 2001 06:25:09 -0700 (PDT) Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f6NDPAi06060 for ; Mon, 23 Jul 2001 08:25:10 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Mon, 23 Jul 2001 08:25:08 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.1600); Mon, 23 Jul 2001 08:25:08 -0500 content-class: urn:content-classes:message Subject: RE: [mobile-ip] Subnet vs Link Date: Mon, 23 Jul 2001 08:25:07 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF440860A8@daebe007.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 Thread-Topic: [mobile-ip] Subnet vs Link Thread-Index: AcETeTaLNLGr8H9rEdWpVgBQi2kYTQAAbJ1A To: , X-OriginalArrivalTime: 23 Jul 2001 13:25:08.0045 (UTC) FILETIME=[E44FAFD0:01C1137A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f6NDOvY14087 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 Alexandru Petrescu wrote: >Basavaraj.Patil@nokia.com writes: >> We believe the requirements are a critical part of the I-D. If you >> only have scenarios that depict threats, and do not necessarily >> derive what it means in terms of requirements for Mobile IPv6, it is >> not very useful for developing a solution. The document now captures >> requirements that should be considered in the design of a solution. > >Aha, thanks for clarification. > >I'm also wondering if another goal behind those requirements was to >avoid as much as possible modifications to Mobile IPv6 as is today? > If securing binding updates requires some changes to Mobile IPv6 as specified today, then it is inevitable to avoid modifications. But I guess your question leans more towards, what degree of emancipation from the current spec will be acceptable? Well the smaller the better, but a good solution that causes larger changes may be acceptable if we have consensus. >Alex > -Basavaraj From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 23 09:41:14 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA20036 for ; Mon, 23 Jul 2001 09:41:13 -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 GAA02496; Mon, 23 Jul 2001 06:41: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 GAA19184; Mon, 23 Jul 2001 06:40:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6NDcsK14215 for mobile-ip-dist; Mon, 23 Jul 2001 06:38:54 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6NDcoY14205 for ; Mon, 23 Jul 2001 06:38:51 -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 GAA18819 for ; Mon, 23 Jul 2001 06:39:04 -0700 (PDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA26666 for ; Mon, 23 Jul 2001 07:40:26 -0600 (MDT) Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f6NDd1O24636 for ; Mon, 23 Jul 2001 15:39:01 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Mon Jul 23 15:39:00 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Mon, 23 Jul 2001 15:38:57 +0200 Message-ID: <795A014AF92DD21182AF0008C7A404320C52047F@esealnt117> From: "Karim El-Malki (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] WG feedback on bicasting Date: Mon, 23 Jul 2001 15:38:46 +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: Hello Wolfgang > I'm not able to comment on mobileip WG issues, > but I believe that the role of bicasting for handover > is not yet fully understood, both in MIPv4 and MIPv6. > Considerations like the following for MIPv4 > might help to decide. The aim of the draft is exactly to address the role of bicasting in fast handovers (for MIPv6) and address issues involved. > > Obviously, bicasting makes sense only if MN is able > to maintain more than one link simultaneously, > say to oFA and nFA. That's not what the draft says and actually quite the opposite. > Now assume that this is the case > and consider handover without bicasting. > Handover involves, among others, these events: > > (A) MN detects a link to nFA and issues a BU message to HA. > (B) HA receives BU and updates binding of MN. > (C) MN looses the link to oFA. > > How is a stream of packets from some CN to MN affected by handover? > (A) does not affect the stream, but (B) does: > Before (B), packets travel to oFA, > and after (B), they travel to nFA > (assume that HA buffers during (B)). > Packets passing HA after (B) will reach MN, > but what about those > which pass HA before (B) and after (A)? > Let us call them "critical" packets. The bicasting draft applies to fast handover v6 but your example is different. You're also considering MIPv4 but this draft is on MIPv6... So I guess your comments are not on the draft itself but on generic bicasting? If you follow the fast handover v6 concepts then A & B would occur some time in advance of when C occurs. We assume this anticipation is enough such that the "critical" packets reach the MN at its old link. That's also a good reason to use a close-by or local HA like the MAP from HMIPv6. In fast handover v6 the anticipated F-BU is sent to the oAR. So this should not involve loss of "critical" packets. > If (C) happens only after all critical packets > have passed the link from oFA to MN, > then there is no packet loss at all. That's why the handoff is anticipated. > Now, what could bicasting improve? > Non-critical packets need not be bicasted - > they will reach MN anyhow. That's not necessarily true. The l2 handoff may occur at any time relative to the MN's BU. What if the MN hands-off (L2) to the new AR a certain time after having sent the Fast-BU? Since the MN has not moved yet the packets sent to nAR during this time interval get lost. Bicasting instead gives us a way to decouple l2 and l3 handoffs: the MN can communicate no matter when the L2 handoff occurs. This is discussed in the draft. > To summarize, > simultaneous use of two links to MN - if they exist - > is somehow "built-in" and can happen > even if simultaneous binding is switched off. In fact bicasting is probably more useful on MNs with a single link. > Switching it on will have no effect on packet loss!!! > Bicasting does not make sense. > > It does make sense only if HA is able to predict (A). > But move prediction is, as far as I understand, > not an issue for MIPv4 or for MIPv6. Is it more clear now? You were assuming things that are neither according to fast handover v6 draft nor the bicasting draft which is why you were coming to these conclusions. Regards /Karim From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 23 10:38:28 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA24914 for ; Mon, 23 Jul 2001 10:38:27 -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 HAA25150; Mon, 23 Jul 2001 07:38:43 -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 HAA02237; Mon, 23 Jul 2001 07:38:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6NEaa714485 for mobile-ip-dist; Mon, 23 Jul 2001 07:36:36 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6NEaWY14478 for ; Mon, 23 Jul 2001 07:36:32 -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 HAA00045 for ; Mon, 23 Jul 2001 07:36:44 -0700 (PDT) Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA24211 for ; Mon, 23 Jul 2001 08:38:07 -0600 (MDT) Received: from inrialpes.fr (glandon.inrialpes.fr [194.199.24.105]) by ebene.inrialpes.fr (8.11.3/8.11.3) with ESMTP id f6NEY2B06296 for ; Mon, 23 Jul 2001 16:34:02 +0200 (MEST) Message-ID: <3B5C366C.1D7BFD6E@inrialpes.fr> Date: Mon, 23 Jul 2001 16:36:28 +0200 From: Claude Castelluccia X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Question on draft-team-mobileip-mipv6-sec-reqts-00.txt References: Content-Type: multipart/alternative; boundary="------------BDA6F108267B0B5C1ACB8E46" 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: --------------BDA6F108267B0B5C1ACB8E46 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, This is a very interesting draft ... too bad that the privacy issues are not addressed... Anyway i think that requirement H.3 should be: "CNs MUST NOT process any packet (BU or not) containing a Home Address option unless they have verified that that the node sending the packets is authorized to use the home address in the destination option: In fact the MIPv6 draft says : "A node receiving a packet that includes a Home Address option MAY implement the processing of this option by physically exchanging the Home Address option field with the source IPv6 address in the IPv6 header." An attacker can then easily use a CN as a packet reflector with current MIPv6... it only needs to send packets with a home address option containing the victim address to several CNs... CNs will exchanged the source IPv6 address with the vicitim address and reply to the victim ...NO Binding entrie is necessary for this attack... Am i missing something? thanks, Claude. -- ---------------------------------------- Claude CASTELLUCCIA, INRIA Rhone-Alpes ph: +33 4.76.61.52.15 (fax: 52.52) http://www.inrialpes.fr/planete/ --------------BDA6F108267B0B5C1ACB8E46 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  

Hello,

This is a very interesting draft ... too bad that the privacy issues are not addressed...
Anyway i think that requirement H.3 should be:

 "CNs MUST NOT process any packet (BU or not) containing a Home
   Address option unless they have verified that that the node sending the packets
   is authorized to use the home address in the destination option:
 

  In fact the MIPv6 draft says :
  "A node receiving a packet
   that includes a Home Address option MAY implement the processing of
   this option by physically exchanging the Home Address option field
   with the source IPv6 address in the IPv6 header."

    An attacker can then easily use a CN as a packet reflector with current MIPv6...
    it only needs to send packets with a home address option containing the victim address to several CNs...
    CNs will exchanged the source IPv6 address with the vicitim address and reply to the victim ...NO Binding entrie
   is necessary for this attack...

   Am i missing something?
 
    thanks,

    Claude.
  

-- 

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes  
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/
  --------------BDA6F108267B0B5C1ACB8E46-- From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 23 11:19:30 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA28159 for ; Mon, 23 Jul 2001 11:19: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 JAA09268; Mon, 23 Jul 2001 09:19: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 IAA19848; Mon, 23 Jul 2001 08:19:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6NFI5m14729 for mobile-ip-dist; Mon, 23 Jul 2001 08:18:05 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6NFI1Y14722 for ; Mon, 23 Jul 2001 08:18:02 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA05857 for ; Mon, 23 Jul 2001 08:18:14 -0700 (PDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA13837 for ; Mon, 23 Jul 2001 08:18:11 -0700 (PDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f6NFI9N20294 for ; Mon, 23 Jul 2001 17:18:09 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Mon Jul 23 17:18:05 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Mon, 23 Jul 2001 17:18:05 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008B45@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] HMIPv6 rev 04 Date: Mon, 23 Jul 2001 17:18:05 +0200 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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Folks, A new version of HMIPv6 was submitted on Friday and should be announced soon. Till then you can find it at: http://standards.ericsson.net/Hesham/draft-ietf-mobileip-hmipv6-04.txt Changes from the last revision: - Several editorials and clarifications all over the document - Added a new terminology section - More clarifications for Extended mode. - New Appendix A on HMIPv6 and Fast Handoffs co-existence - New Appendix B showing an example of HMIPv6 use for mobile networks Comments are welcome. Cheers, Hesham From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 23 11:34:57 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA29351 for ; Mon, 23 Jul 2001 11:34:55 -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 JAA22596; Mon, 23 Jul 2001 09:35: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 IAA23469; Mon, 23 Jul 2001 08:34:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6NFXZ414906 for mobile-ip-dist; Mon, 23 Jul 2001 08:33:35 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6NFXVY14899 for ; Mon, 23 Jul 2001 08:33:31 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA19103 for ; Mon, 23 Jul 2001 08:33:43 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA22286 for ; Mon, 23 Jul 2001 08:33:41 -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 LAA29137; Mon, 23 Jul 2001 11:32:41 -0400 (EDT) Message-Id: <200107231532.LAA29137@ietf.org> To: IETF-Announce: ; Cc: mobile-ip@sunroof.eng.sun.com From: The IESG Subject: [mobile-ip] Last Call: Generalized NAI (GNAIE) Extension to Proposed Standard Date: Mon, 23 Jul 2001 11:32:40 -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: The IESG has received a request from the IP Routing for Wireless/Mobile Hosts Working Group to consider Generalized NAI (GNAIE) Extension as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by August 17, 2001. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mobileip-gnaie-04.txt From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 23 12:31:17 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04321 for ; Mon, 23 Jul 2001 12:31:16 -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 KAA12527; Mon, 23 Jul 2001 10:31: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 JAA06740; Mon, 23 Jul 2001 09:31:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6NGTpY15126 for mobile-ip-dist; Mon, 23 Jul 2001 09:29:51 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6NGTmY15119 for ; Mon, 23 Jul 2001 09:29:48 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA19539 for ; Mon, 23 Jul 2001 09:30:00 -0700 (PDT) Received: from sonne.darmstadt.gmd.de (sonne.darmstadt.gmd.de [141.12.62.20]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA21974 for ; Mon, 23 Jul 2001 09:29:59 -0700 (PDT) Received: from ipsi.fraunhofer.de (pc-morion [141.12.35.155]) by sonne.darmstadt.gmd.de (8.8.8/8.8.5) with ESMTP id SAA11272; Mon, 23 Jul 2001 18:29:58 +0200 (MET DST) Message-ID: <3B5C51FB.76CA2B98@ipsi.fraunhofer.de> Date: Mon, 23 Jul 2001 18:34:03 +0200 From: Wolfgang Schoenfeld Organization: FhG IPSI X-Mailer: Mozilla 4.7 [de] (WinNT; I) X-Accept-Language: en,de MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] WG feedback on bicasting References: <034BEFD03799D411A59F00508BDF754603008B42@esealnt448.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 Dear Hesham, thanks for your remarks which in deed show some gaps in my argumentation. "Hesham Soliman (ERA)" schrieb: > > Hello Wolfgang, > > > I'm not able to comment on mobileip WG issues, > > but I believe that the role of bicasting for handover > > is not yet fully understood, both in MIPv4 and MIPv6. > > Considerations like the following for MIPv4 > > might help to decide. > > > > Obviously, bicasting makes sense only if MN is able > > to maintain more than one link simultaneously, > > say to oFA and nFA. > > > => In fact itis the opposite. Bicasting makes less sense > if you can have such connectivity. The assumption in the > draft (and the Fast Handoffs draft for that matter) is > that anticipation and bicasting are needed if you > do not have such simultaneous connectivity. > This is the basis of the Fast Handoffs draft for v6 > and the low lateny draft for v4. Leave out the assumption on simultaneous links - it is not necessary. > > > Now assume that this is the case > > and consider handover without bicasting. > > Handover involves, among others, these events: > > > > (A) MN detects a link to nFA and issues a BU message to HA. > > (B) HA receives BU and updates binding of MN. > > (C) MN looses the link to oFA. > > > => You seem to be assuming a make before break handover > as you stated above. This is not the scenario > that fast handoffs are aimed at. Hence the rest of the analysis > would not apply. Please note that I did not require that (C) follow (A) or (B) - it is independent. Hence no assumption on "make before break" etc. > > Regards, > Hesham Regards, Wolfgang PS: Will answer Karim's remarks separately. -- Wolfgang Schoenfeld, Fraunhofer IPSI, Dolivostr. 15, D-64293 Darmstadt Office: +49-6151-869-865 FAX: -6847 Mobile: +49-174-7093455 From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 23 12:31:36 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04339 for ; Mon, 23 Jul 2001 12:31: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 KAA12912; Mon, 23 Jul 2001 10:32: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 JAA06848; Mon, 23 Jul 2001 09:31:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6NGUOG15135 for mobile-ip-dist; Mon, 23 Jul 2001 09:30:24 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6NGUKY15128 for ; Mon, 23 Jul 2001 09:30:20 -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 JAA29930 for ; Mon, 23 Jul 2001 09:30:33 -0700 (PDT) From: Basavaraj.Patil@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 KAA00967 for ; Mon, 23 Jul 2001 10:31:55 -0600 (MDT) Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f6NGULi08622 for ; Mon, 23 Jul 2001 11:30:34 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Mon, 23 Jul 2001 11:30:05 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.1600); Mon, 23 Jul 2001 11:30:04 -0500 content-class: urn:content-classes:message Subject: RE: [mobile-ip] Question on draft-team-mobileip-mipv6-sec-reqts-00.txt Date: Mon, 23 Jul 2001 11:30:04 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF440860AD@daebe007.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [mobile-ip] Question on draft-team-mobileip-mipv6-sec-reqts-00.txt X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 Thread-Index: AcEThXAOorr/Yn93EdWBSQBQi2X+DwAD03pQ To: Cc: X-OriginalArrivalTime: 23 Jul 2001 16:30:04.0957 (UTC) FILETIME=[BA9614D0:01C11394] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f6NGULY15129 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, > >This is a very interesting draft ... too bad that the privacy issues >are not addressed... Privacy should be dealt with separately. In order to get MIPv6 spec to PS, we need to solve the more immediate problem. >Anyway i think that requirement H.3 should be: > > "CNs MUST NOT process any packet (BU or not) containing a Home > Address option unless they have verified that that the node sending > the packets is authorized to use the home address in the > destination option: > The above makes more sense. As you mention, a CN can be made a packet reflector without creating a binding cache. Thanks for the input. > > In fact the MIPv6 draft says : > "A node receiving a packet > that includes a Home Address option MAY implement the processing of > this option by physically exchanging the Home Address option field > with the source IPv6 address in the IPv6 header." > > An attacker can then easily use a CN as a packet reflector with > current MIPv6... > it only needs to send packets with a home address option > containing the victim address to several CNs... > CNs will exchanged the source IPv6 address with the vicitim > address and reply to the victim ...NO Binding entrie > is necessary for this attack... > > Am i missing something? Nope. You are correct. > > thanks, > > Claude. > -Basavaraj > >-- > >---------------------------------------- >Claude CASTELLUCCIA, INRIA Rhone-Alpes >ph: +33 4.76.61.52.15 (fax: 52.52) >http://www.inrialpes.fr/planete/ > > From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 23 13:04:45 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA06332 for ; Mon, 23 Jul 2001 13:04:44 -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 KAA07852; Mon, 23 Jul 2001 10:05: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 KAA07557; Mon, 23 Jul 2001 10:04:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6NH39e15398 for mobile-ip-dist; Mon, 23 Jul 2001 10:03:09 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6NH35Y15391 for ; Mon, 23 Jul 2001 10:03:05 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id KAA22551 for ; Mon, 23 Jul 2001 10:03:18 -0700 (PDT) Message-Id: <200107231703.KAA22551@heliopolis.eng.sun.com> Date: Mon, 23 Jul 2001 10:03:18 -0700 (PDT) From: James Kempf Subject: [mobile-ip] Handover Smoothing - What to Do? To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: YhRdkG1C6lDZnqESijNP3w== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 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: I'd like to kick off a thread about how the MIP WG should specify/document handover smoothing. There has been specific comment around Hesham and Karim's draft draft-elmalki-mobileip-bicasting-v6-00.txt, but the issue is somewhat broader, since currently the IDs dealing with handover issues have a considerably different approach to how handover smoothing is documented. Here are the current approaches; - Include handover smoothing as part of the specification of handover. This approach is used by draft-ietf-mobileip-lowlatency-handoffs-ipv4-00.txt and draft-ietf-kempf-beth-ipv6-00.txt, the former in the body of the spec, the latter primarily in an appendix. - Completely exclude any discussion of handover smoothing as part of the specification, even in an appendix. This approach is used by draft-ietf-mobileip-fast-mipv6-01.txt. - Document handover smoothing itself in a separate ID. This approach is used by draft-elmalki-mobileip-bicasting-v6-00.txt and draft-krishnamurthi-mobileip-buffer6-01.txt. While consistency is not required, it is usually more helpful to readers to have a consistent set of specifications. In addition, there are some common threads between IPv4 and IPv6 (the analysis in the appendix of draft-ietf-kempf-beth-ipv6-00.txt for example is independent of IP version) and it might be possible to find more if we developed a consistent approach to documenting handover smoothing technologies. Here's my take on the possibilities for a more consistent approach: 1) Include IP version specific aspects of handover smoothing along with the fast/low latency handover specifications. This would result in folding draft-krishnamurthi... and draft-elmalki... into the FMIPv6 draft. We would also need to add something about buffering to the low latency MIPv4 draft, since it currently just discusses bicasting. IP version independent discussions of handover smoothing could be included in a separate draft, like for example, draft-kempf..., sort of like a BCP (but, as yet, there is no current practice in this area, so maybe RFP, "recommended future practice" :-). 2) Have separate drafts describing handover smoothing for the two IP versions, but merge the two techniques into one draft. Again, non-version specific discussion would be in a separate draft as well. 3) Have separate drafts describing the two smoothing techniques for each IP version, and the non-version specific discussion in a separate draft. 4) Merge all the handover smoothing drafts into one, including material from the version specific and non-version specific drafts, but keep it separate from the actual handover specification. The document count for each of these options is: 1) 3, one FMIPv6, one low latency MIPv4, one version independent smoothing draft. 2) 5, one FMIPv6, one smoothing v6, one low latency MIPv4, one smoothing v4, one version independent smoothing. 3) 7, one FMIPv6, one bicasting v6, one buffering v6, one low latency MIPv4, one bicasting v4, one buffering v4 (?), and one version independent smoothing. 4) 3, one FMIPv6, one low latency MIPv4, one smoothing draft with version dependent and version independent. Have I missed anything? Comments? Does anybody think we might find it easier to come to a decision if we could agree to use handoff v.s. handover and fast v.s. low latency? :-) jak From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 23 14:10:35 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12182 for ; Mon, 23 Jul 2001 14:10:33 -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 LAA11215; Mon, 23 Jul 2001 11:11:04 -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 LAA14154; Mon, 23 Jul 2001 11:10:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6NI9DT15828 for mobile-ip-dist; Mon, 23 Jul 2001 11:09:13 -0700 (PDT) Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6NI9BY15821 for ; Mon, 23 Jul 2001 11:09: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 OAA21311 for ; Mon, 23 Jul 2001 14:09:20 -0400 (EDT) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id OAA14574 for mobile-ip@sunroof.eng.sun.com; Mon, 23 Jul 2001 14:09:46 -0400 (EDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6L64Q009452 for ; Fri, 20 Jul 2001 23:04:27 -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 XAA05927 for ; Fri, 20 Jul 2001 23:04:41 -0700 (PDT) Received: from smtp-hub2.mrf.mail.rcn.net (smtp-hub2.mrf.mail.rcn.net [207.172.4.76]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA22443 for ; Sat, 21 Jul 2001 00:04:39 -0600 (MDT) Received: from smtp03.mrf.mail.rcn.net ([207.172.4.62]) by smtp-hub2.mrf.mail.rcn.net with esmtp (Exim 3.31 #3) id 15NpsW-00000P-00 for MOBILE-IP@sunroof.eng.sun.com; Sat, 21 Jul 2001 02:04:40 -0400 Received: from 66-44-55-216.s470.tnt1.lnhva.md.dialup.rcn.com ([66.44.55.216] helo=EAGLE) by smtp03.mrf.mail.rcn.net with esmtp (Exim 3.31 #3) id 15NpsU-0003pI-00 for MOBILE-IP@SUNROOF.ENG.SUN.COM; Sat, 21 Jul 2001 02:04:38 -0400 Message-ID: <17388200176216454140@EAGLE> X-EM-Version: 5, 0, 0, 19 X-EM-Registration: #01B0530810E603002D00 X-Priority: 3 X-MSMail-Priority: Normal From: "David C. Dickson" To: MOBILE-IP@sunroof.eng.sun.com Subject: [mobile-ip] 21st Century Commerce Int'l EXPO 2001 - Training Conference - Phoenix, AZ Date: Sat, 21 Jul 2001 02:04:54 -0400 MIME-Version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f6L64R009453 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: To: MOBILE-IP@sunroof.eng.sun.com Content-Transfer-Encoding: 8bit TRAINING CONFERENCE: 21st Century Commerce International EXPO 2001 E-Business://Building Integrated Solutions September 10-13, 2001 Phoenix Civic Plaza Phoenix, Arizona Main Program: Registration: 7:30 a.m., September 11 Program Begins: 8:30 a.m., September 11 Wrap-up: 3:30 p.m., September 13 Continental Breakfast, Refreshments and Lunches included. About the Conference: The 21st Century Commerce International EXPO 2001 will be held in Phoenix, Arizona, September 10-13, 2001. The conference was created in 1987 as a conference and trade exhibition focused on IT solutions for the government marketplace and the Department of Defense. The EXPO has expanded to encompass commercial marketplace best business practices. EXPO offers you an opportunity to hear from some of the nations top business leaders who will discuss and examine all aspects of e-business, from infrastructure to enterprise architecture, to hardware and software, to security issues. On the trade show floor, you will see successful e-business in action: from government agencies to Fortune 500 companies to small- and medium-size enterprises making a difference for tomorrow's wired world. Who should attend: * Senior Managers (government and Industry) * Chief Information Officers * Knowledge Officers * International Business Leaders * eBusiness Architects * Information Technology Officers * Program Managers * Product Data Managers * Customer Relations Managers * Technology Providers * Small-Medium-Large Enterprises * Data Conversion Managers and Providers * Application Service Providers Among those areas that will be discussed in the tracks are: * Defining Requirements for Integrated Solutions * Strategy Focused Execution * Exploiting Value Chain Management * Electronic Enterprises-Broadening Your Space * Integrated Technologies * Electronic Government Enterprise-Governing Beyond Borders Key Presentations: * Mr. Robert D. Johnson, Executive Vice President and COO, Honeywell International and President and CEO, Honeywell Aerospace * Ms. Mary J. Mitchell, Program Executive for Electronic Government Policy, General Services Administration * Mr. Jack Garrison, Director of Integrated Logistics, Lockheed Martin * LTG Daniel G. Brown, Deputy Commander in Chief, US Transportation Command * LTG Charles S. Mahan, Jr., Deputy Chief of Staff for Logistics, US Army * RADM Ray Archer, Defense Logistics Agency * Ms. Ariane Whittemore, Assistant Deputy Chief of Naval Operations, (Fleet Readiness and Logistics) * Dr. Palmer Smith, Director of Government Solutions, Sabre, Inc. * Mr. John F. Phillips, Vice President of Aftermarket Growth, Honeywell * Mr. Barry Lerner, Vice President of Government Sales, Exostar, LLC * Mr. Walt Kozak, PricewaterhouseCoopers * Mr. Pat Holcomb, CommerceOne * Mr. Craig York, Honeywell International Three ways to register: * On-line at www.21cc.org * By fax at 703-522-3192 * By mail: AFEI, 2111 Wilson Boulevard, Suite 400, Arlington, VA 22201 Register prior to August 31 for Early Bird rates! AFEI Members: $750 Government Employees: $825 Non-Member: $900 Tutorials: $100 (September 10) GSA (MOBIS/LOGWORLD Training): $75 (September 10) Tutorials Sessions Include: * Introduction to Supply Chain Management including practical steps in planning for implementation * How to conduct auctions on the Internet. Reverse auctions - how they work - how DoD is using reverse auctions to save money * Strategy Focused Execution including an introduction to Enterprise Resource Planning (ERP) and Customer Relationship Management (CRM) * XML with examples of the practical application of XML within Industry and Government * Introduction to Enterprise Application Integration (EAI) * Configuration Management (The transition to an Industry-wide standard) We are pleased to announce that GSA will be holding a LOGWORLD/ MOBIS training session during the EXPO this year. This year the General Services Administration's (GSA) procurement innovations will be presented at the 21st Century Commerce International EXPO 2001 on September 10. GSA will provide training at EXPO 2001 for contractors and Federal agencies interested in the Logistics Worldwide (LOGWORLD) and Management, Organizational and Business Improvement Services (MOBIS) schedule contracts. LOGWORLD enables Federal agencies to procure comprehensive logistics solutions to enhance or replace existing operations and capabilities. Examples of the type of services provided under this schedule include Supply and Value Chain Management; Acquisition Logistics; Distribution and Transportation Logistics; Deployment Logistics; Logistics training services, support products and new services. MOBIS provides Federal agencies with a tool to seek expert advice for improving management and organizational effectiveness. Examples of the type of services provided under the MOBIS schedule are consulting services; facilitation services; survey services; Alternative Dispute Resolution (ADR) services; A76 study support; project management services; training services and support products. www.northwest.gsa.gov/fss/msc Executive Roundtable: This years Executive Roundtable (ERT) theme is Returns on Business Investments in the New Reality. The ERT is a special session for senior management (CEO, COO, CIO, CTO, Sr. Vice Presidents, Presidents, Executive Directors) and is offered by invitation only. If you would like to request an invitation, please contact Michelle Bourke at mbourke@afei.org. Exhibit: Booth space will be reserved on a first-come, first-served basis. Reserve your preferred location as soon as possible. The floorplan has been configured to maximize traffic throughout the display area, and the program schedule will be designed to encourage attendee participation. For more information on available booth space and prices, go to http://www.21cc.org/01exhibits.htm. We have already sold 50% of our booth spaces! Sign up soon! Conference Sponsors: * EXOSTAR * Sprint E Solutions * CSC * Phoenix Business Journal * Government Computer News * National Defense Industrial Association * National Defense Magazine * Thomas Group * BidSource * The Greater Phoenix Chamber of Commerce To view sponsorship opportunities, please visit the website at www.21cc.org Contact: Michelle Beckner Bourke, EXPO Conference Manager, at (703) 247-9473, mbourke@afei.org; If you wish to be REMOVED from this list, please REPLY by placing REMOVE in the subject line. Thank you From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 23 14:14:47 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12637 for ; Mon, 23 Jul 2001 14:14:46 -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 LAA13484; Mon, 23 Jul 2001 11:15: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 LAA15327; Mon, 23 Jul 2001 11:14:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6NIDoi15921 for mobile-ip-dist; Mon, 23 Jul 2001 11:13:50 -0700 (PDT) Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6NIDlY15910 for ; Mon, 23 Jul 2001 11:13:48 -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 OAA13780 for ; Mon, 23 Jul 2001 14:14:01 -0400 (EDT) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id OAA14693 for mobile-ip@sunroof.eng.sun.com; Mon, 23 Jul 2001 14:14:26 -0400 (EDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6LCf7009928 for ; Sat, 21 Jul 2001 05:41:07 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA11642 for ; Sat, 21 Jul 2001 05:41:19 -0700 (PDT) Received: from sonne.darmstadt.gmd.de (sonne.darmstadt.gmd.de [141.12.62.20]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA17360 for ; Sat, 21 Jul 2001 05:41:18 -0700 (PDT) Received: from ipsi.fhg.de (schfeld@schoenfeld-isdn [141.12.156.205]) by sonne.darmstadt.gmd.de (8.8.8/8.8.5) with ESMTP id OAA28269; Sat, 21 Jul 2001 14:41:16 +0200 (MET DST) Message-ID: <3B597401.8C9E792@ipsi.fhg.de> Date: Sat, 21 Jul 2001 14:22:25 +0200 From: Wolfgang =?iso-8859-1?Q?Sch=F6nfeld?= Organization: FhG IPSI X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13 i586) X-Accept-Language: de, en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] WG feedback on bicasting References: <795A014AF92DD21182AF0008C7A404320C520477@esealnt117> 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 "Karim El-Malki (ERA)" wrote: > > Hello folks > > We'd like to have feedback on the following draft: > http://www.ietf.org/internet-drafts/draft-elmalki-mobileip-bicasting-v6-00.txt > This describes a technique to reduce packet loss during > the handover (i.e. smoothing) and to support l2-handover > failure or ping-pong. This is meant for addition to the > fast handover v6 draft. It was discussed in the fast handover > mipv6 design team and it was decided to ask the WG for feedback > on whether to include this in the fastv6 draft. The equivalent > draft for MIPv4 (low latency v4) already includes this technique > so we're proposing to include this optional function in v6 as well. > What do people think about this? > > Regards > /Karim Karim, I'm not able to comment on mobileip WG issues, but I believe that the role of bicasting for handover is not yet fully understood, both in MIPv4 and MIPv6. Considerations like the following for MIPv4 might help to decide. Obviously, bicasting makes sense only if MN is able to maintain more than one link simultaneously, say to oFA and nFA. Now assume that this is the case and consider handover without bicasting. Handover involves, among others, these events: (A) MN detects a link to nFA and issues a BU message to HA. (B) HA receives BU and updates binding of MN. (C) MN looses the link to oFA. How is a stream of packets from some CN to MN affected by handover? (A) does not affect the stream, but (B) does: Before (B), packets travel to oFA, and after (B), they travel to nFA (assume that HA buffers during (B)). Packets passing HA after (B) will reach MN, but what about those which pass HA before (B) and after (A)? Let us call them "critical" packets. If (C) happens only after all critical packets have passed the link from oFA to MN, then there is no packet loss at all. (However, the stream may be out of order.) On the other hand, if (C) happens before all critical packets have reached MN via oFA, oFA will discard some of them. (Note there are proposals to, instead, forward them to nFA.) Now, what could bicasting improve? Non-critical packets need not be bicasted - they will reach MN anyhow. And critical packets cannot be bicasted because HA is not yet aware of (A) ! (except HA is able to guess) To summarize, simultaneous use of two links to MN - if they exist - is somehow "built-in" and can happen even if simultaneous bindings are switched off. Hence I believe that bicasting makes sense only if HA is able to predict (A). But mobility prediction is, as far as I understand, not an issue for MIPv4 or for MIPv6. Regards, Wolfgang -- Wolfgang Schoenfeld, FhG IPSI, +49 6151 869 865, +49 174 7093455 From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 23 14:49:38 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15467 for ; Mon, 23 Jul 2001 14:49:37 -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 LAA29690; Mon, 23 Jul 2001 11:50:03 -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 LAA23848; Mon, 23 Jul 2001 11:49:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6NImOe16181 for mobile-ip-dist; Mon, 23 Jul 2001 11:48:24 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6NImKY16172 for ; Mon, 23 Jul 2001 11:48: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 LAA10849 for ; Mon, 23 Jul 2001 11:48:32 -0700 (PDT) From: Basavaraj.Patil@nokia.com Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA10124 for ; Mon, 23 Jul 2001 12:48:30 -0600 (MDT) Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f6NImYi05359 for ; Mon, 23 Jul 2001 13:48:34 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Mon, 23 Jul 2001 13:48:31 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.1600); Mon, 23 Jul 2001 13:48:31 -0500 content-class: urn:content-classes:message Subject: RE: [mobile-ip] Handover Smoothing - What to Do? Date: Mon, 23 Jul 2001 13:48:31 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF440860B1@daebe007.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [mobile-ip] Handover Smoothing - What to Do? X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 Thread-Index: AcETmbzbGIHu7X+DEdWrwwAIx6S5QwADjIKw To: Cc: X-OriginalArrivalTime: 23 Jul 2001 18:48:31.0773 (UTC) FILETIME=[11D59CD0:01C113A8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f6NImLY16173 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 James, Smooth handoffs is important for certain types of applications only, but the goal of the current handoff work in the Mobile IP WG is primarily on fast handoff (I hope we do not get into arguments on terminology here). I believe it is better to deal with smoothing of handoffs as a separate work item/milestone. We also need to let the bicasting and buffering drafts get some more discussion and input, as individual I-Ds before trying to combine them. The current WG handoff specs (lowlatency & fast) should not focus on this aspect of handoffs. And I do not believe the logistics of the number of specs that would be created has much bearing within the context of the handover work. The same people who are interested in this work would still be interested whether there are 5 or 7 drafts. -Basavaraj From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 23 16:19:08 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA21111 for ; Mon, 23 Jul 2001 16:19:07 -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 NAA09241; Mon, 23 Jul 2001 13:19: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 NAA00015; Mon, 23 Jul 2001 13:19:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6NKHVK16395 for mobile-ip-dist; Mon, 23 Jul 2001 13:17:31 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6NKHRY16388 for ; Mon, 23 Jul 2001 13:17:27 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA11867 for ; Mon, 23 Jul 2001 13:17:40 -0700 (PDT) Received: from palrel2.hp.com (palrel2.hp.com [156.153.255.234]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA08750 for ; Mon, 23 Jul 2001 13:17:40 -0700 (PDT) Received: from strtio1.cup.hp.com (strtio1.cup.hp.com [15.13.129.245]) by palrel2.hp.com (Postfix) with ESMTP id E5B0F117D; Mon, 23 Jul 2001 13:17:39 -0700 (PDT) Received: (from jlau@localhost) by strtio1.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) id NAA16669; Mon, 23 Jul 2001 13:19:27 -0700 (PDT) Date: Mon, 23 Jul 2001 13:19:27 -0700 (PDT) From: Joe Lau Message-Id: <200107232019.NAA16669@strtio1.cup.hp.com> To: pcalhoun@diameter.org Subject: [mobile-ip] Re: [AAA-WG]: Re: Proposed Text for Issue 91 (KDC) Cc: aaa-wg@merit.edu, mobile-ip@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset=X-roman8 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 Pat, With MIP-MN-to-HA-Key defined as a grouped AVP instead of the previous Generalized Key Reply Extension with Unsolicited MN-FA Key Material subtype, MIP-MN-to-FA-Key ::== { MIP-Algorithm-Type } { MIP-Session-Key } * [ AVP] how can the HA figure out the "AAA SPI" field in order to create the Generalized Key Reply Extension with Unsolicited MN-FA Key Material subtype in the Registration Reply to the MN. Also, am I right that AAA SPI refers to algorithm like CHAP-SPI? What are the other possible algorithms? Thank you for the clarification and info. Joe From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 23 16:56:52 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA23103 for ; Mon, 23 Jul 2001 16:56:52 -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 OAA17751; Mon, 23 Jul 2001 14:57: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 NAA26768; Mon, 23 Jul 2001 13:57:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6NKtgD16610 for mobile-ip-dist; Mon, 23 Jul 2001 13:55:42 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6NKtdY16603 for ; Mon, 23 Jul 2001 13:55:39 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA25725 for ; Mon, 23 Jul 2001 13:55:52 -0700 (PDT) Received: from idcpa4.pa.interdigital.com ([12.32.197.142]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA24362 for ; Mon, 23 Jul 2001 13:55:48 -0700 (PDT) Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19) id ; Mon, 23 Jul 2001 16:54:49 -0400 Message-ID: From: "Shahrier, Sharif M." To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] NAT-boxes with MIPv6 Date: Mon, 23 Jul 2001 16:54: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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: There had been 4 I-D submissions on the usage of NAT-boxes with MIP. I was informed by the chairman that there was to be an ad-hoc meeting to discuss how to proceed with this topic, and to determine whether this topic is within the charter of the working group. I was wondering if anyone can tell me where this meeting is to be held, and the time and the date. Thanks. -Sharif From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 23 17:36:32 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25742 for ; Mon, 23 Jul 2001 17:36:31 -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 OAA12861; Mon, 23 Jul 2001 14:37: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 OAA05883; Mon, 23 Jul 2001 14:36:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6NLZM616838 for mobile-ip-dist; Mon, 23 Jul 2001 14:35:22 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6NLZIY16831 for ; Mon, 23 Jul 2001 14:35:19 -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 OAA04738 for ; Mon, 23 Jul 2001 14:35:32 -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 PAA14134 for ; Mon, 23 Jul 2001 15:36: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 OAA24037 for ; Mon, 23 Jul 2001 14:35:30 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6NLZUi03912 for ; Mon, 23 Jul 2001 14:35:30 -0700 X-mProtect: Mon, 23 Jul 2001 14:35:30 -0700 Nokia Silicon Valley Messaging Protection Received: from vijayd.iprg.nokia.com (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdylGAM5; Mon, 23 Jul 2001 13:41:43 PDT Message-ID: <3B5C8C06.219B470C@iprg.nokia.com> Date: Mon, 23 Jul 2001 13:41: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: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Dynamic Home Agent Address Discovery mechanism 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 and Franck, take a look at threat H.1 in section 6.8 of draft-team-mobileip-mipv6-seq-reqts-00.txt the requirement H.1 that follows it, states that "An HA which responds to an ICMP home agent discovery message MUST only do so after authenticating the MN's identity". Vijay > > Well the question is "Can you really hide the identity of your HAs?" And > > from the current spec, that is not totally possible. But it should also > > be made more difficult to obtain the identity of the HAs in a network. > > The current discovery mechanism allows just about anyone to send the > > ICMP discovery request and obtain a list of all HAs in the network. > > So it really boils down to making it a little more difficult to learn > > the identity of HAs. > > > => I understand your concern and appreciate the aim, but my > point is that you will never by able to hide the home subnet's > prefix. Granted that you can make it more difficult to find all > the HAs on the link, for a price. Until we see a proposal > for securing the HA discovery mechanism it is difficult > to know what that price is. > > > And again to emphasize, the suggestion is to have security parameters in > > the discovery message be optional. > > > => Understood, but since IPsec is not really an option here > we need to evaluate the method for securing the discovery. > That's why I asked if you had a proposal. Simply adding text > to say it should be secure is not enough. Perhaps when the final > solution > comes out for securing BUs we could see if it can be > reused. > But so far, the solutions proposed for key exchange don't > seem to work for an anycast address either, unless I > missed something. > > Regs, > Hesham > From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 23 18:13:27 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27584 for ; Mon, 23 Jul 2001 18:13:27 -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 PAA26976; Mon, 23 Jul 2001 15:14:07 -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 PAA23859; Mon, 23 Jul 2001 15:13:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6NMCYu16922 for mobile-ip-dist; Mon, 23 Jul 2001 15:12:34 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6NMCUY16915 for ; Mon, 23 Jul 2001 15:12:30 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA11816 for ; Mon, 23 Jul 2001 15:12:44 -0700 (PDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id PAA25569 for ; Mon, 23 Jul 2001 15:12:44 -0700 (PDT) Received: (qmail 20011 invoked by uid 500); 23 Jul 2001 22:01:49 -0000 Date: Mon, 23 Jul 2001 15:01:49 -0700 From: Pat Calhoun To: Joe Lau Cc: pcalhoun@diameter.org, aaa-wg@merit.edu, mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Re: [AAA-WG]: Re: Proposed Text for Issue 91 (KDC) Message-ID: <20010723150149.W10225@charizard.diameter.org> Mail-Followup-To: Joe Lau , pcalhoun@diameter.org, aaa-wg@merit.edu, mobile-ip@sunroof.eng.sun.com References: <200107232019.NAA16669@strtio1.cup.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200107232019.NAA16669@strtio1.cup.hp.com>; from jlau@cup.hp.com on Mon, Jul 23, 2001 at 01:19:27PM -0700 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 Mon, Jul 23, 2001 at 01:19:27PM -0700, Joe Lau wrote: > Hi Pat, > > With MIP-MN-to-HA-Key defined as a grouped AVP instead of the previous > Generalized Key Reply Extension with Unsolicited MN-FA Key Material subtype, > > MIP-MN-to-FA-Key ::== > { MIP-Algorithm-Type } > { MIP-Session-Key } > * [ AVP] > > how can the HA figure out the "AAA SPI" field in order to create the > Generalized Key Reply Extension with Unsolicited MN-FA Key Material subtype > in the Registration Reply to the MN. Ah, I see the problem. Yes, this Grouped AVP does need to include the AAA SPI, which the HA includes in the MIP key extension. Another issue that needs to be resolved as part of last call comments. Thanks, PatC > Also, am I right that AAA SPI refers to algorithm like CHAP-SPI? What > are the other possible algorithms? No, the SPI refers to an encryption transform. Similar to MIP autentication extensions, both sides have an SPI that points to the auth transform used in the authenticator computation, the AAA SPI will point to the transform used to encrypt/decrypt the session keys. Hope this helps, PatC From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 23 19:06:02 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA29591 for ; Mon, 23 Jul 2001 19:06:00 -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 QAA16866; Mon, 23 Jul 2001 16:06: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 QAA04389; Mon, 23 Jul 2001 16:06:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6NN4l517091 for mobile-ip-dist; Mon, 23 Jul 2001 16:04:47 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6NN4hY17084 for ; Mon, 23 Jul 2001 16:04:44 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id QAA10974; Mon, 23 Jul 2001 16:04:56 -0700 (PDT) Message-Id: <200107232304.QAA10974@heliopolis.eng.sun.com> Date: Mon, 23 Jul 2001 16:04:55 -0700 (PDT) From: James Kempf Subject: RE: [mobile-ip] Handover Smoothing - What to Do? To: mobile-ip@sunroof.eng.sun.com, Basavaraj.Patil@nokia.com Cc: James.Kempf@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Qo4x79I+GjWd7TjXR1MQHg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 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: Hi Raj, >Smooth handoffs is important for certain types of applications >only, but the goal of the current handoff work in the Mobile IP WG is >primarily on fast handoff (I hope we do not get into arguments on >terminology here). >I believe it is better to deal with smoothing of handoffs as a >separate work item/milestone. We also need to let the bicasting and >buffering drafts get some more discussion and input, as individual >I-Ds before trying to combine them. >The current WG handoff specs (lowlatency & fast) should not focus on >this aspect of handoffs. > Do you think it would be best to remove the discussion of bicasting in the low latency MIPv4 draft? Currently, the draft does not discuss how to do bicasting, it just states that bicasting should be used for handover smoothing, as opposed to buffering. jak From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 23 19:18:29 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA00261 for ; Mon, 23 Jul 2001 19:18:27 -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 RAA20573; Mon, 23 Jul 2001 17:19: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 QAA06813; Mon, 23 Jul 2001 16:18:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6NNHKt17178 for mobile-ip-dist; Mon, 23 Jul 2001 16:17:20 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6NNHGY17171 for ; Mon, 23 Jul 2001 16:17:16 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA20763 for ; Mon, 23 Jul 2001 16:17:29 -0700 (PDT) Received: from birch.ee.vt.edu (birch.ee.vt.edu [128.173.88.34]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA21226 for ; Mon, 23 Jul 2001 16:17:28 -0700 (PDT) Received: from eagle.ee.vt.edu (eagle.ee.vt.edu [128.173.88.147]) by birch.ee.vt.edu (8.9.3/8.9.3) with ESMTP id TAA18564; Mon, 23 Jul 2001 19:17:26 -0400 (EDT) Received: (from wells@localhost) by eagle.ee.vt.edu (8.9.3+Sun/8.9.3) id TAA17538; Mon, 23 Jul 2001 19:17:25 -0400 (EDT) Date: Mon, 23 Jul 2001 19:17:25 -0400 From: John Wells To: mobile-ip@sunroof.eng.sun.com Cc: claude.castelluccia@inrialpes.fr Subject: Re: [mobile-ip] Question on draft-team-mobileip-mipv6-sec-reqts-00.txt Message-ID: <20010723191725.B17492@horus.imag.fr> References: <697DAA22C5004B4596E033803A7CEF440860AD@daebe007.NOE.Nokia.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="LpQ9ahxlCli8rRTG" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <697DAA22C5004B4596E033803A7CEF440860AD@daebe007.NOE.Nokia.com>; from Basavaraj.Patil@nokia.com on Mon, Jul 23, 2001 at 11:30:04AM -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: --LpQ9ahxlCli8rRTG Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable lundi, le 23 juil 2001 =E0 11h30 -0500, Basavaraj.Patil@nokia.com a =E9crit= : > > =20 > >Hello,=20 > > > >This is a very interesting draft ... too bad that the privacy issues > >are not addressed... =20 > =20 > Privacy should be dealt with separately. In order to get MIPv6 spec to > PS, we need to solve the more immediate problem. I've written a report on dealing with privacy issues in a MIPv6 environment, see http://www.ee.vt.edu/~wells. Lots of little pieces exist to help ensure privacy (ex. RFC 3041 -- Stateless Address Autoconf privacy extensions), but as of yet, no comprehensive solution exists. Perhaps we should draft up some requirements? --john --=20 John WELLS Virginia Tech Networking and Visualization Lab PGP Public key: http://www.ee.vt.edu/~wells/pgpkey.txt --LpQ9ahxlCli8rRTG Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (SunOS) Comment: For info see http://www.gnupg.org iD8DBQE7XLCEtvPFKAfa3SIRAtmVAJ9/2fNyurSLxi99F8KndzEfUrutlACfZ2OS jAJAkN2VgcVeKNBn6qtZtv0= =mFeF -----END PGP SIGNATURE----- --LpQ9ahxlCli8rRTG-- From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 23 23:55:06 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA11110 for ; Mon, 23 Jul 2001 23:55:06 -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 VAA11034; Mon, 23 Jul 2001 21:55: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 UAA00353; Mon, 23 Jul 2001 20:55:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6O3rpM17731 for mobile-ip-dist; Mon, 23 Jul 2001 20:53:51 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6O3rlY17724 for ; Mon, 23 Jul 2001 20:53:48 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA26679 for ; Mon, 23 Jul 2001 20:54:00 -0700 (PDT) From: Basavaraj.Patil@nokia.com Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA19321 for ; Mon, 23 Jul 2001 20:53:59 -0700 (PDT) Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f6O3rni19066 for ; Mon, 23 Jul 2001 22:54:01 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Mon, 23 Jul 2001 22:53:46 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.1600); Mon, 23 Jul 2001 22:53:46 -0500 content-class: urn:content-classes:message Subject: RE: [mobile-ip] Handover Smoothing - What to Do? Date: Mon, 23 Jul 2001 22:53:46 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF440860C1@daebe007.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 Thread-Topic: [mobile-ip] Handover Smoothing - What to Do? Thread-Index: AcETy+YLrWngI3+1EdWxLgAIx6TWeAAKF2DQ To: , X-OriginalArrivalTime: 24 Jul 2001 03:53:46.0797 (UTC) FILETIME=[3D821DD0:01C113F4] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f6O3rmY17725 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 Hi James, >Hi Raj, > > >>Smooth handoffs is important for certain types of applications >>only, but the goal of the current handoff work in the Mobile IP WG is >>primarily on fast handoff (I hope we do not get into arguments on >>terminology here). >>I believe it is better to deal with smoothing of handoffs as a >>separate work item/milestone. We also need to let the bicasting and >>buffering drafts get some more discussion and input, as individual >>I-Ds before trying to combine them. >>The current WG handoff specs (lowlatency & fast) should not focus on >>this aspect of handoffs. >> > >Do you think it would be best to remove the discussion of bicasting >in the low latency MIPv4 draft? Currently, the draft does not >discuss how to do bicasting, it just states that bicasting should >be used for handover smoothing, as opposed to buffering. > What value does the discussion on bicasting add to the low latency MIPv4 draft? I would recommend removing it and focusing on smoothing of handoffs in a separate I-D. Handoff smoothing can also be achieved by buffering. So why recommend only bicasting as the mechanism for the desired effect? I do not believe there has been any real consensus of going one way vs the other. > jak > -Basavaraj From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 24 00:06:16 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA11279 for ; Tue, 24 Jul 2001 00:06:16 -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 VAA21226; Mon, 23 Jul 2001 21:06:58 -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 VAA01501; Mon, 23 Jul 2001 21:06:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6O44es17791 for mobile-ip-dist; Mon, 23 Jul 2001 21:04:40 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6O44aY17784 for ; Mon, 23 Jul 2001 21:04:36 -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 VAA27472 for ; Mon, 23 Jul 2001 21:04:49 -0700 (PDT) From: Basavaraj.Patil@nokia.com Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA13990 for ; Mon, 23 Jul 2001 22:04:47 -0600 (MDT) Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f6O44oi19270 for ; Mon, 23 Jul 2001 23:04:50 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Mon, 23 Jul 2001 23:04:48 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.1600); Mon, 23 Jul 2001 23:04:47 -0500 content-class: urn:content-classes:message Subject: [mobile-ip] Use of NATs/VPN with MIP discussion at IETF51 Date: Mon, 23 Jul 2001 23:04:47 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF440860C3@daebe007.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 Thread-Topic: Use of NATs/VPN with MIP discussion at IETF51 Thread-Index: AcET9dcyw7rXLH/kEdWwVwAAhj/HZA== To: X-OriginalArrivalTime: 24 Jul 2001 04:04:47.0723 (UTC) FILETIME=[C7736BB0:01C113F5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f6O44bY17785 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, Since there has been some discussion on this topic on the list and a few drafts proposing solutions, I had proposed (to some of the authors of these I-Ds) that we get together at IETF51 to discuss this topic outside the Mobile IP WG meeting. We can expand this to involve all those who are interested in this topic. A couple of possibilities: 1. Meet on Sunday (Aug 5th) evening at the registration desk (or the bar) 2. Meet on Monday afternoon (between 2:00 and 4:00 PM) Please e-mail me directly (Basavaraj.Patil@nokia.com) if you wish to participate and we will decide by the end of this week on when/where to meet. Cheers, -Basavaraj From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 24 04:12:28 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA03613 for ; Tue, 24 Jul 2001 04:12:28 -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 BAA07450; Tue, 24 Jul 2001 01:12: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 BAA02301; Tue, 24 Jul 2001 01:12:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6O8Alm18169 for mobile-ip-dist; Tue, 24 Jul 2001 01:10:47 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6O8AiY18162 for ; Tue, 24 Jul 2001 01:10:44 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA22099 for ; Tue, 24 Jul 2001 01:10:56 -0700 (PDT) Received: from mail.zrz.tu-berlin.de (mail.zrz.TU-Berlin.DE [130.149.4.15]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA06479 for ; Tue, 24 Jul 2001 01:10:55 -0700 (PDT) Received: from ftsu07.ee.tu-berlin.de ([130.149.49.87] helo=ftmail.ee.tu-berlin.de) by mail.zrz.tu-berlin.de with esmtp (exim-3.31) for id 15OxHK-0003c8-00; Tue, 24 Jul 2001 10:10:54 +0200 Received: from ee.tu-berlin.de (fu@sinope.ee.TU-Berlin.DE [130.149.49.127]) by ftmail.ee.tu-berlin.de (8.11.3/8.11.3) with ESMTP id f6O8Arh30314 for ; Tue, 24 Jul 2001 10:10:53 +0200 Message-ID: <3B5D2D8D.29DAFEC1@ee.tu-berlin.de> Date: Tue, 24 Jul 2001 10:10:53 +0200 From: Xiaoming Fu Organization: Telecommunication Networks Group, TU-Berlin X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.14 i686) X-Accept-Language: en-US, de, zh-CN MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] draft-tkn-mobileip-qosbinding-mipv6-00.txt 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 Hi Hemant, Hemant Chaskar wrote: > > Why do we need CT(oldAR to MAP)? Since downlink data flows thorugh MAP and > assuming that QoS was established using h-b-h option, MAP can just store > that object along with mobility bindings. So when it receives BU from > whaterver router (old or new) for this binding, it knows how to and where to > send h-b-h option in BA. Doing CT from AR to MAP will open up can of worms > each worm trying to do CT between AR and its application proxy. Theoretically the QoS can be stored either in MAP or AR. However, if storing in MAP, what happens for an inter-MAP mobility? A MN may initate a new BU+QoS from MN-->(nAR)-->MAP? Or ask the oMAP to perform CT(oMAP-->nMAP)? Or additionally, ask QoS-CT(oMAP-->nAR)? Note we have to further the BU+QoS towards the higher level of hierarchy until the switching point (either might be a MAP or HA or even CN), and this may result in a strange sequence in BU and QoS setup. In contrast, if storing in MAP, except the case of Fast Handoffs, we can do CT(oAR-->nAR), and process the BU+QoS from the oAR until the switching point in a conforming way. Xiaoming From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 24 05:54:48 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA05153 for ; Tue, 24 Jul 2001 05:54:48 -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 CAA03233; Tue, 24 Jul 2001 02:54:54 -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 CAA29573; Tue, 24 Jul 2001 02:54:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6O9r2N18270 for mobile-ip-dist; Tue, 24 Jul 2001 02:53:02 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6O9qwY18263 for ; Tue, 24 Jul 2001 02:52:59 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA09566 for ; Tue, 24 Jul 2001 02:53:13 -0700 (PDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA12576 for ; Tue, 24 Jul 2001 02:53:11 -0700 (PDT) Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f6O9rAO01892 for ; Tue, 24 Jul 2001 11:53:10 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Tue Jul 24 11:53:08 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Jul 2001 11:53:08 +0200 Message-ID: <795A014AF92DD21182AF0008C7A404320C520483@esealnt117> From: "Karim El-Malki (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" , James.Kempf@sun.com Subject: RE: [mobile-ip] Handover Smoothing - What to Do? Date: Tue, 24 Jul 2001 11:53:01 +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: Hello Raj and James > >>Smooth handoffs is important for certain types of applications > >>only, but the goal of the current handoff work in the > Mobile IP WG is > >>primarily on fast handoff (I hope we do not get into arguments on > >>terminology here). > >>I believe it is better to deal with smoothing of handoffs as a > >>separate work item/milestone. We also need to let the bicasting and > >>buffering drafts get some more discussion and input, as individual > >>I-Ds before trying to combine them. > >>The current WG handoff specs (lowlatency & fast) should not focus on > >>this aspect of handoffs. > >> > > > >Do you think it would be best to remove the discussion of bicasting > >in the low latency MIPv4 draft? Currently, the draft does not > >discuss how to do bicasting, it just states that bicasting should > >be used for handover smoothing, as opposed to buffering. > > > > What value does the discussion on bicasting add to the low latency > MIPv4 draft? Without bicasting (or some alternative) the low latency draft is not complete. That is, someone implementing it will find that a certain period of service disruption will most likely be introduced by the low latency mechanism. There will be a time difference between the moment in which the MN sends an "anticipated" Registration to the nFA (PRE-REG) or the H'off Req/Reply are sent between nFA-oFA in anticipation of the handoff (POST-REG) and the moment in which the MN actually completes the L2 handoff to nFA. This means that there is no knowledge at L3 as to where the MN is exactly during that period and when it will make the L2 handoff, so packets will be sent to nFA while the MN is actually still at oFA. For the duration of this L3-handoff "anticipation" period (period shortly after the trigger and until the MN's L2 movement) the MN could be unable to communicate. However, the whole purpose of the low latency draft is to reduce and possibly eliminate the period of service disruption due to handoff. So if we take bicasting out we haven't solved the problem we aimed to solve. >I would recommend removing it and focusing on smoothing > of handoffs in a separate I-D. Handoff smoothing can also be achieved > by buffering. So why recommend only bicasting as the mechanism for the > desired effect? I do not believe there has been any real consensus of > going one way vs the other. > There has been consensus among the design team members and up to now we have not received negative comments on the low latency draft nor during the IETF presentations. I would be happy to consider buffering as an alternative and eventually add it into the draft if the authors/WG want this, but all the methods must satisfy the requirement of eliminating the period of service disruption due to L3 handoff independently of the L2 characteristics. Without this IMO the draft would not serve its purpose. Regards /Karim From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 24 08:09:06 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA12000 for ; Tue, 24 Jul 2001 08:09:05 -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 FAA05767; Tue, 24 Jul 2001 05:09:41 -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 FAA09462; Tue, 24 Jul 2001 05:09:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6OC7Q718446 for mobile-ip-dist; Tue, 24 Jul 2001 05:07:26 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6OC7MY18439 for ; Tue, 24 Jul 2001 05:07: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 FAA18744 for ; Tue, 24 Jul 2001 05:07:36 -0700 (PDT) Received: from RRMAIL01.RADIOROUTER_NT ([63.103.94.23]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA04493 for ; Tue, 24 Jul 2001 06:07:34 -0600 (MDT) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Jul 2001 08:07:33 -0400 Message-ID: <8C92E23A3E87FB479988285F9E22BE460546A1@ftmail> From: George Tsirtsis To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Handover Smoothing - What to Do? Date: Tue, 24 Jul 2001 08:07:33 -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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: -----Original Message----- From: Karim El-Malki (ERA) [mailto:Karim.El-Malki@era.ericsson.se] Sent: Tuesday, July 24, 2001 10:53 AM To: 'mobile-ip@sunroof.eng.sun.com'; James.Kempf@sun.com Subject: RE: [mobile-ip] Handover Smoothing - What to Do? Hello Raj and James ... >I would recommend removing it and focusing on smoothing > of handoffs in a separate I-D. Handoff smoothing can also be achieved > by buffering. So why recommend only bicasting as the mechanism for the > desired effect? I do not believe there has been any real consensus of > going one way vs the other. > There has been consensus among the design team members and up to now we have not received negative comments on the low latency draft nor during the IETF presentations. I would be happy to consider buffering as an alternative and eventually add it into the draft if the authors/WG want this, but all the methods must satisfy the requirement of eliminating the period of service disruption due to L3 handoff independently of the L2 characteristics. Without this IMO the draft would not serve its purpose. GT> This was discussed in (I think) much greater length in the FMIPv6 design team and enough doubts were raised to exclude bicasting from the FMIPv6 spec and encourage its proponents to publish the idea as a separate document, which they did...well done :). The main argument against bicasting was regarding its possible effects on TCP. Bicasting would duplicate TCP ACKS (along with everything else) and as we know 3 dupacks result in TCP shrinking its window...dupacks occur naturally by TCP as a result of the network loosing or reordering packets and the chance of 3 dupacks in a row is not very high. We thought that bicasting may increase the chance of 3 dupacks and thus impact TCP performance. Note that there has been work towards eliminating this well known problem and Karim can point the list to this work since I do not remember that draft name. Nevertheless, the FMIPv6 team decided that bicasting has experimental nature and the TCP fix was at the time a draft at v00...early days => not enough practical experiance or understanding of what a possiby wide spread use of bicasting do to TCP. For all the above we thought that bicasting should be discussed as a separate item and the FMIPv6 spec should not be dependant on it. The fact that the FMIPv4 team did not take the same decision always concerned me a bit... IMO smoothing (bicasting and/or buffering) should be separate specs from the FMIPv4/v6 not only because of the uncertainty regarding bicasting but also because (again IMO) smooth handoffs may be achieved at the implementation level and without protocol support. That is not to say that protocol work may not help and should not be done...but only to indicate that "smooth handoff" work should be separate from the FMIP work. In fact, smooth handoffs could be viewed as optional extensions to the FMIP specs. Thanks George From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 24 11:08:48 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23387 for ; Tue, 24 Jul 2001 11:08:48 -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 JAA02608; Tue, 24 Jul 2001 09:09:24 -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 IAA04015; Tue, 24 Jul 2001 08:08:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6OF6cf18771 for mobile-ip-dist; Tue, 24 Jul 2001 08:06:38 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6OF6YY18764 for ; Tue, 24 Jul 2001 08:06: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 IAA09984 for ; Tue, 24 Jul 2001 08:06:48 -0700 (PDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA00320 for ; Tue, 24 Jul 2001 09:06:45 -0600 (MDT) Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f6OF6jO19769 for ; Tue, 24 Jul 2001 17:06:45 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Tue Jul 24 17:06:45 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Jul 2001 17:06:41 +0200 Message-ID: <795A014AF92DD21182AF0008C7A404320C520488@esealnt117> From: "Karim El-Malki (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Handover Smoothing - What to Do? Date: Tue, 24 Jul 2001 17:06:35 +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: Hi George > Note that there has been work towards eliminating this well > known problem > and Karim can point the list to this work since I do not > remember that draft > name. Nevertheless, the FMIPv6 team decided that bicasting > has experimental > nature and the TCP fix was at the time a draft at v00...early > days => not > enough practical experiance or understanding of what a > possiby wide spread > use of bicasting do to TCP. For all the above we thought that > bicasting > should be discussed as a separate item and the FMIPv6 spec > should not be > dependant on it. The fact that the FMIPv4 team did not take the same > decision always concerned me a bit... The TCP issue is discussed with reference (EIFEL algorithm for TCP) in the bicasting draft. Also, for the scenarios we consider in low-latency, the MN will not get multiple copies of packets. The "second" copy gets discarded by the non-connected FA (e.g. nFA) and an ICMP error is not transmitted. Alternatively that second copy may be buffered. When the MN connects to nFA it no longer receives from oFA. That's what the draft specifies and I think that should be quite typical for a single-interfaced MN. So that's why we went for this solution and allowed bicasting. The TCP issues should not be involved. > > IMO smoothing (bicasting and/or buffering) should be separate > specs from the > FMIPv4/v6 not only because of the uncertainty regarding > bicasting but also > because (again IMO) smooth handoffs may be achieved at the > implementation > level and without protocol support. That is not to say that > protocol work > may not help and should not be done...but only to indicate > that "smooth > handoff" work should be separate from the FMIP work. In fact, smooth > handoffs could be viewed as optional extensions to the FMIP specs. What do you mean by achieving smoothing at the implementation level? I looked back at the low-latency spec and noticed an inconsistency in that the simultaneous binding is a MAY in PRE-REG and a MUST in POST-REG. I think the aim was to keep it as a MAY. So I would consider it as optional already. What makes me unconfortable in putting all this in another spec is that it would defeat one of the main purposes of this document: reduce/eliminate service disruption due to handoff. Or did you mean to state the problems in the FMIP drafts and have them point to a new bicasting/buffering draft for optional implementation? In both cases, having it in or outside the FMIP drafts, we must have these "smoothing" options. What I don't understand is what the difference is with what we have today? You don't need to implement bicasting or buffering if you don't need it, so what you want is already there. Regards /Karim From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 24 11:26:42 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA24716 for ; Tue, 24 Jul 2001 11:26:37 -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 JAA17877; Tue, 24 Jul 2001 09:27: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 IAA08295; Tue, 24 Jul 2001 08:26:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6OFPRK18915 for mobile-ip-dist; Tue, 24 Jul 2001 08:25:27 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6OFPKY18906 for ; Tue, 24 Jul 2001 08:25:20 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA02493 for ; Tue, 24 Jul 2001 08:25:33 -0700 (PDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA01088 for ; Tue, 24 Jul 2001 08:25:32 -0700 (PDT) Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f6OFPUO27372 for ; Tue, 24 Jul 2001 17:25:30 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Tue Jul 24 17:25:27 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Jul 2001 17:25:23 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008B4D@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Handover Smoothing - What to Do? Date: Tue, 24 Jul 2001 17:25:17 +0200 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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: George, Just a couple of comments in addition to Karim's > >I would recommend removing it and focusing on smoothing > > of handoffs in a separate I-D. Handoff smoothing can also be achieved > > by buffering. So why recommend only bicasting as the mechanism for the > > desired effect? I do not believe there has been any real consensus of > > going one way vs the other. > > > > There has been consensus among the design team members and up to now > we have not received negative comments on the low latency draft nor during > the IETF presentations. I would be happy to consider buffering as an > alternative and eventually add it into the draft if the authors/WG want > this, > but all the methods must satisfy the requirement of eliminating the period > of > service disruption due to L3 handoff independently of the L2 > characteristics. > Without this IMO the draft would not serve its purpose. > > GT> This was discussed in (I think) much greater length in the FMIPv6 design > team and enough doubts were raised to exclude bicasting from the FMIPv6 spec > and encourage its proponents to publish the idea as a separate document, > which they did...well done :). The main argument against bicasting was > regarding its possible effects on TCP. Bicasting would duplicate TCP ACKS > (along with everything else) and as we know 3 dupacks result in TCP > shrinking its window...dupacks occur naturally by TCP as a result of the > network loosing or reordering packets and the chance of 3 dupacks in a row > is not very high. We thought that bicasting may increase the chance of 3 > dupacks and thus impact TCP performance. > > Note that there has been work towards eliminating this well known problem > and Karim can point the list to this work since I do not remember that draft > name. Nevertheless, the FMIPv6 team decided that bicasting has experimental > nature and the TCP fix was at the time a draft at v00...early days => not > enough practical experiance or understanding of what a possiby wide spread > use of bicasting do to TCP. For all the above we thought that bicasting > => I don't think we can judge other people's work on TCP in this WG. Because I know the author and have seen his experiments and know how long this work has been trialled for I can say that your judgement is incorrect. Some 00 drats go straight to last call in many WGs. We all (the DT members for v6) got these links and saw how long this work has gone for so I think we can safely say that there is a solution. > IMO smoothing (bicasting and/or buffering) should be separate specs from the > FMIPv4/v6 not only because of the uncertainty regarding bicasting but also > because (again IMO) smooth handoffs may be achieved at the implementation > level and without protocol support. That is not to say that protocol work > may not help and should not be done...but only to indicate that "smooth > handoff" work should be separate from the FMIP work. In fact, smooth > handoffs could be viewed as optional extensions to the FMIP specs. > => Respectfully disagree here (but I guess you knew that :)). The whole point of the draft is to provide minimal loss during IP handovers. How can we claim that it's successful when we have a section that says if we have ping pong then this won't really work ? I just don't understand what having a different draft will achieve apart from more paper work last calls .....etc. I prefer to discuss the technical merits which is why we agreed to writing a draft in the first place. IMHO we should have one draft for v4 and one for v6 as was always planned. Hesham From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 24 11:34:27 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA25282 for ; Tue, 24 Jul 2001 11:34:26 -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 IAA23984; Tue, 24 Jul 2001 08:35: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 IAA10346; Tue, 24 Jul 2001 08:34:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6OFXZU18980 for mobile-ip-dist; Tue, 24 Jul 2001 08:33:35 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6OFXVY18973 for ; Tue, 24 Jul 2001 08:33:31 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id IAA07715 for ; Tue, 24 Jul 2001 08:33:44 -0700 (PDT) Message-Id: <200107241533.IAA07715@heliopolis.eng.sun.com> Date: Tue, 24 Jul 2001 08:33:44 -0700 (PDT) From: James Kempf Subject: Re: [mobile-ip] Use of NATs/VPN with MIP discussion at IETF51 To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 5h83ylSDnQDQ+FuB2+G6eA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 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: I'd like to participate. jak >From: Basavaraj.Patil@nokia.com >content-class: urn:content-classes:message >Subject: [mobile-ip] Use of NATs/VPN with MIP discussion at IETF51 >Date: Mon, 23 Jul 2001 23:04:47 -0500 >X-MS-Has-Attach: >X-MS-TNEF-Correlator: >X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 >Thread-Topic: Use of NATs/VPN with MIP discussion at IETF51 >Thread-Index: AcET9dcyw7rXLH/kEdWwVwAAhj/HZA== >To: >X-OriginalArrivalTime: 24 Jul 2001 04:04:47.0723 (UTC) FILETIME=[C7736BB0:01C113F5] >X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f6O44bY17785 > >Hello, > >Since there has been some discussion on this topic on the list and a few >drafts >proposing solutions, I had proposed (to some of the authors of these >I-Ds) that >we get together at IETF51 to discuss this topic outside the Mobile IP WG >meeting. >We can expand this to involve all those who are interested in this >topic. > >A couple of possibilities: >1. Meet on Sunday (Aug 5th) evening at the registration desk (or the >bar) >2. Meet on Monday afternoon (between 2:00 and 4:00 PM) > >Please e-mail me directly (Basavaraj.Patil@nokia.com) if you wish to >participate and we will decide by the end of this week on when/where to >meet. > >Cheers, >-Basavaraj > > From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 24 11:38:37 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA25601 for ; Tue, 24 Jul 2001 11:38:35 -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 IAA26181; Tue, 24 Jul 2001 08:39: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 IAA11340; Tue, 24 Jul 2001 08:38:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6OFbY719033 for mobile-ip-dist; Tue, 24 Jul 2001 08:37:34 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6OFbUY19026 for ; Tue, 24 Jul 2001 08:37:31 -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 IAA04812 for ; Tue, 24 Jul 2001 08:37:44 -0700 (PDT) Received: from RRMAIL01.RADIOROUTER_NT ([63.103.94.23]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA25509 for ; Tue, 24 Jul 2001 09:39:03 -0600 (MDT) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Jul 2001 11:37:36 -0400 Message-ID: <8C92E23A3E87FB479988285F9E22BE460546A5@ftmail> From: George Tsirtsis To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Handover Smoothing - What to Do? Date: Tue, 24 Jul 2001 11:37:36 -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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: -----Original Message----- From: Karim El-Malki (ERA) [mailto:Karim.El-Malki@era.ericsson.se] Sent: Tuesday, July 24, 2001 4:07 PM To: 'mobile-ip@sunroof.eng.sun.com' Subject: RE: [mobile-ip] Handover Smoothing - What to Do? Hi George > Note that there has been work towards eliminating this well > known problem > and Karim can point the list to this work since I do not > remember that draft > name. Nevertheless, the FMIPv6 team decided that bicasting > has experimental > nature and the TCP fix was at the time a draft at v00...early > days => not > enough practical experiance or understanding of what a > possiby wide spread > use of bicasting do to TCP. For all the above we thought that > bicasting > should be discussed as a separate item and the FMIPv6 spec > should not be > dependant on it. The fact that the FMIPv4 team did not take the same > decision always concerned me a bit... The TCP issue is discussed with reference (EIFEL algorithm for TCP) in the bicasting draft. Also, for the scenarios we consider in low-latency, the MN will not get multiple copies of packets. The "second" copy gets discarded by the non-connected FA (e.g. nFA) and an ICMP error is not transmitted. Alternatively that second copy may be buffered. When the MN connects to nFA it no longer receives from oFA. That's what the draft specifies and I think that should be quite typical for a single-interfaced MN. So that's why we went for this solution and allowed bicasting. The TCP issues should not be involved. GT> The nFA has no way of know at which point the transmission was severed at the oldFA...i.e.: if the bicasted packets are buffered at the newFA (which I assume they will so this is useful) the TCP issues remain! > > IMO smoothing (bicasting and/or buffering) should be separate > specs from the > FMIPv4/v6 not only because of the uncertainty regarding > bicasting but also > because (again IMO) smooth handoffs may be achieved at the > implementation > level and without protocol support. That is not to say that > protocol work > may not help and should not be done...but only to indicate > that "smooth > handoff" work should be separate from the FMIP work. In fact, smooth > handoffs could be viewed as optional extensions to the FMIP specs. What do you mean by achieving smoothing at the implementation level? GT> I mean that routers can buffer without the involvement of the MN i.e.: without the need for a protocol based negotiation. I looked back at the low-latency spec and noticed an inconsistency in that the simultaneous binding is a MAY in PRE-REG and a MUST in POST-REG. I think the aim was to keep it as a MAY. So I would consider it as optional already. What makes me unconfortable in putting all this in another spec is that it would defeat one of the main purposes of this document: reduce/eliminate service disruption due to handoff. Or did you mean to state the problems in the FMIP drafts and have them point to a new bicasting/buffering draft for optional implementation? In both cases, having it in or outside the FMIP drafts, we must have these "smoothing" options. What I don't understand is what the difference is with what we have today? You don't need to implement bicasting or buffering if you don't need it, so what you want is already there. GT> I also stated that "smoothing" options are useful and are needed so no disagreement there. I am only arguing that it is a separable piece of work. - multiple ways of smoothing are possible for the same FMIP mechanism - there is a discussion to be made about buffering based methods vs bicasting based methods. I think both have merit but recommendation of one of the two would be nice interoperability/simplicity purposes - smoothing work is not as mature are FMIP, has not been discussed at the same detail which also points to the fact that are separable. GT> Karim, my main argument in this thread is not against bicasting although I have my own concerns which you are very well aware off. The question in this thread is about separating "smooth" from "fast" specs and I think I am not the only one who things this may be a good idea. It makes specs thinner if nothing else and I, at least, believe that will make FMIP specs go through the standards process faster... GT> I think I have made my point others should comment too. George From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 24 11:40:17 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA25701 for ; Tue, 24 Jul 2001 11:40:16 -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 IAA27215; Tue, 24 Jul 2001 08:40: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 IAA11738; Tue, 24 Jul 2001 08:40:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6OFdYV19071 for mobile-ip-dist; Tue, 24 Jul 2001 08:39:34 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6OFdVY19060 for ; Tue, 24 Jul 2001 08:39:31 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA11527 for ; Tue, 24 Jul 2001 08:39:44 -0700 (PDT) Received: from sonne.darmstadt.gmd.de (sonne.darmstadt.gmd.de [141.12.62.20]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA10543 for ; Tue, 24 Jul 2001 08:39:40 -0700 (PDT) Received: from ipsi.fraunhofer.de (pc-morion [141.12.35.155]) by sonne.darmstadt.gmd.de (8.8.8/8.8.5) with ESMTP id RAA10731; Tue, 24 Jul 2001 17:39:35 +0200 (MET DST) Message-ID: <3B5D97AC.319B403@ipsi.fraunhofer.de> Date: Tue, 24 Jul 2001 17:43:40 +0200 From: Wolfgang Schoenfeld Organization: FhG IPSI X-Mailer: Mozilla 4.7 [de] (WinNT; I) X-Accept-Language: en,de MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] WG feedback on bicasting References: <795A014AF92DD21182AF0008C7A404320C52047F@esealnt117> 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 Karim, may I just restate my considerations which had - I admid - a few flaws? Assume again that a stream of packets is running from CN to MN via oFA (or oAR or ...). When MN moves, some redirection of the stream may be necessary (which is done by registration at the HA). Which events can trigger that? The emergence of a new link between MN and some nFA is a good candidate since the stream can use it (as long as it is stable). And this is what MIP does. However, to propagate the event to HA takes some time during which packets keep on running to oFA. And after redirection is done, packets take some time to reach MN. Hence, the round-trip time from MN to HA determines handoff latency time. Obviously, it can be reduced by bringing HA functionality closer to MN - which is the purpose of hierarchies. What else can be done? Nothing if we consider layer 3 alone since this would mean to by-pass registration message or data packets. In particular, bicast/multicast will not help. Another (the only?) way is guessing the emergence of a new link, i.e. taking outer "oracles" like layer 2 events, statistics etc. into account. In this case, bicasting can indeed make sense if the guess does not give a unique answer: Just multicast to all nodes which the guess predicts. (Broadcast would result from the most vague guess.) This increases the probability that all packets reach MN. Note however that multicast is concerned only with vagueness of guesses - if they are precise, multicasting does have not have any effect. Hence, fast handover without bicasting (your original question) does make sense. I'm not sure whether the above is now "gap-free". Hence, please comment. Wolfgang PS: Concerning James' "Handover Smoothing - What to Do?" which I appreciate very much - wouldn't it be reasonable to also have, for each of the proposals, some analysis of - Which cases are handled by the proposed architecture / functionality? - In these cases, what is the improvement achieved? - How often do these cases happen? "Karim El-Malki (ERA)" schrieb: > > Hello Wolfgang > > > I'm not able to comment on mobileip WG issues, > > but I believe that the role of bicasting for handover > > is not yet fully understood, both in MIPv4 and MIPv6. > > Considerations like the following for MIPv4 > > might help to decide. > > The aim of the draft is exactly to address the role > of bicasting in fast handovers (for MIPv6) and address > issues involved. > > > > > Obviously, bicasting makes sense only if MN is able > > to maintain more than one link simultaneously, > > say to oFA and nFA. > > That's not what the draft says and actually quite the > opposite. > > > Now assume that this is the case > > and consider handover without bicasting. > > Handover involves, among others, these events: > > > > (A) MN detects a link to nFA and issues a BU message to HA. > > (B) HA receives BU and updates binding of MN. > > (C) MN looses the link to oFA. > > > > How is a stream of packets from some CN to MN affected by handover? > > (A) does not affect the stream, but (B) does: > > Before (B), packets travel to oFA, > > and after (B), they travel to nFA > > (assume that HA buffers during (B)). > > Packets passing HA after (B) will reach MN, > > but what about those > > which pass HA before (B) and after (A)? > > Let us call them "critical" packets. > > The bicasting draft applies to fast handover v6 but your > example is different. You're also considering MIPv4 but this > draft is on MIPv6... > So I guess your comments are not on the draft itself but on > generic bicasting? > If you follow the fast handover v6 concepts then A & B would > occur some time in advance of when C occurs. We assume this > anticipation is enough such that the "critical" packets reach > the MN at its old link. That's also a good reason to use > a close-by or local HA like the MAP from HMIPv6. In fast > handover v6 the anticipated F-BU is sent to the oAR. So this > should not involve loss of "critical" packets. > > > If (C) happens only after all critical packets > > have passed the link from oFA to MN, > > then there is no packet loss at all. > > That's why the handoff is anticipated. > > > Now, what could bicasting improve? > > Non-critical packets need not be bicasted - > > they will reach MN anyhow. > > That's not necessarily true. The l2 handoff may > occur at any time relative to the MN's BU. > What if the MN hands-off (L2) to the new AR a certain > time after having sent the Fast-BU? Since the MN has > not moved yet the packets sent to nAR during this > time interval get lost. Bicasting instead gives us a > way to decouple l2 and l3 handoffs: the MN can communicate > no matter when the L2 handoff occurs. This is > discussed in the draft. > > > To summarize, > > simultaneous use of two links to MN - if they exist - > > is somehow "built-in" and can happen > > even if simultaneous binding is switched off. > > In fact bicasting is probably more useful on MNs with a > single link. > > > Switching it on will have no effect on packet loss!!! > > Bicasting does not make sense. > > > > It does make sense only if HA is able to predict (A). > > But move prediction is, as far as I understand, > > not an issue for MIPv4 or for MIPv6. > > Is it more clear now? > You were assuming things that are neither according to > fast handover v6 draft nor the bicasting draft which is > why you were coming to these conclusions. > > Regards > /Karim -- Prof. Dr. Wolfgang Schoenfeld, Fraunhofer IPSI, Dolivostr. 15, D-64293 Darmstadt Office: +49-6151-869-865 FAX: -6847 Mobile: +49-174-7093455 From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 24 12:04:44 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA27402 for ; Tue, 24 Jul 2001 12:04:43 -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 JAA09853; Tue, 24 Jul 2001 09:05: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 JAA16772; Tue, 24 Jul 2001 09:04:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6OG3Ce19213 for mobile-ip-dist; Tue, 24 Jul 2001 09:03:12 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6OG38Y19206 for ; Tue, 24 Jul 2001 09:03:08 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA25598 for ; Tue, 24 Jul 2001 09:03:22 -0700 (PDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA24550 for ; Tue, 24 Jul 2001 09:03:20 -0700 (PDT) Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f6OG3IO09286 for ; Tue, 24 Jul 2001 18:03:18 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Tue Jul 24 18:03:18 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Jul 2001 18:03:14 +0200 Message-ID: <795A014AF92DD21182AF0008C7A404320C520489@esealnt117> From: "Karim El-Malki (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Handover Smoothing - What to Do? Date: Tue, 24 Jul 2001 18:03: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: > GT> The nFA has no way of know at which point the > transmission was severed > at the oldFA...i.e.: if the bicasted packets are buffered at the newFA > (which I assume they will so this is useful) the TCP issues remain! Just a quick answer to this point. You're assuming that you will buffer and that may not be needed. It's a MAY in low-latency. If you do buffer, and have a fixed buffer/delay at nFA of the size of the duration of the L2 handoff (when the MN is disconnected at L2 while moving between oFA and nFA) then you shouldn't get duplicates. That's a possible solution since the L2 handover period is normally known in wireless systems. Rgds /Karim From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 24 12:18:37 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA28672 for ; Tue, 24 Jul 2001 12:18:36 -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 KAA04386; Tue, 24 Jul 2001 10:19:06 -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 JAA13469; Tue, 24 Jul 2001 09:18:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6OGGGt19289 for mobile-ip-dist; Tue, 24 Jul 2001 09:16:16 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6OGGCY19278 for ; Tue, 24 Jul 2001 09:16:12 -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 JAA29151 for ; Tue, 24 Jul 2001 09:16:25 -0700 (PDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA02022 for ; Tue, 24 Jul 2001 10:16:23 -0600 (MDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f6OGGNN28449 for ; Tue, 24 Jul 2001 18:16:23 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Tue Jul 24 18:16:23 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Jul 2001 18:16:19 +0200 Message-ID: <795A014AF92DD21182AF0008C7A404320C52048A@esealnt117> From: "Karim El-Malki (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] WG feedback on bicasting Date: Tue, 24 Jul 2001 18:16:22 +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: Hello Wolfgang > Another (the only?) way is guessing the emergence of a new link, > i.e. taking outer "oracles" like layer 2 events, statistics > etc. into account. That's the approach taken in FMIP (low-latency & fast handover drafts). I wouldn't consider link-layer "triggers" as statistics or guesses. They are messages from/at L2 which can "warn" the receiver in anticipation of a handoff event. So it's not a guess, the handoff will be or is being performed at L2. Note that an L2 handoff does not always mean a L3 handoff, so it is up to the L3 receiver of the trigger to determine whether FMIP is needed. The anticipation time instead will be dependent on the L2 system. > In this case, bicasting can indeed make sense > if the guess does not give a unique answer: > Just multicast to all nodes which the guess predicts. > (Broadcast would result from the most vague guess.) > This increases the probability that all packets reach MN. You can have simultaneous bindings with multiple COAs. So that gives the same result as multicasting without the need to join groups. > > Note however that multicast is concerned only with vagueness > of guesses - > if they are precise, multicasting does have not have any effect. > Hence, fast handover without bicasting > (your original question) does make sense. > > I'm not sure whether the above is now "gap-free". Hence, > please comment. It is not gap free since, assuming anticipated triggers and registrations (i.e. FMIP) you have no knowledge as to when the L2 handoff event occurs with respect to the moment the HA or local HA receives the BU/registration. So if the COA is updated too late or too early with respect to the L2 handoff event, the MN will find itself unable to communicate. That is what FMIP is trying to avoid. Regards /Karim From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 24 12:31:24 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA29539 for ; Tue, 24 Jul 2001 12:31:23 -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 KAA15969; Tue, 24 Jul 2001 10:32: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 JAA16632; Tue, 24 Jul 2001 09:31:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6OGUaf19388 for mobile-ip-dist; Tue, 24 Jul 2001 09:30:36 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6OGUXY19381 for ; Tue, 24 Jul 2001 09:30:33 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA16348 for ; Tue, 24 Jul 2001 09:30:46 -0700 (PDT) Received: from p-mail2.cnet.fr (p-mail2.rd.francetelecom.fr [193.49.124.32]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id JAA03860 for ; Tue, 24 Jul 2001 09:30:46 -0700 (PDT) Received: by p-voyageur.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Jul 2001 18:30:33 +0200 Received: from francetelecom.com (p-dico.rd.francetelecom.fr [139.100.18.135]) by p-grive.rd.francetelecom.fr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3ZBB7VRG; Tue, 24 Jul 2001 18:30:31 +0200 Message-ID: <3B5DA26F.1D35859C@francetelecom.com> Date: Tue, 24 Jul 2001 18:29:35 +0200 From: Jean-Michel COMBES Organization: France =?iso-8859-1?Q?T=E9l=E9com?= R&D X-Mailer: Mozilla 4.75 [fr] (Windows NT 5.0; U) X-Accept-Language: fr MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com CC: claude.castelluccia@inrialpes.fr Subject: Re: [mobile-ip] Question on draft-team-mobileip-mipv6-sec-reqts-00.txt References: <697DAA22C5004B4596E033803A7CEF440860AD@daebe007.NOE.Nokia.com> 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: X-MIME-Autoconverted: from 8bit to quoted-printable by patan.sun.com id KAA15969 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA29539 Hi, Basavaraj.Patil@nokia.com a écrit : > > > >Hello, > > > >This is a very interesting draft ... too bad that the privacy issues > >are not addressed... > > Privacy should be dealt with separately. In order to get MIPv6 spec to > PS, we need to solve the more immediate problem. JMC : ... which is securing BU/BAck (ie. granurality, authorization of using H@, etc ...) For more details, see Saturday Michael's email. Thus, IMHO, it would be preferable to work on two separate drafts : 1. one concerning immediate and _vital_ problem 2. one (which would be a Informal draft) concerning others threats which are not critical for MIPv6 mecanisms. > > > >Anyway i think that requirement H.3 should be: > > > > "CNs MUST NOT process any packet (BU or not) containing a Home > > Address option unless they have verified that that the node sending > > the packets is authorized to use the home address in the > > destination option: > > > > The above makes more sense. As you mention, a CN can be made a packet > reflector without creating a binding cache. Thanks for the input. JMC : Not agree. This threat is not specific to MIPv6 (see below). I think that the actual requirement H.3 is fine. > > > > > > In fact the MIPv6 draft says : > > "A node receiving a packet > > that includes a Home Address option MAY implement the processing of > > this option by physically exchanging the Home Address option field > > with the source IPv6 address in the IPv6 header." > > > > An attacker can then easily use a CN as a packet reflector with > > current MIPv6... > > it only needs to send packets with a home address option > > containing the victim address to several CNs... > > CNs will exchanged the source IPv6 address with the vicitim > > address and reply to the victim JMC : In my point of view, the result is like a static host using spoofing ... the only threat that is specific to MIPv6 is on MN using an unauthorized H@ when it sends BU. BTW, I don't understand the General Requirement C which is "Identity verification MUST not rely on the existence of a global PKI". I would prefer the sentence "Identity verification MAY not rely on the existence of a global PKI". 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 From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 24 12:32:16 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA29589 for ; Tue, 24 Jul 2001 12:32:15 -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 KAA13589; Tue, 24 Jul 2001 10:29:23 -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 JAA15919; Tue, 24 Jul 2001 09:29:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6OGREf19350 for mobile-ip-dist; Tue, 24 Jul 2001 09:27:14 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6OGRAY19343 for ; Tue, 24 Jul 2001 09:27:10 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA21095 for ; Tue, 24 Jul 2001 09:27:24 -0700 (PDT) Received: from zcars0m9.ca.nortel.com ([47.129.242.157]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA02049 for ; Tue, 24 Jul 2001 09:27:24 -0700 (PDT) Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f6OGQv914304 for ; Tue, 24 Jul 2001 12:26:57 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.ca.nortel.com; Tue, 24 Jul 2001 12:27:14 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Jul 2001 12:27:16 -0400 Message-ID: From: "Hongyi Li" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Handover Smoothing - What to Do? Date: Tue, 24 Jul 2001 12:27:12 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1145D.7E5BBD20" X-Orig: 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_01C1145D.7E5BBD20 Content-Type: text/plain; charset="iso-8859-1" Hi Karim, I think George was right in this point. For a single interface MN, if there is no synchronization between the two FAs, the MN will experience either packet loss or packet duplication depending on the direction of the handoff. Here is an example, at time t, assume FA1 is transmitting packet with seq no. x; FA2 is transmitting packet with seq no. x+2. If the MN handoff from FA1 to FA2, packet x+1 will be lost. If the MN handoff from FA2 to FA1 the MN will receive duplicated packet x+1. Buffering without synchronization won't help here. Regards Hongyi > -----Original Message----- > From: Karim El-Malki (ERA) [mailto:Karim.El-Malki@era.ericsson.se] > Sent: Tuesday, July 24, 2001 12:03 PM > To: 'mobile-ip@sunroof.eng.sun.com' > Subject: RE: [mobile-ip] Handover Smoothing - What to Do? > > > > GT> The nFA has no way of know at which point the > > transmission was severed > > at the oldFA...i.e.: if the bicasted packets are buffered > at the newFA > > (which I assume they will so this is useful) the TCP issues remain! > > Just a quick answer to this point. You're assuming that you > will buffer > and that may not be needed. It's a MAY in low-latency. If you > do buffer, > and have a fixed buffer/delay at nFA of the size of the > duration of the > L2 handoff (when the MN is disconnected at L2 while moving between oFA > and nFA) then you shouldn't get duplicates. That's a possible solution > since the L2 handover period is normally known in wireless systems. > > Rgds > /Karim > ------_=_NextPart_001_01C1145D.7E5BBD20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Handover Smoothing - What to Do?

Hi Karim,
  I think George was right in this = point.
  For a single interface MN, if there is no = synchronization between the
two FAs, the MN will experience either packet loss = or packet duplication
depending on the direction of the handoff.
  Here is an example, at time t, assume FA1 is = transmitting packet with
seq no. x; FA2 is transmitting packet with seq no. = x+2. If the MN handoff
from FA1 to FA2, packet x+1 will be lost. If the MN = handoff from FA2 to FA1
the MN will receive duplicated packet x+1.
  Buffering without synchronization won't help = here.

Regards

Hongyi


 


> -----Original Message-----
> From: Karim El-Malki (ERA) [mailto:Karim.El-Malki@era= .ericsson.se]
> Sent: Tuesday, July 24, 2001 12:03 PM
> To: 'mobile-ip@sunroof.eng.sun.com'
> Subject: RE: [mobile-ip] Handover Smoothing - = What to Do?
>
>
> > GT> The nFA has no way of know at which = point the
> > transmission was severed
> > at the oldFA...i.e.: if the bicasted = packets are buffered
> at the newFA
> > (which I assume they will so this is = useful) the TCP issues remain!
>
> Just a quick answer to this point. You're = assuming that you
> will buffer
> and that may not be needed. It's a MAY in = low-latency. If you
> do buffer,
> and have a fixed buffer/delay at nFA of the = size of the
> duration of the
> L2 handoff (when the MN is disconnected at L2 = while moving between oFA
> and nFA) then you shouldn't get duplicates. = That's a possible solution
> since the L2 handover period is normally known = in wireless systems.
>
> Rgds
> /Karim
>

------_=_NextPart_001_01C1145D.7E5BBD20-- From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 24 12:32:20 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA29600 for ; Tue, 24 Jul 2001 12:32:19 -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 KAA16606; Tue, 24 Jul 2001 10:32: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 JAA16768; Tue, 24 Jul 2001 09:32:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6OGVAX19399 for mobile-ip-dist; Tue, 24 Jul 2001 09:31:10 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6OGV3Y19390 for ; Tue, 24 Jul 2001 09:31:03 -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 JAA02055 for ; Tue, 24 Jul 2001 09:31:17 -0700 (PDT) Received: from p-mail2.cnet.fr (p-mail2.rd.francetelecom.fr [193.49.124.32]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id KAA15187 for ; Tue, 24 Jul 2001 10:31:14 -0600 (MDT) Received: by p-voyageur.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Jul 2001 18:31:03 +0200 Received: from francetelecom.com (p-dico.rd.francetelecom.fr [139.100.18.135]) by p-grive.rd.francetelecom.fr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3ZBB7VR2; Tue, 24 Jul 2001 18:31:01 +0200 Message-ID: <3B5DA28D.93F397AA@francetelecom.com> Date: Tue, 24 Jul 2001 18:30:05 +0200 From: Jean-Michel COMBES Organization: France =?iso-8859-1?Q?T=E9l=E9com?= R&D X-Mailer: Mozilla 4.75 [fr] (Windows NT 5.0; U) X-Accept-Language: fr MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com CC: Alexis , Phil Roberts , "Basavaraj Patil (NTC/Dallas)" , Abha Ahuja , Thomas Narten , Dave Johnson , Jeff Schiller , Marcus Leech , Pekka Nikander Subject: Re: [Fwd: [mobile-ip] Mobile IPv6 clarifications] References: <3B3B2E46.50E17D25@era.ericsson.se> <3B3E90F1.3F4AC384@iprg.nokia.com> <3B4171B2.7098C705@era.ericsson.se> <3B42565B.394B91D5@iprg.nokia.com> <3B448146.5112F7C9@crm.mot.com> <3B448983.B50FE7AE@iprg.nokia.com> <15193.41605.24313.336251@thomasm-u1.cisco.com> 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: X-MIME-Autoconverted: from 8bit to quoted-printable by patan.sun.com id KAA16606 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA29600 Hi, Michael Thomas a écrit : > [I know this is old, but probably worth restarting this before London] > > Charles E. Perkins writes: > > If somebody in the Security area wants to tell a different story, > > that will be just very fine with me. I'll try in a later note to > > describe my perhaps-inadequate understanding of the reasons why. > > I wish they would carry out the conversation on the [mobile-ip] > > mailing list instead of telling me in person or making statements > > in the face-to-face Mobile IP meetings. That way we could get it > > in writing and bring into the conversation the Mobile IP experts > > and IPsec experts from around the world. > > > > Furthermore, in no way does the current document split Mobile IP > > away from security. The current Binding Update is quite secure, > > as was the previous Binding Update which relied on AH. The difference > > is that the current Binding Update can have _EXACTLY_ the semantics > > that need to be specified for Mobile IPv6. Relying on AH, which in > > my opinion SHOULD still be O.K. but that's just my opinion and not > > going to matter when the IESG reviews the document, has the effect > > of leaving the Mobile IPv6 vulnerable to outside forces who may claim > > (and have claimed) that we have made inappropriate use of the protocol. > > As I recall, there were two objections to the way that -13 > was using IPsec. > > 1) There is no way to express a SPD rule (or ingress/egress filter) > for an IP packet which has multiple IP extensions. There is the > ability to filter on the normal five tuple (or subset thereof) > and that is it. -13's ability to piggyback a BU (which is an > IP extension header) with a normal, say, TCP header would not > be processed correctly by IPsec. > JMC : May you explain me why can't you piggyback BU with a TCP header ? In my point of view, the problem of IPsec granularity is on the fact that BU and BAck have no "special" next header number. Thus, any Destination Option (not only BU/BAck) will be processed by IPsec. > > If, however, a node were willing to _not_ piggyback BU as > well as instantiate an SA either solely for the purpose of matching the BU header > (where it was there alone), or with the properly formated > wildcarded IPsec ID -- typically, all traffic from a particular > IP address in transport mode only -- I believe that IPsec's > current selector mechanism works fine. Indeed, I don't see any > problem with using IPsec between the HA and MN, and with the > proper restrictions, I think that can be extended for use between > the MN and CN. See draft-thomas-mobileip-esp-bu-00.txt for a > discussion of the problem, as well as a proposal to use ESP for BU's. JMC : BTW, where is placed the DO-H@ in your proposal ? > > > 2) There was a great deal of concern about the authorization problem. > Namely, that even if a random CN were able to determine the > identity of a node requesting a BU (a dubious proposition in > itself), that doesn't give it in and of itself the _authority_ > to change the binding for a particular IP address. In order to > prevent otherwise authenticated but potentially unauthorized > entities from abuse, there must be some form of correlation > that the CN can use to determine whether a particular identity > is authorized. This is nothing new, really, and happens all of > the time with PKI's, Kerberos, etc, backed by authorization > correlation, say, in an LDAP database. However, the scale of > of the *random* CN/MN interaction posits the *worldwide* > availability of that authentication/authorization correlation > which is secure, scalable, free from reptilian corruption, > etc, etc. In other words, it's untenable, and unclear that > it would be desirable even if. > > Now, that said, I do not think that rules out use of IPsec > (with the restrictions from #1) in situations where the > authentication/authorization correlation can be kept a local > matter (eg, doesn't require IANA, or or the address registries > to become a PKI root). It would be perfectly reasonable for > an enterprise to run their own authentication/authorization > service for their own employees, and they could use IPsec > to protect the BU's after, say, IKE or KINK made a policy > decision based on the security policy database rules it > was provisioned with. Indeed, within some security domains, > authentication is in many cases sufficient to grant > authorization, and I think we should still preserve that > flexibility so long as we do *not* try to extend it to the > general case, which was what -13 was hoping to do. JMC : Totally agree. > > > In conclusion, I do think it's worthwhile to > preserve a strong crypto possibility using IPsec > for both MN/HA interaction as well as MN/CN > interaction within the scope that it was meant to > operate (ie, without global implications). The > weak authentication/authorization that is being > proposed in BAKE and my Cookies draft should be > more narrowly focused on the random MN/CN > interaction where it is not pragmatic to have a > strong crypto solution. > > Mike -- 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 From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 24 12:46:27 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA00984 for ; Tue, 24 Jul 2001 12:46:26 -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 JAA01658; Tue, 24 Jul 2001 09:46:54 -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 JAA19918; Tue, 24 Jul 2001 09:45:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6OGiV519604 for mobile-ip-dist; Tue, 24 Jul 2001 09:44:31 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6OGiQY19590 for ; Tue, 24 Jul 2001 09:44:26 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id JAA11520 for ; Tue, 24 Jul 2001 09:44:40 -0700 (PDT) Message-Id: <200107241644.JAA11520@heliopolis.eng.sun.com> Date: Tue, 24 Jul 2001 09:44:39 -0700 (PDT) From: James Kempf Subject: RE: [mobile-ip] Handover Smoothing - What to Do? To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: LkBD9UaNalcSt8zD3KJQ4g== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 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: Hi Karim, >The TCP issue is discussed with reference (EIFEL algorithm for TCP) >in the bicasting draft. > Agreed. The EIFEL algorithm should work. >Also, for the scenarios we consider in low-latency, the MN will not >get multiple copies of packets. The "second" copy gets discarded by the >non-connected FA (e.g. nFA) and an ICMP error is not transmitted. >Alternatively that second copy may be buffered. When the MN connects to >nFA it no longer receives from oFA. That's what the draft specifies and >I think that should be quite typical for a single-interfaced MN. >So that's why we went for this solution and allowed bicasting. >The TCP issues should not be involved. > The issue here isn't so much a second copy coming down the old L2 but rather that jitter on the oFA to nFA link or HA/RegReg Agent to oFA/nFA links could skew the packet delivery. This would result in a packet to nFA being delayed so that the MN got a packet on the old L2, went through handover, then got the same packet on the new L2 because it was delayed by jitter. This is easily controllable by reducing the topological distance over which bicasting occurs to reduce the probability of jitter, and reducing the latency period during which L3 service is not available to the MN. > >What do you mean by achieving smoothing at the implementation level? > I think he means L2, right George? The idea here is that if the amount of time in which L3 is unavailable to the MN is low enough the L2 protocol can handle lost packets by performing retransmit. But you would still need to bicast because otherwise the packet would not be at the new FA/AR. >I looked back at the low-latency spec and noticed an inconsistency in >that the simultaneous binding is a MAY in PRE-REG and a MUST in POST-REG. What do you mean by simultaneous binding? I think you mean bicasting. POST-REG uses FA-FA bicasting with tunnels, not HA/RegReg Agent to FA bicasting, so simultaneous bindings are not needed. >I think the aim was to keep it as a MAY. So I would consider it as optional >already. What makes me unconfortable in putting all this in another spec >is that it would defeat one of the main purposes of this document: >reduce/eliminate service disruption due to handoff. I originally argued for putting a discussion of bicasting in the appendix, but I agree that a specification of handover smoothing options and a discussion of techniques is essential for a complete specification of handover and guidance to implementors. >Or did you mean to state the problems in the FMIP drafts and have them >point to a new bicasting/buffering draft for optional implementation? I favor this approach. I would like to see a two handover smoothing draft with protocol details of both approaches, one for IPv4 and one for IPv6, and one draft discussing handover smoothing and handover performance as a guide to implementors independent of implementation. I also think the discussion of bicasting needs to distinguish between the simultaneous bindings approach and the tunneling approach. They have somewhat different properties. >In both cases, having it in or outside the FMIP drafts, we must have >these "smoothing" options. What I don't understand is what the >difference is with what we have today? You don't need to implement >bicasting or buffering if you don't need it, so what you want is already >there. > The issue is whether the two FMIP drafts say that one particular smoothing option is a MUST, or just say that smoothing MAY be necessary, and point to a separate draft where smoothing is discussed. I believe that there may be cases where smoothing may be unnecessary (though I can't think of one off the top of my head), so it makes sense to leave open the option, but I do believe it needs to be specified. jak From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 24 12:46:39 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA01045 for ; Tue, 24 Jul 2001 12:46:37 -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 JAA01721; Tue, 24 Jul 2001 09:47:02 -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 JAA19841; Tue, 24 Jul 2001 09:45:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6OGhYw19585 for mobile-ip-dist; Tue, 24 Jul 2001 09:43:34 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6OGhUY19575 for ; Tue, 24 Jul 2001 09:43:30 -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 JAA19306 for ; Tue, 24 Jul 2001 09:43:44 -0700 (PDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA26262 for ; Tue, 24 Jul 2001 10:43:42 -0600 (MDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f6OGhgN04934 for ; Tue, 24 Jul 2001 18:43:42 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Tue Jul 24 18:43:42 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Jul 2001 18:43:38 +0200 Message-ID: <795A014AF92DD21182AF0008C7A404320C52048D@esealnt117> From: "Karim El-Malki (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Handover Smoothing - What to Do? Date: Tue, 24 Jul 2001 18:43:40 +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: Comments inline. -----Original Message----- From: Hongyi Li [mailto:hyli@nortelnetworks.com] Sent: den 24 juli 2001 18:27 To: 'mobile-ip@sunroof.eng.sun.com' Subject: RE: [mobile-ip] Handover Smoothing - What to Do? Hi Karim, I think George was right in this point. For a single interface MN, if there is no synchronization between the two FAs, the MN will experience either packet loss or packet duplication depending on the direction of the handoff. Here is an example, at time t, assume FA1 is transmitting packet with seq no. x; FA2 is transmitting packet with seq no. x+2. >> Why is it transmitting x+2? It would be x-2 if FA2 (nFA) is buffering. >> If so my suggestion was to set the buffer to the L2 handoff duration. If the MN handoff from FA1 to FA2, packet x+1 will be lost. If the MN handoff from FA2 to FA1 the MN will receive duplicated packet x+1. Buffering without synchronization won't help here. >> does it take zero time to perform a L2 handoff in this example? >> If it does then I would expect FA2 to transmit x, while FA1 transmits x. >> Then you don't have packet loss or duplication. > -----Original Message----- > From: Karim El-Malki (ERA) [mailto:Karim.El-Malki@era.ericsson.se] > Sent: Tuesday, July 24, 2001 12:03 PM > To: 'mobile-ip@sunroof.eng.sun.com' > Subject: RE: [mobile-ip] Handover Smoothing - What to Do? > > > > GT> The nFA has no way of know at which point the > > transmission was severed > > at the oldFA...i.e.: if the bicasted packets are buffered > at the newFA > > (which I assume they will so this is useful) the TCP issues remain! > > Just a quick answer to this point. You're assuming that you > will buffer > and that may not be needed. It's a MAY in low-latency. If you > do buffer, > and have a fixed buffer/delay at nFA of the size of the > duration of the > L2 handoff (when the MN is disconnected at L2 while moving between oFA > and nFA) then you shouldn't get duplicates. That's a possible solution > since the L2 handover period is normally known in wireless systems. > > Rgds > /Karim > From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 24 13:05:09 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA02516 for ; Tue, 24 Jul 2001 13:05: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 LAA15832; Tue, 24 Jul 2001 11:05:44 -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 KAA10187; Tue, 24 Jul 2001 10:05:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6OH44719768 for mobile-ip-dist; Tue, 24 Jul 2001 10:04:04 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6OH40Y19761 for ; Tue, 24 Jul 2001 10:04:00 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id KAA12764 for ; Tue, 24 Jul 2001 10:04:15 -0700 (PDT) Message-Id: <200107241704.KAA12764@heliopolis.eng.sun.com> Date: Tue, 24 Jul 2001 10:04:14 -0700 (PDT) From: James Kempf Subject: RE: [mobile-ip] Handover Smoothing - What to Do? To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: PJcxdr3dJSL30vWPWbN+5w== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 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: Hi George, >GT> The nFA has no way of know at which point the transmission was severed >at the oldFA...i.e.: if the bicasted packets are buffered at the newFA >(which I assume they will so this is useful) the TCP issues remain! > I don't understand why this should be a problem. If the nFA has a sliding window buffer that holds only enough packets to cover a high probability, say 95%, of the L2 handover time, then the only problem could be if jitter caused a packet to show up in the buffer after it was delivered to the MN through the old L2. The probability of that occuring shouldn't be very high if the wired network is properly engineered to reduce jitter (overprovisioning, etc.). >GT> I mean that routers can buffer without the involvement of the MN i.e.: >without the need for a protocol based negotiation. > Oh, OK, strike my previous comment about L2 smoothing. I agree that buffering can be done by the routers, and I agree that the MN should not be involved. > >GT> I also stated that "smoothing" options are useful and are needed so no >disagreement there. I am only arguing that it is a separable piece of work. >- multiple ways of smoothing are possible for the same FMIP mechanism >- there is a discussion to be made about buffering based methods vs >bicasting based methods. I think both have merit but recommendation of one >of the two would be nice interoperability/simplicity purposes >- smoothing work is not as mature are FMIP, has not been discussed at the >same detail which also points to the fact that are separable. > >GT> Karim, my main argument in this thread is not against bicasting although >I have my own concerns which you are very well aware off. The question in >this thread is about separating "smooth" from "fast" specs and I think I am >not the only one who things this may be a good idea. It makes specs thinner >if nothing else and I, at least, believe that will make FMIP specs go >through the standards process faster... > > The issue is whether the FMIP work is completely useless without smoothing, or whether smoothing is so intertwined with the FMIP work that it is impossible to put it into a separate spec. I think the fact that the FMIPv6 draft managed to successfully disentangle them argues that the smoothing work can be separated out from a design perspective. Whether or not FMIP is useless without smoothing from an operational or implementation perspective is something that can only be determined by experiment. As was laid out in the BETH appendex on smoothing, I think there is a place for both buffering and bicasting, but not in the way that proponents of both believe. Given that, it makes sense to me to separate out smoothing and frame that as a separate issue, for purposes of design discussion and debate, and as a way to advance the FMIP specs. We seem to have a certain amount of concensus on the FMIP specs, in the interests of moving them forward, it would probably be a better idea to separate out smoothing. I personally believe that smoothing is absolutely required for proper handover, but I think we need to approach this from a practical standpoint of how can we conclude the discussion on what we agree so we can advance it to the IESG, rather than let it linger as has, unfortunately, been the case with so many MIP drafts. jak From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 24 13:12:19 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA03010 for ; Tue, 24 Jul 2001 13:12:18 -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 KAA14399; Tue, 24 Jul 2001 10:11:02 -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 KAA11578; Tue, 24 Jul 2001 10:10:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6OH9BN19838 for mobile-ip-dist; Tue, 24 Jul 2001 10:09:12 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6OH98Y19830 for ; Tue, 24 Jul 2001 10:09:08 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id KAA13051 for ; Tue, 24 Jul 2001 10:09:22 -0700 (PDT) Message-Id: <200107241709.KAA13051@heliopolis.eng.sun.com> Date: Tue, 24 Jul 2001 10:09:22 -0700 (PDT) From: James Kempf Subject: Re: [mobile-ip] WG feedback on bicasting To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: +BVOkktZxQrRLIP55WKqnw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 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: Wolfgang, Most of these problems go away if bicasting is done between oFA/oAR and nFA/nAR. The exchange of L3 handover messages across the wired backbone (HI/HACK) is a coarse approximation of when the link changes. The oAR continues to send packets down the old L2 until the L2 disappears. Presumably it can detect this somehow. It starts bicasting to nAR when it sends/receives a HACK. This can be fine tuned considerably if appropriate sequencing information is available from L2 (see draft-manyfolks-mobilereq-l2-00.txt for the kinds of sequencing information that can help). jak >Date: Tue, 24 Jul 2001 17:43:40 +0200 >From: Wolfgang Schoenfeld >To: mobile-ip@sunroof.eng.sun.com >Subject: Re: [mobile-ip] WG feedback on bicasting > >Hello Karim, > >may I just restate my considerations >which had - I admid - a few flaws? > >Assume again that a stream of packets >is running from CN to MN via oFA (or oAR or ...). >When MN moves, some redirection of the stream may be necessary >(which is done by registration at the HA). >Which events can trigger that? > >The emergence of a new link between MN and some nFA is a good candidate >since the stream can use it (as long as it is stable). >And this is what MIP does. >However, to propagate the event to HA takes some time >during which packets keep on running to oFA. >And after redirection is done, >packets take some time to reach MN. >Hence, the round-trip time from MN to HA >determines handoff latency time. > >Obviously, it can be reduced >by bringing HA functionality closer to MN - >which is the purpose of hierarchies. >What else can be done? >Nothing if we consider layer 3 alone >since this would mean to by-pass registration message or data packets. >In particular, bicast/multicast will not help. > >Another (the only?) way is guessing the emergence of a new link, >i.e. taking outer "oracles" like layer 2 events, statistics etc. into account. >In this case, bicasting can indeed make sense >if the guess does not give a unique answer: >Just multicast to all nodes which the guess predicts. >(Broadcast would result from the most vague guess.) >This increases the probability that all packets reach MN. > >Note however that multicast is concerned only with vagueness of guesses - >if they are precise, multicasting does have not have any effect. >Hence, fast handover without bicasting >(your original question) does make sense. > >I'm not sure whether the above is now "gap-free". Hence, please comment. > >Wolfgang > >PS: >Concerning James' "Handover Smoothing - What to Do?" >which I appreciate very much - >wouldn't it be reasonable to also have, for each of the proposals, >some analysis of > >- Which cases are handled by the proposed architecture / functionality? >- In these cases, what is the improvement achieved? >- How often do these cases happen? > > >"Karim El-Malki (ERA)" schrieb: >> >> Hello Wolfgang >> >> > I'm not able to comment on mobileip WG issues, >> > but I believe that the role of bicasting for handover >> > is not yet fully understood, both in MIPv4 and MIPv6. >> > Considerations like the following for MIPv4 >> > might help to decide. >> >> The aim of the draft is exactly to address the role >> of bicasting in fast handovers (for MIPv6) and address >> issues involved. >> >> > >> > Obviously, bicasting makes sense only if MN is able >> > to maintain more than one link simultaneously, >> > say to oFA and nFA. >> >> That's not what the draft says and actually quite the >> opposite. >> >> > Now assume that this is the case >> > and consider handover without bicasting. >> > Handover involves, among others, these events: >> > >> > (A) MN detects a link to nFA and issues a BU message to HA. >> > (B) HA receives BU and updates binding of MN. >> > (C) MN looses the link to oFA. >> > >> > How is a stream of packets from some CN to MN affected by handover? >> > (A) does not affect the stream, but (B) does: >> > Before (B), packets travel to oFA, >> > and after (B), they travel to nFA >> > (assume that HA buffers during (B)). >> > Packets passing HA after (B) will reach MN, >> > but what about those >> > which pass HA before (B) and after (A)? >> > Let us call them "critical" packets. >> >> The bicasting draft applies to fast handover v6 but your >> example is different. You're also considering MIPv4 but this >> draft is on MIPv6... >> So I guess your comments are not on the draft itself but on >> generic bicasting? >> If you follow the fast handover v6 concepts then A & B would >> occur some time in advance of when C occurs. We assume this >> anticipation is enough such that the "critical" packets reach >> the MN at its old link. That's also a good reason to use >> a close-by or local HA like the MAP from HMIPv6. In fast >> handover v6 the anticipated F-BU is sent to the oAR. So this >> should not involve loss of "critical" packets. >> >> > If (C) happens only after all critical packets >> > have passed the link from oFA to MN, >> > then there is no packet loss at all. >> >> That's why the handoff is anticipated. >> >> > Now, what could bicasting improve? >> > Non-critical packets need not be bicasted - >> > they will reach MN anyhow. >> >> That's not necessarily true. The l2 handoff may >> occur at any time relative to the MN's BU. >> What if the MN hands-off (L2) to the new AR a certain >> time after having sent the Fast-BU? Since the MN has >> not moved yet the packets sent to nAR during this >> time interval get lost. Bicasting instead gives us a >> way to decouple l2 and l3 handoffs: the MN can communicate >> no matter when the L2 handoff occurs. This is >> discussed in the draft. >> >> > To summarize, >> > simultaneous use of two links to MN - if they exist - >> > is somehow "built-in" and can happen >> > even if simultaneous binding is switched off. >> >> In fact bicasting is probably more useful on MNs with a >> single link. >> >> > Switching it on will have no effect on packet loss!!! >> > Bicasting does not make sense. >> > >> > It does make sense only if HA is able to predict (A). >> > But move prediction is, as far as I understand, >> > not an issue for MIPv4 or for MIPv6. >> >> Is it more clear now? >> You were assuming things that are neither according to >> fast handover v6 draft nor the bicasting draft which is >> why you were coming to these conclusions. >> >> Regards >> /Karim > >-- >Prof. Dr. Wolfgang Schoenfeld, Fraunhofer IPSI, Dolivostr. 15, D-64293 Darmstadt >Office: +49-6151-869-865 FAX: -6847 Mobile: +49-174-7093455 From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 24 13:15:30 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA03375 for ; Tue, 24 Jul 2001 13:15:29 -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 KAA16814; Tue, 24 Jul 2001 10:15: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 KAA12321; Tue, 24 Jul 2001 10:13:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6OHBwX19875 for mobile-ip-dist; Tue, 24 Jul 2001 10:11:58 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6OHBsY19868 for ; Tue, 24 Jul 2001 10:11:54 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id KAA13253 for ; Tue, 24 Jul 2001 10:12:09 -0700 (PDT) Message-Id: <200107241712.KAA13253@heliopolis.eng.sun.com> Date: Tue, 24 Jul 2001 10:12:08 -0700 (PDT) From: James Kempf Subject: RE: [mobile-ip] Handover Smoothing - What to Do? To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: C+4BUT6t9I/AGfRr4frnsQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 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: Hi Karim/George, >Just a quick answer to this point. You're assuming that you will buffer >and that may not be needed. It's a MAY in low-latency. If you do buffer, >and have a fixed buffer/delay at nFA of the size of the duration of the >L2 handoff (when the MN is disconnected at L2 while moving between oFA >and nFA) then you shouldn't get duplicates. That's a possible solution >since the L2 handover period is normally known in wireless systems. > Yes, that's right. If the latency is low enough, you can simply drop any packets that come through. For real time traffic this will have no effect if the number of dropped packets is low enough. For reliable protocols, such as TCP, it will cause retransmit, which may or may not be a problem. jak From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 24 13:23:41 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA03994 for ; Tue, 24 Jul 2001 13:23:40 -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 KAA22027; Tue, 24 Jul 2001 10:23: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 KAA14812; Tue, 24 Jul 2001 10:22:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6OHKtb19975 for mobile-ip-dist; Tue, 24 Jul 2001 10:20:55 -0700 (PDT) Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6OHKrY19967 for ; Tue, 24 Jul 2001 10:20: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 NAA19836 for ; Tue, 24 Jul 2001 13:21:07 -0400 (EDT) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id NAA07976 for mobile-ip@sunroof.eng.sun.com; Tue, 24 Jul 2001 13:21:31 -0400 (EDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6OH82Y19810 for ; Tue, 24 Jul 2001 10:08:02 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA26397 for ; Tue, 24 Jul 2001 10:08:16 -0700 (PDT) Received: from mail.ee.gatech.edu (mail.ee.gatech.edu [130.207.225.105]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAB24403 for ; Tue, 24 Jul 2001 10:08:16 -0700 (PDT) Received: from ece.gatech.edu (seiya.ece.gatech.edu [130.207.225.101]) by mail.ee.gatech.edu (8.11.3/8.11.0) with SMTP id f6OH8FA02448 for ; Tue, 24 Jul 2001 13:08:15 -0400 (EDT) From: Conference 123101 Received: from 199.77.145.57 (SquirrelMail authenticated user mobilecf) by secure2.ece.gatech.edu with HTTP; Tue, 24 Jul 2001 13:08:15 -0400 (EDT) Message-ID: <46570.199.77.145.57.995994495.squirrel@secure2.ece.gatech.edu> Date: Tue, 24 Jul 2001 13:08:15 -0400 (EDT) Subject: [mobile-ip] IEEE WCNC2002 (Deadline August 1) To: X-Mailer: SquirrelMail (version 1.1.2) 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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit ------------------------------------------------------------------- CALL FOR PAPERS IEEE Wireless Communications & Networking Conference 2002 17 - 21 March 2002 ------------------------------------------------------------------- You are invited to submit original papers addressing topics in all areas of wireless communication systems and networks. Potential topics include, but are not limited to, the technical subject categories listed below: TECHNICAL SUBJECT CATEGORIES Coding and modulation Mobile agents Multiple access methods Satellite-based systems Broadband wireless networks 3G/4G wireless systems/networks Wireless multimedia Wireless IP and IP-on-Air Wireless mobile ATM (wmATM) QoS in wireless networks Signal processing techniques Low power algorithms/protocols Network/transport protocols Antennas and RF subsystems Wireless Ad Hoc networks Heterogeneous wireless networks Personal area networking Radio resource management Mobility & location management Software defined radio Nomadic & mobile computing Global communications Mobile security and privacy Active wireless networking Wireless sensor networks Mobile Internet and WAP Wireless home networks SUBMISSION GUIDELINES --------------------- All authors must register and submit their papers electronically at: http://www.expotrack.com/wcnc/submit.asp You can also link to the paper submission system from the main event website: http://www.wcnc.org/2002. DO NOT MAIL OR FAX YOUR PAPER: IT MUST BE SUBMITTED ONLINE. Regular Technical Sessions -------------------------- Papers should be in English, with no more than 3,000 words, and submitted via on-line to: www.wcnc.org/2002 If you have problems with on-line submission, please e-mail: C. K. Toh cktoh@ece.gatech.edu Business Application Sessions ----------------------------- Extended summary of papers, 2-3 pages in PDF/PS/Word, should be submitted by e-mail to: Willie W. Lu wwlu@ieee.org Tutorial Sessions ----------------- Extended summary of proposals, 2~3 pages in PDF/PS/Word, should be submitted by e-mail to: Li Fung Chang lifung@ieee.org NOTE: Best papers will also be selected for consideration in IEEE leading journals. Authors of selected papers will be informed by the TPC chairs. IMPORTANT DATES --------------- Paper Submission Due: 1 August 2001 Acceptance Notification: 1 November 2001 Camera-Ready Paper Due: 15 December 2001 ORGANISATION ------------ General Chair: Dick Lynch, Verizon Wireless, USA Vice Chair: Gerry Flynn, Verizon Wireless, USA Administrative Chair: Andrea Linsky, Verizon Wireless, USA Finance Chair: Francis O'Brien, Lucent Technologies, USA Tech Committee Chair: Larry Milstein, UCSD, USA Tech Committee Vice Chairs: Willie Lu, Siemens, US C.K. Toh, GeorgiaTech, US Tutorial Vice Chairs: Li Fung Chang, Mobilinktel, Len Cimini, AT&T Executive Panel Chair: Mehmet Unsoy, BT, UK Technical Program Committee Members: ------------------------------------ Saleh Aidarous, NEC, USA Hamid Aghvami, KCL, UK Bart Arroyo, EC-DG13, Belgium Yeheskel Bar-Ness, NJIT, USA Robert Berezdivin, Raytheon, USA Vijay Bhargava, Victoria University, Canada Qi Bi, Lucent, USA Chang Wen Chan, Univ. of Missouri, USA K C Chua, NUS, Singapore K-C Chen, NTU, Taiwan Justin Chuang, AT&T, USA Yuguang Fang, University of Florida, USA Federico Tosco, CSELT, Italy Gerhard Fettweis, T. Univ. Dresden, Germany Cengiz Evci, Alcatel, France Jerry Gibson, SMU, USA Shinichiro Haruyama, Keio University, Japan Martin Haardt, Siemens AG, Germany Zygmunt Haas, Cornell, USA Russel Hsing, Telcordia, USA James Kempf, SUN, USA Ryuji Kohno, Yokohama University, Japan Sastri Kota, Loral Space, USA Jason Lin, NTCU, Taiwan Kin Leung, AT&T, USA Victor Leung, UBC, Canada Paul Lemson, Cellestra, USA Khaled Ben Letaiff, HKUST, China Victor Li, Hongkong University, China Greg Pollini, Telcordia, USA Ramjee Prasad, Aalborg University, Denmark Yunsang Park, Hughes Networks, USA Xuemin Shen, Waterloo University, Canada Elvino Sousa, Toronto University, Canada Reinaldo Valenzuela, Lucent, USA Bernhard Walke, RWTH, Germany Adam Wolisz, Tech. Univ. of Berlin, Germany Steering Committee Chair ------------------------ Chih-Lin I, AT&T, USA WCNC - The World's Most Authoritative Conference in Wireless Communications and Networks ------------------------------------------------------------------ From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 24 13:39:01 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05177 for ; Tue, 24 Jul 2001 13:39:00 -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 KAA00389; Tue, 24 Jul 2001 10:38:21 -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 KAA16619; Tue, 24 Jul 2001 10:29:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6OHSIs20083 for mobile-ip-dist; Tue, 24 Jul 2001 10:28:18 -0700 (PDT) Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6OHSEY20076 for ; Tue, 24 Jul 2001 10:28:14 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA21134; Tue, 24 Jul 2001 13:28:23 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f6OHRlS08219; Tue, 24 Jul 2001 13:27:47 -0400 (EDT) Message-Id: <200107241727.f6OHRlS08219@thunk.east.sun.com> From: Bill Sommerfeld To: mobile-ip@sunroof.eng.sun.com cc: Alexis , Phil Roberts , "Basavaraj Patil (NTC/Dallas)" , Abha Ahuja , Thomas Narten , Dave Johnson , Jeff Schiller , Marcus Leech , Pekka Nikander Subject: Re: [Fwd: [mobile-ip] Mobile IPv6 clarifications] In-reply-to: Your message of "Tue, 24 Jul 2001 18:30:05 +0200." <3B5DA28D.93F397AA@francetelecom.com> Date: Tue, 24 Jul 2001 13:27:47 -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: In my point of view, the problem of IPsec granularity is on the fact that BU and BAck have no "special" next header number. Thus, any Destination Option (not only BU/BAck) will be processed by IPsec. Not quite; we could fix IPsec implementations to recognize BU's and treat them separately if there was no piggybacking going on. The deeper problem here is that AH/ESP protect the entire packet, and mobile IPv6 currently only wants to protect the binding update. This leads to ambiguity on the receiver in terms of knowing what policy to apply to a new connection. If I receive an AH-protected packet containing a binding update and a TCP SYN, a receiver cannot know for sure whether the sender intended the AH protection to apply just to the binding update, or also to subsequent packets that are part of the TCP connection. While I thought this option had been beaten to death, if folks still want to use IPsec to protect MN/CN traffic, here are two possible ways to deal: 1) disallow piggybacking, and always send binding updates separately from user traffic. 2) since you've already paid the cost of setting up the IPsec security associations, you might as well just keep using them -- once a binding is established, *all* traffic between the MN and the CN should be protected the same way. Note that even with this issue resolved, you still have to deal with the PKI/authentication/etc. issues involved with SA setup; if anything, this is a much harder problem.. - Bill From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 24 13:47:37 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05843 for ; Tue, 24 Jul 2001 13:47:36 -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 KAA05615; Tue, 24 Jul 2001 10:47: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 KAA18939; Tue, 24 Jul 2001 10:38:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6OHagP20146 for mobile-ip-dist; Tue, 24 Jul 2001 10:36:42 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6OHacY20139 for ; Tue, 24 Jul 2001 10:36:38 -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 KAA08722 for ; Tue, 24 Jul 2001 10:36:52 -0700 (PDT) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA07395 for ; Tue, 24 Jul 2001 11:38:16 -0600 (MDT) Received: by megisto-sql1.megisto.com with Internet Mail Service (5.5.2650.21) id ; Tue, 24 Jul 2001 13:35:19 -0400 Message-ID: From: Phil Roberts To: "'sommerfeld@east.sun.com'" , mobile-ip@sunroof.eng.sun.com Cc: Alexis , Phil Roberts , "Basavaraj Patil (NTC/Dallas)" , Abha Ahuja , Thomas Narten , Dave Johnson , Jeff Schiller , Marcus Leech , Pekka Nikander Subject: RE: [Fwd: [mobile-ip] Mobile IPv6 clarifications] Date: Tue, 24 Jul 2001 13:35:18 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) 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: > Note that even with this issue resolved, you still have to deal with > the PKI/authentication/etc. issues involved with SA setup; if > anything, this is a much harder problem.. > > - Bill > Right. And the perspective has been, I believe, to solve the harder problem before determining how the protocol supports it. From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 24 13:51:43 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA06204 for ; Tue, 24 Jul 2001 13:51: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 LAA27222; Tue, 24 Jul 2001 11:52:17 -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 KAA23006; Tue, 24 Jul 2001 10:51:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6OHobB20282 for mobile-ip-dist; Tue, 24 Jul 2001 10:50:37 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6OHoXY20275 for ; Tue, 24 Jul 2001 10:50:34 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA06069 for ; Tue, 24 Jul 2001 10:50:48 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA15360 for ; Tue, 24 Jul 2001 10:50:48 -0700 (PDT) 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 f6OHolg08652 for ; Tue, 24 Jul 2001 10:50: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 AAR23633; Tue, 24 Jul 2001 10:50:46 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA10492; Tue, 24 Jul 2001 10:50:45 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15197.46453.112546.57599@thomasm-u1.cisco.com> Date: Tue, 24 Jul 2001 10:50:45 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Handover Smoothing - What to Do? In-Reply-To: <200107241704.KAA12764@heliopolis.eng.sun.com> References: <200107241704.KAA12764@heliopolis.eng.sun.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 James Kempf writes: > The issue is whether the FMIP work is completely useless without > smoothing, or whether smoothing is so intertwined with the FMIP > work that it is impossible to put it into a separate spec. I think > the fact that the FMIPv6 draft managed to successfully disentangle > them argues that the smoothing work can be separated out from > a design perspective. Whether or not FMIP is useless without > smoothing from an operational or implementation perspective > is something that can only be determined by experiment. I'd say that it's not useless: if you have two interfaces, FMIP alone is probably sufficient since you can do a make before break while listening on both for some period of time. It might be pointed out that you could do that without the FMIP AR, but latencies back to the CN/HA may require a more localized solution to achieve a reasonable handoff. Mike From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 24 14:00:58 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07063 for ; Tue, 24 Jul 2001 14:00:57 -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 LAA13754; Tue, 24 Jul 2001 11:01: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 KAA24774; Tue, 24 Jul 2001 10:58:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6OHutr20350 for mobile-ip-dist; Tue, 24 Jul 2001 10:56:55 -0700 (PDT) Received: from locked.eng.sun.com (locked [129.146.85.189]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6OHupY20343 for ; Tue, 24 Jul 2001 10:56:51 -0700 (PDT) Received: (from mohanp@localhost) by locked.eng.sun.com (8.11.2+Sun/8.11.2) id f6OHtdK25750; Tue, 24 Jul 2001 10:55:39 -0700 (PDT) From: Mohan Parthasarathy Message-Id: <200107241755.f6OHtdK25750@locked.eng.sun.com> Subject: Re: [Fwd: [mobile-ip] Mobile IPv6 clarifications] In-Reply-To: <200107241727.f6OHRlS08219@thunk.east.sun.com> from Bill Sommerfeld at "Jul 24, 2001 01:27:47 pm" To: mobile-ip@sunroof.eng.sun.com Date: Tue, 24 Jul 2001 10:55:38 -0700 (PDT) CC: Alexis , Phil Roberts , "Basavaraj Patil (NTC/Dallas)" , Abha Ahuja , Thomas Narten , Dave Johnson , Jeff Schiller , Marcus Leech , Pekka Nikander X-Mailer: ELM [version 2.4ME+ PL66 (25)] 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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > Not quite; we could fix IPsec implementations to recognize BU's and > treat them separately if there was no piggybacking going on. > > The deeper problem here is that AH/ESP protect the entire packet, and > mobile IPv6 currently only wants to protect the binding update. > When piggybacked, the intention was to protect the whole packet and not just the Binding Update. The issue was then how to piggyback the binding update on a clear TCP connection. Because IPsec policy would not allow this. I think you really meant to say the entire flow above i guess. > This leads to ambiguity on the receiver in terms of knowing what > policy to apply to a new connection. > > If I receive an AH-protected packet containing a binding update and a > TCP SYN, a receiver cannot know for sure whether the sender intended > the AH protection to apply just to the binding update, or also to > subsequent packets that are part of the TCP connection. > > While I thought this option had been beaten to death, if folks still > want to use IPsec to protect MN/CN traffic, here are two possible ways > to deal: > > 1) disallow piggybacking, and always send binding updates separately > from user traffic. > This is the easiest. > 2) since you've already paid the cost of setting up the IPsec > security associations, you might as well just keep using them -- once > a binding is established, *all* traffic between the MN and the CN > should be protected the same way. > > Note that even with this issue resolved, you still have to deal with > the PKI/authentication/etc. issues involved with SA setup; if > anything, this is a much harder problem.. > It depends on how secure a solution you want. The requirements state that : It SHOULD be extremely difficult for an attacker "off-axis" i.e. an attacker that cannot snoop packets on either of the three legs of the paths, to divert traffic. This difficulty should be on the order of correctly guessing a very large random number. Any approach MUST consider the scalability issues and computational capabilities of the entities in a mobile environment (MN, HA, CN). The expense associated with generating keys or public key operations or Diffie Hellman computations SHOULD be accounted for -mohan > - Bill From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 24 14:08:35 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07718 for ; Tue, 24 Jul 2001 14:08: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 MAA11222; Tue, 24 Jul 2001 12:09: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 LAA27126; Tue, 24 Jul 2001 11:08:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6OI7Tm20435 for mobile-ip-dist; Tue, 24 Jul 2001 11:07:29 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6OI7PY20428 for ; Tue, 24 Jul 2001 11:07:26 -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 LAA16786 for ; Tue, 24 Jul 2001 11:07:40 -0700 (PDT) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA25615 for ; Tue, 24 Jul 2001 12:09:03 -0600 (MDT) Received: by megisto-sql1.megisto.com with Internet Mail Service (5.5.2650.21) id ; Tue, 24 Jul 2001 14:06:12 -0400 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] agenda Date: Tue, 24 Jul 2001 14:06:11 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) 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: Folks, here's what we'd like to ship. The only change since the last version is a 10 minute slot for "handover smoothing." This is based on the discussion generated from the draft on simultaneous bindings. I put myself as the placeholder presenter for this but we'll determine how to handle this as the discussion unfolds. Phil and Raj -------------------------------- Agenda Phil 5 minutes Update on WG docs Phil 10 minutes This slot is for last minute updates. Here is the current status of docs that are in last call or submitted to Abha. draft-ietf-mobileip-mier-07.txt (submitted) draft-ietf-mobileip-gnaie-04.txt (submitted) draft-ietf-mobileip-3g wireless-ext-06.txt (being updated based on IESG feedback) draft-ietf-mobileip-rfc2002-bis-06.txt (being updated based on IESG feedback) draft-ietf-mobileip-gen-key-00.txt (wg last call expires Friday 7/20 hopefully submitted) draft-ietf-mobileip-aaa-key-07.txt (to be submitted Friday 7/20) draft-ietf-mobileip-qos-requirements-00.txt (wg last call expires 7/25) draft-ietf-mobileip-reg-tunnel-04.txt (being updated) draft-ietf-mobileip-optim-10.txt (past wg last call, sitting on it until MIP v6 issues resolved) Moving MIPv4 to draft standard Charlie 10 minutes Mobile IP v6 security update ? draft-team-mobileip-mipv6-sec-reqts-00.txt 15 minutes Mobile IP v6 other changes in -14 Charlie 5 minutes draft-ietf-mobileip-ipv6-14.txt v4 Low Latency Handover Karim 5 minutes draft-ietf-mobileip-lowlatency-handoffs-v4-01.txt Is there anyone who can share implementation experiences? Is this doc ready for last call? v6 Fast Handover draft-ietf-mobileip-fast-mipv6-01.txt BETH addition? James 10 minutes draft-kempf-beth-ipv6-01.txt Implementation experience report Rajeev Koodli 10 minutes Handover Smoothing Phil 10 minutes Mobile Network Support Thierry Ernst 15 minutes Mobile IP Component Redundancy Gopal 10 minutes LMM Requirements Carl Williams 15 minutes (draft-ietf-mobileip-lmm-requirements-00.txt) Issues from the list Raj 15 minutes From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 24 14:43:15 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10413 for ; Tue, 24 Jul 2001 14:43:14 -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 MAA11313; Tue, 24 Jul 2001 12:43:55 -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 LAA20259; Tue, 24 Jul 2001 11:43:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6OIfjB20651 for mobile-ip-dist; Tue, 24 Jul 2001 11:41:45 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6OIffY20644 for ; Tue, 24 Jul 2001 11:41:41 -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 LAA19789 for ; Tue, 24 Jul 2001 11:41:54 -0700 (PDT) Received: from RRMAIL01.RADIOROUTER_NT ([63.103.94.23]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA13149 for ; Tue, 24 Jul 2001 12:43:16 -0600 (MDT) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Jul 2001 14:41:52 -0400 Message-ID: <8C92E23A3E87FB479988285F9E22BE460546A8@ftmail> From: George Tsirtsis To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Handover Smoothing - What to Do? Date: Tue, 24 Jul 2001 14:41: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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: James, I agree with Mike regarding make before break but you also agreed with me in earlier e-mail that smoothing can be done by an implementation buffering without protocol/mobile's involvement...so FMIP does not need smoothing specificiations to become useful even in break before make. George -----Original Message----- From: Michael Thomas [mailto:mat@cisco.com] Sent: Tuesday, July 24, 2001 6:51 PM To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Handover Smoothing - What to Do? James Kempf writes: > The issue is whether the FMIP work is completely useless without > smoothing, or whether smoothing is so intertwined with the FMIP > work that it is impossible to put it into a separate spec. I think > the fact that the FMIPv6 draft managed to successfully disentangle > them argues that the smoothing work can be separated out from > a design perspective. Whether or not FMIP is useless without > smoothing from an operational or implementation perspective > is something that can only be determined by experiment. I'd say that it's not useless: if you have two interfaces, FMIP alone is probably sufficient since you can do a make before break while listening on both for some period of time. It might be pointed out that you could do that without the FMIP AR, but latencies back to the CN/HA may require a more localized solution to achieve a reasonable handoff. Mike From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 24 14:43:16 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10414 for ; Tue, 24 Jul 2001 14:43:15 -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 LAA07763; Tue, 24 Jul 2001 11:43:54 -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 LAA20203; Tue, 24 Jul 2001 11:43:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6OIfqh20666 for mobile-ip-dist; Tue, 24 Jul 2001 11:41:52 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6OIfmY20653 for ; Tue, 24 Jul 2001 11: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 LAA19858 for ; Tue, 24 Jul 2001 11:42:01 -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 MAA13193 for ; Tue, 24 Jul 2001 12:43:22 -0600 (MDT) 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 f6OIgCT27792 for ; Tue, 24 Jul 2001 11:42:12 -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 AAR25554; Tue, 24 Jul 2001 11:41:58 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA10496; Tue, 24 Jul 2001 11:41:58 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15197.49525.882549.511340@thomasm-u1.cisco.com> Date: Tue, 24 Jul 2001 11:41:57 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Security requirements clarification 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 One thing that I think we need to clarify in the security requirements draft is the relationship of strong authentication crypto based security to this draft. The draft rightly rejects the notion of a global PKI-like scheme, but this leaves the impression that _any_ PKI/strong crypto based solution doesn't meet requirements. Or at least it leaves that taste in my mouth. What would be better is lay down requirements for a strong crypto based solution as well as a weaker version which doesn't run afoul of the global PKI problem. Something like: 1) The security solution MUST provide a method to secure binding messages using conventional strong cryptographic authentication which can leverage existing authentication infrastructures. This aspect of the solution MUST provide message integrity and privacy. The solution MUST apply to both the MN/HA and MN/CN communication. 2) The security solution MUST NOT require that the authentication infrastructure be extended to global proportions. As such, a solution which doesn't rely on strong authentication is acceptible so long as the difficulty is on the order of guessing a very large random number (ie requirement #1 in 7.2) [perhaps controversial:] This method MUST NOT be used for MN/HA communication. Mike From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 24 15:45:08 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA15049 for ; Tue, 24 Jul 2001 15:45:08 -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 MAA10149; Tue, 24 Jul 2001 12:45: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 MAA03183; Tue, 24 Jul 2001 12:42:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6OJboD20934 for mobile-ip-dist; Tue, 24 Jul 2001 12:37:50 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6OJbkY20927 for ; Tue, 24 Jul 2001 12:37:47 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA02570 for ; Tue, 24 Jul 2001 12:37:59 -0700 (PDT) Received: from zcars0m9.ca.nortel.com ([47.129.242.157]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA23062 for ; Tue, 24 Jul 2001 12:37:57 -0700 (PDT) Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f6OJbV912222 for ; Tue, 24 Jul 2001 15:37:31 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.ca.nortel.com; Tue, 24 Jul 2001 15:37:28 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Jul 2001 15:37:29 -0400 Message-ID: From: "Hongyi Li" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Handover Smoothing - What to Do? Date: Tue, 24 Jul 2001 15:37:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C11478.11F2F250" X-Orig: 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_01C11478.11F2F250 Content-Type: text/plain; charset="iso-8859-1" See my comments inline -Hongyi > -----Original Message----- > From: Karim El-Malki (ERA) [mailto:Karim.El-Malki@era.ericsson.se] > Sent: Tuesday, July 24, 2001 12:44 PM > To: 'mobile-ip@sunroof.eng.sun.com' > Subject: RE: [mobile-ip] Handover Smoothing - What to Do? > > > Comments inline. > > -----Original Message----- > From: Hongyi Li [mailto:hyli@nortelnetworks.com] > Sent: den 24 juli 2001 18:27 > To: 'mobile-ip@sunroof.eng.sun.com' > Subject: RE: [mobile-ip] Handover Smoothing - What to Do? > > > Hi Karim, > I think George was right in this point. > For a single interface MN, if there is no synchronization > between the > two FAs, the MN will experience either packet loss or packet > duplication > depending on the direction of the handoff. > Here is an example, at time t, assume FA1 is transmitting > packet with > seq no. x; FA2 is transmitting packet with seq no. x+2. > > >> Why is it transmitting x+2? It would be x-2 if FA2 (nFA) > is buffering. > >> If so my suggestion was to set the buffer to the L2 > handoff duration. [hyli] this is just to show the different transmission speeds on the two bicasting legs. The transmission speed depends on the traffic conditions on different legs that include radio links as well. I don't think we can over provisioning radio links in near future. Buffering at the new FA still doesn't solve the problem. This is because the transmission speed at old FA still matters. Let's assume for example bicasting started with packet of seq no. x. If the old FA is transmitting x-2 at handoff (due to poor radio link), packet x-1 will be lost; if the old AR is transmitting x+2 at handoff (good radio link), the MN has packet duplication. > > If the MN handoff > from FA1 to FA2, packet x+1 will be lost. If the MN handoff > from FA2 to FA1 > the MN will receive duplicated packet x+1. > Buffering without synchronization won't help here. > > >> does it take zero time to perform a L2 handoff in this example? > >> If it does then I would expect FA2 to transmit x, while > FA1 transmits x. > >> Then you don't have packet loss or duplication. [hyli] Whether handoff takes zero time or dt is not important here. If a system wants both FAs transmit x at the same time, good synchronization mechanism is needed. 2G CDMA systems implement this synchronization in soft handoff. However, this synchronization reduces the overall throughput of the CDMA systems. You may find some HDR papers that explain this problem. > > > > -----Original Message----- > > From: Karim El-Malki (ERA) [mailto:Karim.El-Malki@era.ericsson.se] > > Sent: Tuesday, July 24, 2001 12:03 PM > > To: 'mobile-ip@sunroof.eng.sun.com' > > Subject: RE: [mobile-ip] Handover Smoothing - What to Do? > > > > > > > GT> The nFA has no way of know at which point the > > > transmission was severed > > > at the oldFA...i.e.: if the bicasted packets are buffered > > at the newFA > > > (which I assume they will so this is useful) the TCP > issues remain! > > > > Just a quick answer to this point. You're assuming that you > > will buffer > > and that may not be needed. It's a MAY in low-latency. If you > > do buffer, > > and have a fixed buffer/delay at nFA of the size of the > > duration of the > > L2 handoff (when the MN is disconnected at L2 while moving > between oFA > > and nFA) then you shouldn't get duplicates. That's a > possible solution > > since the L2 handover period is normally known in wireless systems. > > > > Rgds > > /Karim > > > ------_=_NextPart_001_01C11478.11F2F250 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Handover Smoothing - What to Do?

See my comments inline

-Hongyi

> -----Original Message-----
> From: Karim El-Malki (ERA) [mailto:Karim.El-Malki@era= .ericsson.se]
> Sent: Tuesday, July 24, 2001 12:44 PM
> To: 'mobile-ip@sunroof.eng.sun.com'
> Subject: RE: [mobile-ip] Handover Smoothing - = What to Do?
>
>
> Comments inline.
>
> -----Original Message-----
> From: Hongyi Li [mailto:hyli@nortelnetworks.com]
> Sent: den 24 juli 2001 18:27
> To: 'mobile-ip@sunroof.eng.sun.com'
> Subject: RE: [mobile-ip] Handover Smoothing - = What to Do?
>
>
> Hi Karim,
>   I think George was right in this = point.
>   For a single interface MN, if there = is no synchronization
> between the
> two FAs, the MN will experience either packet = loss or packet
> duplication
> depending on the direction of the handoff. =
>   Here is an example, at time t, = assume FA1 is transmitting
> packet with
> seq no. x; FA2 is transmitting packet with seq = no. x+2.
>
> >> Why is it transmitting x+2? It would = be x-2 if FA2 (nFA)
> is buffering.
> >> If so my suggestion was to set the = buffer to the L2
> handoff duration.

[hyli] this is just to show the different = transmission speeds on
the two bicasting legs. The transmission speed = depends on the traffic
conditions on different legs that include radio = links as well. I don't
think we can over provisioning radio links in near = future.
Buffering at the new FA still doesn't solve the = problem. This is
because the transmission speed at old FA still = matters. Let's assume
for example bicasting started with packet of seq no. = x. If the old FA
is transmitting x-2 at handoff (due to poor radio = link), packet x-1
will be lost; if the old AR is transmitting x+2 at = handoff (good radio
link), the MN has packet duplication.


>
>  If the MN handoff
> from FA1 to FA2, packet x+1 will be lost. If = the MN handoff
> from FA2 to FA1
> the MN will receive duplicated packet x+1. =
>   Buffering without synchronization = won't help here.
>
> >> does it take zero time to perform a L2 = handoff in this example?
> >> If it does then I would expect FA2 to = transmit x, while
> FA1 transmits x.
> >> Then you don't have packet loss or = duplication.

[hyli] Whether handoff takes zero time or dt is not = important here. If a
system wants both FAs transmit x at the same time, = good synchronization
mechanism is needed. 2G CDMA systems implement this = synchronization
in soft handoff. However, this synchronization = reduces the overall
throughput of the CDMA systems. You may find some = HDR papers that explain
this problem.
 
>
>
> > -----Original Message-----
> > From: Karim El-Malki (ERA) [mailto:Karim.El-Malki@era= .ericsson.se]
> > Sent: Tuesday, July 24, 2001 12:03 PM =
> > To: 'mobile-ip@sunroof.eng.sun.com' =
> > Subject: RE: [mobile-ip] Handover = Smoothing - What to Do?
> >
> >
> > > GT> The nFA has no way of know at = which point the
> > > transmission was severed
> > > at the oldFA...i.e.: if the bicasted = packets are buffered
> > at the newFA
> > > (which I assume they will so this is = useful) the TCP
> issues remain!
> >
> > Just a quick answer to this point. You're = assuming that you
> > will buffer
> > and that may not be needed. It's a MAY in = low-latency. If you
> > do buffer,
> > and have a fixed buffer/delay at nFA of = the size of the
> > duration of the
> > L2 handoff (when the MN is disconnected at = L2 while moving
> between oFA
> > and nFA) then you shouldn't get = duplicates. That's a
> possible solution
> > since the L2 handover period is normally = known in wireless systems.
> >
> > Rgds
> > /Karim
> >
>

------_=_NextPart_001_01C11478.11F2F250-- From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 24 16:26:53 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA18924 for ; Tue, 24 Jul 2001 16:26:52 -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 NAA02234; Tue, 24 Jul 2001 13:27:27 -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 NAA18731; Tue, 24 Jul 2001 13:26:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6OKOrm21120 for mobile-ip-dist; Tue, 24 Jul 2001 13:24:53 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6OKOmY21113 for ; Tue, 24 Jul 2001 13:24:50 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id NAA23746 for ; Tue, 24 Jul 2001 13:25:03 -0700 (PDT) Message-Id: <200107242025.NAA23746@heliopolis.eng.sun.com> Date: Tue, 24 Jul 2001 13:25:02 -0700 (PDT) From: James Kempf Subject: RE: [mobile-ip] Handover Smoothing - What to Do? To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: +qoTBlXMlMwwhDjzyya7uw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 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: George, I think we agree that specifications of smoothing and fast handoff do not need to be linked, if only for practical considerations. I think we agree that it is possible to do smoothing without mobile/protocol involvement (bicasting in BETH using tunnels is done that way, only the routers are involved). I think we may disagree about the value of smoothing in actually implementing fast handoff. I have the impression you believe it may be possible to deploy fast handoff completely without any smoothing, whereas I feel that some smoothing will definitely be needed and that more experiments are necessary to quantify exactly what the technology should be. To that extent, I believe the fast handoff work is incomplete without discussion of smoothing (which, I believe, is Karim's position), but I would rather see the WG move forward on what we agree on than get hung up on what we don't, given that it seems to be technically possible to separate out the specification of smoothing from fast handoff. jak >From: George Tsirtsis >To: "'mobile-ip@sunroof.eng.sun.com'" >Subject: RE: [mobile-ip] Handover Smoothing - What to Do? >Date: Tue, 24 Jul 2001 14:41:50 -0400 > >James, > >I agree with Mike regarding make before break but you also agreed with me in >earlier e-mail that smoothing can be done by an implementation buffering >without protocol/mobile's involvement...so FMIP does not need smoothing >specificiations to become useful even in break before make. > >George >-----Original Message----- >From: Michael Thomas [mailto:mat@cisco.com] >Sent: Tuesday, July 24, 2001 6:51 PM >To: mobile-ip@sunroof.eng.sun.com >Subject: RE: [mobile-ip] Handover Smoothing - What to Do? > > >James Kempf writes: > > The issue is whether the FMIP work is completely useless without > > smoothing, or whether smoothing is so intertwined with the FMIP > > work that it is impossible to put it into a separate spec. I think > > the fact that the FMIPv6 draft managed to successfully disentangle > > them argues that the smoothing work can be separated out from > > a design perspective. Whether or not FMIP is useless without > > smoothing from an operational or implementation perspective > > is something that can only be determined by experiment. > > I'd say that it's not useless: if you have two interfaces, > FMIP alone is probably sufficient since you can do a make > before break while listening on both for some period of > time. It might be pointed out that you could do that without > the FMIP AR, but latencies back to the CN/HA may require a > more localized solution to achieve a reasonable handoff. > > Mike From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 24 16:40:18 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA20466 for ; Tue, 24 Jul 2001 16:40:17 -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 OAA15305; Tue, 24 Jul 2001 14:40: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 NAA22327; Tue, 24 Jul 2001 13:40:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6OKd7q21193 for mobile-ip-dist; Tue, 24 Jul 2001 13:39:07 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6OKd3Y21186 for ; Tue, 24 Jul 2001 13:39:03 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id NAA24572 for ; Tue, 24 Jul 2001 13:39:18 -0700 (PDT) Message-Id: <200107242039.NAA24572@heliopolis.eng.sun.com> Date: Tue, 24 Jul 2001 13:39:17 -0700 (PDT) From: James Kempf Subject: RE: [mobile-ip] Handover Smoothing - What to Do? To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: /GtyOcyoRxw1h/SKJsdw8Q== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 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: Hongyi, I agree with your analysis. Basically, what you are saying is that there can be jitter between the old link and the new that could result in duplicated packets going to the MN on the new link, correct? One way to mitigate this problem is for the FA to get better handover sequencing information from L2. For example, if nFA gets an L2 trigger when L2 handover begins, it can start buffering until the new L2 is fully stabilized. This reduces the window during which the nFA is buffering. Although it won't synchronize packet delivery, it will reduce the amount of buffered packets and therefore the potential for duplication. Another way to mitigate it is to make sure the wired network is properly provisioned for the expected amount of traffic, to reduce the possibility of congestion and thus jitter. This will not, of course, solve the problem of the radio link on the oFA slowing down. That can be mitigated with reducing cell sizes, etc. to avoid overloading, but, in general, if the radio propagation conditions become poor enough that retransmits are necessary, as you point out, oFA could lag behind the bicast stream. In general, I don't know any way to synchronize packet delivery between oFA and nFA. I believe CDMA does this by having a very short window (something like 20 ms) during which soft handover occurs, and using GPS (in cdma2000) to synchronize soft handover between BTSs. This is not possible in IP, if for no other reason than the packet sizes can vary, and not all radio protocols have access to GPS synchronization. There are a variety of heurstics that could be used, however, and I think it makes sense to write them down. jak >From: "Hongyi Li" >To: "'mobile-ip@sunroof.eng.sun.com'" >Subject: RE: [mobile-ip] Handover Smoothing - What to Do? >Date: Tue, 24 Jul 2001 15:37:27 -0400 > >See my comments inline > >-Hongyi > >> -----Original Message----- >> From: Karim El-Malki (ERA) [mailto:Karim.El-Malki@era.ericsson.se] >> Sent: Tuesday, July 24, 2001 12:44 PM >> To: 'mobile-ip@sunroof.eng.sun.com' >> Subject: RE: [mobile-ip] Handover Smoothing - What to Do? >> >> >> Comments inline. >> >> -----Original Message----- >> From: Hongyi Li [mailto:hyli@nortelnetworks.com] >> Sent: den 24 juli 2001 18:27 >> To: 'mobile-ip@sunroof.eng.sun.com' >> Subject: RE: [mobile-ip] Handover Smoothing - What to Do? >> >> >> Hi Karim, >> I think George was right in this point. >> For a single interface MN, if there is no synchronization >> between the >> two FAs, the MN will experience either packet loss or packet >> duplication >> depending on the direction of the handoff. >> Here is an example, at time t, assume FA1 is transmitting >> packet with >> seq no. x; FA2 is transmitting packet with seq no. x+2. >> >> >> Why is it transmitting x+2? It would be x-2 if FA2 (nFA) >> is buffering. >> >> If so my suggestion was to set the buffer to the L2 >> handoff duration. > >[hyli] this is just to show the different transmission speeds on >the two bicasting legs. The transmission speed depends on the traffic >conditions on different legs that include radio links as well. I don't >think we can over provisioning radio links in near future. >Buffering at the new FA still doesn't solve the problem. This is >because the transmission speed at old FA still matters. Let's assume >for example bicasting started with packet of seq no. x. If the old FA >is transmitting x-2 at handoff (due to poor radio link), packet x-1 >will be lost; if the old AR is transmitting x+2 at handoff (good radio >link), the MN has packet duplication. > > >> >> If the MN handoff >> from FA1 to FA2, packet x+1 will be lost. If the MN handoff >> from FA2 to FA1 >> the MN will receive duplicated packet x+1. >> Buffering without synchronization won't help here. >> >> >> does it take zero time to perform a L2 handoff in this example? >> >> If it does then I would expect FA2 to transmit x, while >> FA1 transmits x. >> >> Then you don't have packet loss or duplication. > >[hyli] Whether handoff takes zero time or dt is not important here. If a >system wants both FAs transmit x at the same time, good synchronization >mechanism is needed. 2G CDMA systems implement this synchronization >in soft handoff. However, this synchronization reduces the overall >throughput of the CDMA systems. You may find some HDR papers that explain >this problem. > >> >> >> > -----Original Message----- >> > From: Karim El-Malki (ERA) [mailto:Karim.El-Malki@era.ericsson.se] >> > Sent: Tuesday, July 24, 2001 12:03 PM >> > To: 'mobile-ip@sunroof.eng.sun.com' >> > Subject: RE: [mobile-ip] Handover Smoothing - What to Do? >> > >> > >> > > GT> The nFA has no way of know at which point the >> > > transmission was severed >> > > at the oldFA...i.e.: if the bicasted packets are buffered >> > at the newFA >> > > (which I assume they will so this is useful) the TCP >> issues remain! >> > >> > Just a quick answer to this point. You're assuming that you >> > will buffer >> > and that may not be needed. It's a MAY in low-latency. If you >> > do buffer, >> > and have a fixed buffer/delay at nFA of the size of the >> > duration of the >> > L2 handoff (when the MN is disconnected at L2 while moving >> between oFA >> > and nFA) then you shouldn't get duplicates. That's a >> possible solution >> > since the L2 handover period is normally known in wireless systems. >> > >> > Rgds >> > /Karim >> > >> From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 24 17:17:49 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA24020 for ; Tue, 24 Jul 2001 17:17:48 -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 PAA14577; Tue, 24 Jul 2001 15:18:13 -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 OAA11213; Tue, 24 Jul 2001 14:18:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6OLGQ321308 for mobile-ip-dist; Tue, 24 Jul 2001 14:16:26 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6OLGMY21301 for ; Tue, 24 Jul 2001 14:16: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 OAA25167 for ; Tue, 24 Jul 2001 14:16:36 -0700 (PDT) Received: from netmail.alcatel.com (netmail.alcatel.com [128.251.168.50]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA13393 for ; Tue, 24 Jul 2001 15:16:34 -0600 (MDT) Received: from auds952.usa.alcatel.com (auds952.usa.alcatel.com [143.209.238.7]) by netmail.alcatel.com (8.9.1/8.9.1) with ESMTP id QAA22230 for ; Tue, 24 Jul 2001 16:16:35 -0500 (CDT) Received: from usa.alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f6OLGYk14543 for ; Tue, 24 Jul 2001 16:16:34 -0500 (CDT) Message-ID: <3B5DE5B0.342A8FDE@usa.alcatel.com> Date: Tue, 24 Jul 2001 16:16:33 -0500 From: Sridhar Gurivireddy Organization: Alcatel USA X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Handover Smoothing - What to Do? References: <200107242039.NAA24572@heliopolis.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 James Kempf wrote > Hongyi, > > I agree with your analysis. Basically, what you are saying is that > there can be jitter between the old link and the new that could > result in duplicated packets going to the MN on the new link, correct > > One way to mitigate this problem is for the FA to get better > handover sequencing information from L2. For example, if nFA > gets an L2 trigger when L2 handover begins, it can start buffering > until the new L2 is fully stabilized. This reduces the window > during which the nFA is buffering. Although it won't synchronize > packet delivery, it will reduce the amount of buffered packets > and therefore the potential for duplication. > If during handoff, the MN (or) the old FA get information(trigger) about handoff before the actual handoff takes place, passing this information to new FA through some upper layer protocol may itself induce some delay. In that time, actual, L2 handoff may have already have started....Of course, if this trigger information is passed fast enough, it may help in Handover-smoothing... This delay is even more when the Acess router and access point are at different points in the network..What I feel is, some other Layer-3 protocol should be written to reduce this delay...instead of relying on Layer-2 triggers... > > Another way to mitigate it is to make sure the wired network is > properly provisioned for the expected amount of traffic, to > reduce the possibility of congestion and thus jitter. This will > not, of course, solve the problem of the radio link on the > oFA slowing down. That can be mitigated with reducing cell > sizes, etc. to avoid overloading, but, in general, if the > radio propagation conditions become poor enough that retransmits > are necessary, as you point out, oFA could lag behind the > bicast stream. > > In general, I don't know any way to synchronize packet delivery > between oFA and nFA. I believe CDMA does this by having a > very short window (something like 20 ms) during which soft handover > occurs, and using GPS (in cdma2000) to synchronize soft handover > between BTSs. This is not possible in IP, if for no other reason than > the packet sizes can vary, and not all radio protocols have access > to GPS synchronization. There are a variety of heurstics that > could be used, however, and I think it makes sense to write > them down. > > jak > > >From: "Hongyi Li" > >To: "'mobile-ip@sunroof.eng.sun.com'" > >Subject: RE: [mobile-ip] Handover Smoothing - What to Do? > >Date: Tue, 24 Jul 2001 15:37:27 -0400 > > > >See my comments inline > > > >-Hongyi > > > >> -----Original Message----- > >> From: Karim El-Malki (ERA) [mailto:Karim.El-Malki@era.ericsson.se] > >> Sent: Tuesday, July 24, 2001 12:44 PM > >> To: 'mobile-ip@sunroof.eng.sun.com' > >> Subject: RE: [mobile-ip] Handover Smoothing - What to Do? > >> > >> > >> Comments inline. > >> > >> -----Original Message----- > >> From: Hongyi Li [mailto:hyli@nortelnetworks.com] > >> Sent: den 24 juli 2001 18:27 > >> To: 'mobile-ip@sunroof.eng.sun.com' > >> Subject: RE: [mobile-ip] Handover Smoothing - What to Do? > >> > >> > >> Hi Karim, > >> I think George was right in this point. > >> For a single interface MN, if there is no synchronization > >> between the > >> two FAs, the MN will experience either packet loss or packet > >> duplication > >> depending on the direction of the handoff. > >> Here is an example, at time t, assume FA1 is transmitting > >> packet with > >> seq no. x; FA2 is transmitting packet with seq no. x+2. > >> > >> >> Why is it transmitting x+2? It would be x-2 if FA2 (nFA) > >> is buffering. > >> >> If so my suggestion was to set the buffer to the L2 > >> handoff duration. > > > >[hyli] this is just to show the different transmission speeds on > >the two bicasting legs. The transmission speed depends on the traffic > >conditions on different legs that include radio links as well. I don't > >think we can over provisioning radio links in near future. > >Buffering at the new FA still doesn't solve the problem. This is > >because the transmission speed at old FA still matters. Let's assume > >for example bicasting started with packet of seq no. x. If the old FA > >is transmitting x-2 at handoff (due to poor radio link), packet x-1 > >will be lost; if the old AR is transmitting x+2 at handoff (good radio > >link), the MN has packet duplication. > > > > > >> > >> If the MN handoff > >> from FA1 to FA2, packet x+1 will be lost. If the MN handoff > >> from FA2 to FA1 > >> the MN will receive duplicated packet x+1. > >> Buffering without synchronization won't help here. > >> > >> >> does it take zero time to perform a L2 handoff in this example? > >> >> If it does then I would expect FA2 to transmit x, while > >> FA1 transmits x. > >> >> Then you don't have packet loss or duplication. > > > >[hyli] Whether handoff takes zero time or dt is not important here. If a > >system wants both FAs transmit x at the same time, good synchronization > >mechanism is needed. 2G CDMA systems implement this synchronization > >in soft handoff. However, this synchronization reduces the overall > >throughput of the CDMA systems. You may find some HDR papers that explain > >this problem. > > > >> > >> > >> > -----Original Message----- > >> > From: Karim El-Malki (ERA) [mailto:Karim.El-Malki@era.ericsson.se] > >> > Sent: Tuesday, July 24, 2001 12:03 PM > >> > To: 'mobile-ip@sunroof.eng.sun.com' > >> > Subject: RE: [mobile-ip] Handover Smoothing - What to Do? > >> > > >> > > >> > > GT> The nFA has no way of know at which point the > >> > > transmission was severed > >> > > at the oldFA...i.e.: if the bicasted packets are buffered > >> > at the newFA > >> > > (which I assume they will so this is useful) the TCP > >> issues remain! > >> > > >> > Just a quick answer to this point. You're assuming that you > >> > will buffer > >> > and that may not be needed. It's a MAY in low-latency. If you > >> > do buffer, > >> > and have a fixed buffer/delay at nFA of the size of the > >> > duration of the > >> > L2 handoff (when the MN is disconnected at L2 while moving > >> between oFA > >> > and nFA) then you shouldn't get duplicates. That's a > >> possible solution > >> > since the L2 handover period is normally known in wireless systems. > >> > > >> > Rgds > >> > /Karim > >> > > >> -- Sridhar Guriviredddy, Alcatel- Network Strategic Group, Richardson, TX-75080 Ph: 972.996.2048 From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 24 17:49:01 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA26544 for ; Tue, 24 Jul 2001 17:49:00 -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 PAA07956; Tue, 24 Jul 2001 15:49: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 OAA02534; Tue, 24 Jul 2001 14:49:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6OLlj221408 for mobile-ip-dist; Tue, 24 Jul 2001 14:47:46 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6OLlgY21401 for ; Tue, 24 Jul 2001 14:47:42 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA02270 for ; Tue, 24 Jul 2001 14:47:57 -0700 (PDT) Received: from mailsys01.intnet.net (mailhost.wwc.com [198.252.32.15]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA05501 for ; Tue, 24 Jul 2001 14:47:56 -0700 (PDT) Received: from [206.112.122.240] ([206.112.122.240] verified) by mailsys01.intnet.net (CommuniGate Pro SMTP 3.4.8) with ESMTP id 11963710 for mobile-ip@sunroof.eng.sun.com; Tue, 24 Jul 2001 17:47:21 -0400 Mime-Version: 1.0 X-Sender: ahmrphd@pop3.attglobal.net Message-Id: In-Reply-To: <200107242039.NAA24572@heliopolis.eng.sun.com> References: <200107242039.NAA24572@heliopolis.eng.sun.com> Date: Tue, 24 Jul 2001 14:47:54 -0700 To: mobile-ip@sunroof.eng.sun.com From: Arthur Ross Subject: RE: [mobile-ip] Handover Smoothing - What to Do? 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 13:39 -0700 07/24/2001, James Kempf wrote: > >In general, I don't know any way to synchronize packet delivery >between oFA and nFA. I believe CDMA does this by having a >very short window (something like 20 ms) during which soft handover >occurs, and using GPS (in cdma2000) to synchronize soft handover >between BTSs. This is not possible in IP, if for no other reason than >the packet sizes can vary, and not all radio protocols have access >to GPS synchronization. There are a variety of heurstics that >could be used, however, and I think it makes sense to write >them down. > James et al: The issue here is the nature of the diversity that is available in any given RAN technology. The simplest is unsynchronized multicasting - packets are sent from more than one source, without any attempt at synchronization other than that imposed by sequence numbering. The various flavors of CDMA technology, on the other hand, employ a very sophisticated symbol-by-symbol optimal ratio (in the downlink) combining. This substantially improves error performance under adverse propagation conditions. That combining is, in essence, a vector sum of received symbol amplitude estimates from whatever sources are available. The signal components add amplitude-wise, while the noise components add power-wise (i.e. rss), hence the improvement in overall SNR of the resultant. This technique relies on the same sequence of symbols be radiated the various BTSs participating in this "soft" handoff. The CDMA return link diversity combining is done in a different way, but also makes use of multiple symbol streams from the various BTS receivers involved in the handoff. As you say, this is done with the aid of GPS-derived precise timing. Synchronization is not fundamentally necessary, but it is extremely convenient in implementing the combining, and helps keep the latency low. Other less precisely timed forms are possible in principle, but have not, as far as I know, ever been proposed or implemented. To do so would require substantially buffering and de-skewing of the symbol streams. That buffering and deskewing would contribute objectionable latency and variance of latency, both very objectionable in a speech service. The 20 ms of which you speak is the CDMA frame size. That size has its origins in the size of the vocoder frames. The FEC is blocked in those 20 ms frames - each frame can be decoded and CRC checked independently. Again, not fundamental, but because of the dominance of the speech service, it is probably here to stay, or at least will be around for a long time. Re "handoff smoothing" - It is, I think, desirable to recognize the variety of diversity techniques that may be used in the radio link, depending on the particular technology, and to provide the tools/mechanisms the can accommodate that variety somehow. This is, obviously, intimately intertwined with the QoS issues. What is ok for a dumb datagram service may be manifestly awful for a speech service. Just my 2 cents worth ... -- Regards, AHMR From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 24 17:58:00 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA27006 for ; Tue, 24 Jul 2001 17:57:59 -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 OAA17440; Tue, 24 Jul 2001 14:58:04 -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 OAA04211; Tue, 24 Jul 2001 14:57:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6OLu0F21469 for mobile-ip-dist; Tue, 24 Jul 2001 14:56:00 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6OLtvY21462 for ; Tue, 24 Jul 2001 14:55:57 -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 OAA04769 for ; Tue, 24 Jul 2001 14:56:12 -0700 (PDT) Received: from zcars0m9.ca.nortel.com ([47.129.242.157]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA15589 for ; Tue, 24 Jul 2001 15:57:36 -0600 (MDT) Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f6OLti924397 for ; Tue, 24 Jul 2001 17:55:44 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.ca.nortel.com; Tue, 24 Jul 2001 17:55:46 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Jul 2001 17:55:48 -0400 Message-ID: From: "Hongyi Li" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Handover Smoothing - What to Do? Date: Tue, 24 Jul 2001 17:55:47 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1148B.651DB560" X-Orig: 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_01C1148B.651DB560 Content-Type: text/plain; charset="iso-8859-1" Hi James, My comments are inline. Rgds Hongyi > -----Original Message----- > From: James Kempf [mailto:James.Kempf@Sun.COM] > Sent: Tuesday, July 24, 2001 4:39 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: RE: [mobile-ip] Handover Smoothing - What to Do? > > > Hongyi, > > I agree with your analysis. Basically, what you are saying is that > there can be jitter between the old link and the new that could > result in duplicated packets going to the MN on the new link, > correct? Yes. Jitter between old and new links could result in packet duplication or packet loss in bicasting. > > One way to mitigate this problem is for the FA to get better > handover sequencing information from L2. For example, if nFA > gets an L2 trigger when L2 handover begins, it can start buffering > until the new L2 is fully stabilized. This reduces the window > during which the nFA is buffering. Although it won't synchronize > packet delivery, it will reduce the amount of buffered packets > and therefore the potential for duplication. > > Another way to mitigate it is to make sure the wired network is > properly provisioned for the expected amount of traffic, to > reduce the possibility of congestion and thus jitter. This will > not, of course, solve the problem of the radio link on the > oFA slowing down. That can be mitigated with reducing cell > sizes, etc. to avoid overloading, but, in general, if the > radio propagation conditions become poor enough that retransmits > are necessary, as you point out, oFA could lag behind the > bicast stream. > > In general, I don't know any way to synchronize packet delivery > between oFA and nFA. I believe CDMA does this by having a > very short window (something like 20 ms) during which soft handover > occurs, and using GPS (in cdma2000) to synchronize soft handover > between BTSs. This is not possible in IP, if for no other reason than > the packet sizes can vary, and not all radio protocols have access > to GPS synchronization. There are a variety of heurstics that > could be used, however, and I think it makes sense to write > them down. I agree that it is very difficult to implement CDMA type of synchronization mechanism in IP layer. Based on the perceived value and cost of implementing such a sync. mechanism, it would be better to use heuristics to reduce the packet duplication or loss. The heuristics can be used by network operators for improving their network performance if bicasting is used. > > jak > > >From: "Hongyi Li" > >To: "'mobile-ip@sunroof.eng.sun.com'" > >Subject: RE: [mobile-ip] Handover Smoothing - What to Do? > >Date: Tue, 24 Jul 2001 15:37:27 -0400 > > > >See my comments inline > > > >-Hongyi > > > >> -----Original Message----- > >> From: Karim El-Malki (ERA) [mailto:Karim.El-Malki@era.ericsson.se] > >> Sent: Tuesday, July 24, 2001 12:44 PM > >> To: 'mobile-ip@sunroof.eng.sun.com' > >> Subject: RE: [mobile-ip] Handover Smoothing - What to Do? > >> > >> > >> Comments inline. > >> > >> -----Original Message----- > >> From: Hongyi Li [mailto:hyli@nortelnetworks.com] > >> Sent: den 24 juli 2001 18:27 > >> To: 'mobile-ip@sunroof.eng.sun.com' > >> Subject: RE: [mobile-ip] Handover Smoothing - What to Do? > >> > >> > >> Hi Karim, > >> I think George was right in this point. > >> For a single interface MN, if there is no synchronization > >> between the > >> two FAs, the MN will experience either packet loss or packet > >> duplication > >> depending on the direction of the handoff. > >> Here is an example, at time t, assume FA1 is transmitting > >> packet with > >> seq no. x; FA2 is transmitting packet with seq no. x+2. > >> > >> >> Why is it transmitting x+2? It would be x-2 if FA2 (nFA) > >> is buffering. > >> >> If so my suggestion was to set the buffer to the L2 > >> handoff duration. > > > >[hyli] this is just to show the different transmission speeds on > >the two bicasting legs. The transmission speed depends on the traffic > >conditions on different legs that include radio links as > well. I don't > >think we can over provisioning radio links in near future. > >Buffering at the new FA still doesn't solve the problem. This is > >because the transmission speed at old FA still matters. Let's assume > >for example bicasting started with packet of seq no. x. If the old FA > >is transmitting x-2 at handoff (due to poor radio link), packet x-1 > >will be lost; if the old AR is transmitting x+2 at handoff > (good radio > >link), the MN has packet duplication. > > > > > >> > >> If the MN handoff > >> from FA1 to FA2, packet x+1 will be lost. If the MN handoff > >> from FA2 to FA1 > >> the MN will receive duplicated packet x+1. > >> Buffering without synchronization won't help here. > >> > >> >> does it take zero time to perform a L2 handoff in this example? > >> >> If it does then I would expect FA2 to transmit x, while > >> FA1 transmits x. > >> >> Then you don't have packet loss or duplication. > > > >[hyli] Whether handoff takes zero time or dt is not > important here. If a > >system wants both FAs transmit x at the same time, good > synchronization > >mechanism is needed. 2G CDMA systems implement this synchronization > >in soft handoff. However, this synchronization reduces the overall > >throughput of the CDMA systems. You may find some HDR papers > that explain > >this problem. > > > >> > >> > >> > -----Original Message----- > >> > From: Karim El-Malki (ERA) [mailto:Karim.El-Malki@era.ericsson.se] >> > Sent: Tuesday, July 24, 2001 12:03 PM >> > To: 'mobile-ip@sunroof.eng.sun.com' >> > Subject: RE: [mobile-ip] Handover Smoothing - What to Do? >> > >> > >> > > GT> The nFA has no way of know at which point the >> > > transmission was severed >> > > at the oldFA...i.e.: if the bicasted packets are buffered >> > at the newFA >> > > (which I assume they will so this is useful) the TCP >> issues remain! >> > >> > Just a quick answer to this point. You're assuming that you >> > will buffer >> > and that may not be needed. It's a MAY in low-latency. If you >> > do buffer, >> > and have a fixed buffer/delay at nFA of the size of the >> > duration of the >> > L2 handoff (when the MN is disconnected at L2 while moving >> between oFA >> > and nFA) then you shouldn't get duplicates. That's a >> possible solution >> > since the L2 handover period is normally known in wireless systems. >> > >> > Rgds >> > /Karim >> > >> ------_=_NextPart_001_01C1148B.651DB560 Content-Type: text/html; charset="iso-8859-1" RE: [mobile-ip] Handover Smoothing - What to Do?

Hi James,
 
  My comments are inline.


Rgds

Hongyi



> -----Original Message-----
> From: James Kempf [mailto:James.Kempf@Sun.COM]
> Sent: Tuesday, July 24, 2001 4:39 PM
> To: mobile-ip@sunroof.eng.sun.com
> Subject: RE: [mobile-ip] Handover Smoothing - What to Do?
>
>
> Hongyi,
>
> I agree  with your analysis. Basically, what you are saying is that
> there can be jitter between the old link and the new that could
> result in duplicated packets going to the MN on the new link,
> correct?

Yes. Jitter between old and new links could result in packet duplication
or packet loss in bicasting.

>
> One way to mitigate this problem is for the FA to get better
> handover sequencing information from L2. For example, if nFA
> gets an L2 trigger when L2 handover begins, it can start buffering
> until the new L2 is fully stabilized. This reduces the window
> during which the nFA is buffering. Although it won't synchronize
> packet delivery, it will reduce the amount of buffered packets
> and therefore the potential for duplication.
>
> Another way to mitigate it is to make sure the wired network is
> properly provisioned for the expected amount of traffic, to
> reduce the possibility of congestion and thus jitter. This will
> not, of course, solve the problem of the radio link on the
> oFA slowing down. That can be mitigated with reducing cell
> sizes, etc. to avoid overloading, but, in general, if the
> radio propagation conditions become poor enough that retransmits
> are necessary, as you point out, oFA could lag behind the
> bicast stream.
>
> In general, I don't know any way to synchronize packet delivery
> between oFA and nFA. I believe CDMA does this by having a
> very short window (something like 20 ms) during which soft handover
> occurs, and using GPS (in cdma2000) to synchronize soft handover
> between BTSs. This is not possible in IP, if for no other reason than
> the packet sizes can vary, and not all radio protocols have access
> to GPS synchronization. There are a variety of heurstics that
> could be used, however, and I think it makes sense to write
> them down.

I agree that it is very difficult to implement CDMA type of
synchronization mechanism in IP layer. Based on the perceived value and
cost of implementing such a sync. mechanism, it would be better
to use heuristics to reduce the packet duplication or loss. The
heuristics can be used by network operators for improving their
network performance if bicasting is used.




>
>               jak
>
> >From: "Hongyi Li" <hyli@nortelnetworks.com>
> >To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
> >Subject: RE: [mobile-ip] Handover Smoothing - What to Do?
> >Date: Tue, 24 Jul 2001 15:37:27 -0400
> >
> >See my comments inline
> >
> >-Hongyi
> >
> >> -----Original Message-----
> >> From: Karim El-Malki (ERA) [mailto:Karim.El-Malki@era.ericsson.se]
> >> Sent: Tuesday, July 24, 2001 12:44 PM
> >> To: 'mobile-ip@sunroof.eng.sun.com'
> >> Subject: RE: [mobile-ip] Handover Smoothing - What to Do?
> >>
> >>
> >> Comments inline.
> >>
> >> -----Original Message-----
> >> From: Hongyi Li [mailto:hyli@nortelnetworks.com]
> >> Sent: den 24 juli 2001 18:27
> >> To: 'mobile-ip@sunroof.eng.sun.com'
> >> Subject: RE: [mobile-ip] Handover Smoothing - What to Do?
> >>
> >>
> >> Hi Karim,
> >>   I think George was right in this point.
> >>   For a single interface MN, if there is no synchronization
> >> between the
> >> two FAs, the MN will experience either packet loss or packet
> >> duplication
> >> depending on the direction of the handoff.
> >>   Here is an example, at time t, assume FA1 is transmitting
> >> packet with
> >> seq no. x; FA2 is transmitting packet with seq no. x+2.
> >>
> >> >> Why is it transmitting x+2? It would be x-2 if FA2 (nFA)
> >> is buffering.
> >> >> If so my suggestion was to set the buffer to the L2
> >> handoff duration.
> >
> >[hyli] this is just to show the different transmission speeds on
> >the two bicasting legs. The transmission speed depends on the traffic
> >conditions on different legs that include radio links as
> well. I don't
> >think we can over provisioning radio links in near future.
> >Buffering at the new FA still doesn't solve the problem. This is
> >because the transmission speed at old FA still matters. Let's assume
> >for example bicasting started with packet of seq no. x. If the old FA
> >is transmitting x-2 at handoff (due to poor radio link), packet x-1
> >will be lost; if the old AR is transmitting x+2 at handoff
> (good radio
> >link), the MN has packet duplication.
> >
> >
> >>
> >>  If the MN handoff
> >> from FA1 to FA2, packet x+1 will be lost. If the MN handoff
> >> from FA2 to FA1
> >> the MN will receive duplicated packet x+1.
> >>   Buffering without synchronization won't help here.
> >>
> >> >> does it take zero time to perform a L2 handoff in this example?
> >> >> If it does then I would expect FA2 to transmit x, while
> >> FA1 transmits x.
> >> >> Then you don't have packet loss or duplication.
> >
> >[hyli] Whether handoff takes zero time or dt is not
> important here. If a
> >system wants both FAs transmit x at the same time, good
> synchronization
> >mechanism is needed. 2G CDMA systems implement this synchronization
> >in soft handoff. However, this synchronization reduces the overall
> >throughput of the CDMA systems. You may find some HDR papers
> that explain
> >this problem.
> > 
> >>
> >>
> >> > -----Original Message-----
> >> > From: Karim El-Malki (ERA)
[mailto:Karim.El-Malki@era.ericsson.se]
>> > Sent: Tuesday, July 24, 2001 12:03 PM
>> > To: 'mobile-ip@sunroof.eng.sun.com'
>> > Subject: RE: [mobile-ip] Handover Smoothing - What to Do?
>> >
>> >
>> > > GT> The nFA has no way of know at which point the
>> > > transmission was severed
>> > > at the oldFA...i.e.: if the bicasted packets are buffered
>> > at the newFA
>> > > (which I assume they will so this is useful) the TCP
>> issues remain!
>> >
>> > Just a quick answer to this point. You're assuming that you
>> > will buffer
>> > and that may not be needed. It's a MAY in low-latency. If you
>> > do buffer,
>> > and have a fixed buffer/delay at nFA of the size of the
>> > duration of the
>> > L2 handoff (when the MN is disconnected at L2 while moving
>> between oFA
>> > and nFA) then you shouldn't get duplicates. That's a
>> possible solution
>> > since the L2 handover period is normally known in wireless systems.
>> >
>> > Rgds
>> > /Karim
>> >
>>

------_=_NextPart_001_01C1148B.651DB560-- From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 24 18:00:06 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27106 for ; Tue, 24 Jul 2001 18:00: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 QAA16519; Tue, 24 Jul 2001 16:00: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 PAA04893; Tue, 24 Jul 2001 15:00:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6OLwuK21503 for mobile-ip-dist; Tue, 24 Jul 2001 14:58:56 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6OLwqY21494 for ; Tue, 24 Jul 2001 14:58: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 OAA20188 for ; Tue, 24 Jul 2001 14:59:07 -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 PAA15031 for ; Tue, 24 Jul 2001 15:59:04 -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 OAA03935; Tue, 24 Jul 2001 14:57:01 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6OLuxI12676; Tue, 24 Jul 2001 14:56:59 -0700 X-mProtect: Tue, 24 Jul 2001 14:56:59 -0700 Nokia Silicon Valley Messaging Protection Received: from vijayd.iprg.nokia.com (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdazp7Cg; Tue, 24 Jul 2001 14:56:56 PDT Message-ID: <3B5DEF29.CE1C831D@iprg.nokia.com> Date: Tue, 24 Jul 2001 14:56:57 -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: mobile-ip@sunroof.eng.sun.com CC: Alexis , Phil Roberts , "Basavaraj Patil (NTC/Dallas)" , Abha Ahuja , Thomas Narten , Dave Johnson , Jeff Schiller , Marcus Leech , Pekka Nikander Subject: Re: [Fwd: [mobile-ip] Mobile IPv6 clarifications] References: <200107241727.f6OHRlS08219@thunk.east.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 hello, i thought the real problem with the use of IPSec was with distinguishing a destination options header containing a BU and a destination options header containing some other option. this is not possible with current IPsec selectors. at least this is what Jeff Schiller said in his presentation at the minneapolis IETF. if piggybacking a BU was the problem, we could have solved it long back. just disallow piggybacking. anyway its a 'MAY' in the current draft. you dont lose much by not piggybacking the BU. of course, the other problem is the lack of a global PKI. Bill Sommerfeld wrote: > If I receive an AH-protected packet containing a binding update and a > TCP SYN, a receiver cannot know for sure whether the sender intended > the AH protection to apply just to the binding update, or also to > subsequent packets that are part of the TCP connection. dont sent those two together, then. you dont HAVE to piggyback. vijay > While I thought this option had been beaten to death, if folks still > want to use IPsec to protect MN/CN traffic, here are two possible ways > to deal: > > 1) disallow piggybacking, and always send binding updates separately > from user traffic. > > 2) since you've already paid the cost of setting up the IPsec > security associations, you might as well just keep using them -- once > a binding is established, *all* traffic between the MN and the CN > should be protected the same way. > > Note that even with this issue resolved, you still have to deal with > the PKI/authentication/etc. issues involved with SA setup; if > anything, this is a much harder problem.. > > - Bill From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 24 18:29:08 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA28456 for ; Tue, 24 Jul 2001 18:29:08 -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 PAA02694; Tue, 24 Jul 2001 15:29: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 PAA10765; Tue, 24 Jul 2001 15:29:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6OMS1j21615 for mobile-ip-dist; Tue, 24 Jul 2001 15:28:01 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6OMRvY21608 for ; Tue, 24 Jul 2001 15:27:57 -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 PAA10494 for ; Tue, 24 Jul 2001 15:28:10 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA06557 for ; Tue, 24 Jul 2001 16:28:08 -0600 (MDT) 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 f6OMSKT24112; Tue, 24 Jul 2001 15:28:20 -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 AAT00116; Tue, 24 Jul 2001 15:28:06 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA10503; Tue, 24 Jul 2001 15:28:06 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15197.63094.198068.928185@thomasm-u1.cisco.com> Date: Tue, 24 Jul 2001 15:28:06 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Cc: Alexis , Phil Roberts , "Basavaraj Patil (NTC/Dallas)" , Abha Ahuja , Thomas Narten , Dave Johnson , Jeff Schiller , Marcus Leech , Pekka Nikander Subject: Re: [Fwd: [mobile-ip] Mobile IPv6 clarifications] In-Reply-To: <3B5DEF29.CE1C831D@iprg.nokia.com> References: <200107241727.f6OHRlS08219@thunk.east.sun.com> <3B5DEF29.CE1C831D@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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Vijay Devarapalli writes: > hello, > > i thought the real problem with the use of IPSec was with > distinguishing a destination options header containing a > BU and a destination options header containing some other > option. this is not possible with current IPsec selectors. Ah, that's very different, and I agree it would be a problem with IPsec selectors. I guess I have to ask that _if_ that was the intention of the -13 draft, why. I didn't read it that way, but it's quite possible I didn't notice that subtlety. If the intention was not wanting other DO's to have to be protected, I guess I have to wonder why. I'm starting to think that Bill's suggestion of just setting a up coarser ID selector (ie, don't select based off of IP protocol) may be the right tweak here. Frankly, I think that IPsec/IKE needs a face lift here, because this is all screwed up; MIP has the dubious distinction of being first to be blown up by this land mine left over from the v4 centric world. Mike > at least this is what Jeff Schiller said in his presentation > at the minneapolis IETF. > > if piggybacking a BU was the problem, we could have solved > it long back. just disallow piggybacking. anyway its a 'MAY' > in the current draft. you dont lose much by not piggybacking > the BU. > > of course, the other problem is the lack of a global PKI. > > Bill Sommerfeld wrote: > > > If I receive an AH-protected packet containing a binding update and a > > TCP SYN, a receiver cannot know for sure whether the sender intended > > the AH protection to apply just to the binding update, or also to > > subsequent packets that are part of the TCP connection. > > dont sent those two together, then. you dont HAVE to piggyback. > > vijay > > > While I thought this option had been beaten to death, if folks still > > want to use IPsec to protect MN/CN traffic, here are two possible ways > > to deal: > > > > 1) disallow piggybacking, and always send binding updates separately > > from user traffic. > > > > 2) since you've already paid the cost of setting up the IPsec > > security associations, you might as well just keep using them -- once > > a binding is established, *all* traffic between the MN and the CN > > should be protected the same way. > > > > Note that even with this issue resolved, you still have to deal with > > the PKI/authentication/etc. issues involved with SA setup; if > > anything, this is a much harder problem.. > > > > - Bill From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 24 21:25:18 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA05189 for ; Tue, 24 Jul 2001 21:25:17 -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 TAA12148; Tue, 24 Jul 2001 19:25: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 SAA12770; Tue, 24 Jul 2001 18:25:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6P1O2S22223 for mobile-ip-dist; Tue, 24 Jul 2001 18:24:02 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6P1NwY22216 for ; Tue, 24 Jul 2001 18:23:58 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA12413 for ; Tue, 24 Jul 2001 18:24:13 -0700 (PDT) Received: from thorium.mcis.singnet.com.sg (thorium.singnet.com.sg [165.21.74.73]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA22797 for ; Tue, 24 Jul 2001 18:24:12 -0700 (PDT) Received: from mail pickup service by thorium.mcis.singnet.com.sg with Microsoft SMTPSVC; Wed, 25 Jul 2001 09:24:07 +0800 Received: from mx12.singnet.com.sg ([165.21.74.122]) by tellurium.mcis.singnet.com.sg with Microsoft SMTPSVC(5.5.1877.687.68); Wed, 25 Jul 2001 05:23:10 +0800 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by mx12.singnet.com.sg (8.11.4/8.11.3) with ESMTP id f6OLNDk28136 for ; Wed, 25 Jul 2001 05:23:13 +0800 Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA29303; Tue, 24 Jul 2001 14:20:21 -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 OAA11279; Tue, 24 Jul 2001 14:18:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6OLGQ321308 for mobile-ip-dist; Tue, 24 Jul 2001 14:16:26 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6OLGMY21301 for ; Tue, 24 Jul 2001 14:16: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 OAA25167 for ; Tue, 24 Jul 2001 14:16:36 -0700 (PDT) Received: from netmail.alcatel.com (netmail.alcatel.com [128.251.168.50]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA13393 for ; Tue, 24 Jul 2001 15:16:34 -0600 (MDT) Received: from auds952.usa.alcatel.com (auds952.usa.alcatel.com [143.209.238.7]) by netmail.alcatel.com (8.9.1/8.9.1) with ESMTP id QAA22230 for ; Tue, 24 Jul 2001 16:16:35 -0500 (CDT) Received: from usa.alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f6OLGYk14543 for ; Tue, 24 Jul 2001 16:16:34 -0500 (CDT) Message-ID: <3B5DE5B0.342A8FDE@usa.alcatel.com> Date: Tue, 24 Jul 2001 16:16:33 -0500 From: Sridhar Gurivireddy Organization: Alcatel USA X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Handover Smoothing - What to Do? References: <200107242039.NAA24572@heliopolis.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: 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 James Kempf wrote > Hongyi, > > I agree with your analysis. Basically, what you are saying is that > there can be jitter between the old link and the new that could > result in duplicated packets going to the MN on the new link, correct > > One way to mitigate this problem is for the FA to get better > handover sequencing information from L2. For example, if nFA > gets an L2 trigger when L2 handover begins, it can start buffering > until the new L2 is fully stabilized. This reduces the window > during which the nFA is buffering. Although it won't synchronize > packet delivery, it will reduce the amount of buffered packets > and therefore the potential for duplication. > If during handoff, the MN (or) the old FA get information(trigger) about handoff before the actual handoff takes place, passing this information to new FA through some upper layer protocol may itself induce some delay. In that time, actual, L2 handoff may have already have started....Of course, if this trigger information is passed fast enough, it may help in Handover-smoothing... This delay is even more when the Acess router and access point are at different points in the network..What I feel is, some other Layer-3 protocol should be written to reduce this delay...instead of relying on Layer-2 triggers... > > Another way to mitigate it is to make sure the wired network is > properly provisioned for the expected amount of traffic, to > reduce the possibility of congestion and thus jitter. This will > not, of course, solve the problem of the radio link on the > oFA slowing down. That can be mitigated with reducing cell > sizes, etc. to avoid overloading, but, in general, if the > radio propagation conditions become poor enough that retransmits > are necessary, as you point out, oFA could lag behind the > bicast stream. > > In general, I don't know any way to synchronize packet delivery > between oFA and nFA. I believe CDMA does this by having a > very short window (something like 20 ms) during which soft handover > occurs, and using GPS (in cdma2000) to synchronize soft handover > between BTSs. This is not possible in IP, if for no other reason than > the packet sizes can vary, and not all radio protocols have access > to GPS synchronization. There are a variety of heurstics that > could be used, however, and I think it makes sense to write > them down. > > jak > > >From: "Hongyi Li" > >To: "'mobile-ip@sunroof.eng.sun.com'" > >Subject: RE: [mobile-ip] Handover Smoothing - What to Do? > >Date: Tue, 24 Jul 2001 15:37:27 -0400 > > > >See my comments inline > > > >-Hongyi > > > >> -----Original Message----- > >> From: Karim El-Malki (ERA) [mailto:Karim.El-Malki@era.ericsson.se] > >> Sent: Tuesday, July 24, 2001 12:44 PM > >> To: 'mobile-ip@sunroof.eng.sun.com' > >> Subject: RE: [mobile-ip] Handover Smoothing - What to Do? > >> > >> > >> Comments inline. > >> > >> -----Original Message----- > >> From: Hongyi Li [mailto:hyli@nortelnetworks.com] > >> Sent: den 24 juli 2001 18:27 > >> To: 'mobile-ip@sunroof.eng.sun.com' > >> Subject: RE: [mobile-ip] Handover Smoothing - What to Do? > >> > >> > >> Hi Karim, > >> I think George was right in this point. > >> For a single interface MN, if there is no synchronization > >> between the > >> two FAs, the MN will experience either packet loss or packet > >> duplication > >> depending on the direction of the handoff. > >> Here is an example, at time t, assume FA1 is transmitting > >> packet with > >> seq no. x; FA2 is transmitting packet with seq no. x+2. > >> > >> >> Why is it transmitting x+2? It would be x-2 if FA2 (nFA) > >> is buffering. > >> >> If so my suggestion was to set the buffer to the L2 > >> handoff duration. > > > >[hyli] this is just to show the different transmission speeds on > >the two bicasting legs. The transmission speed depends on the traffic > >conditions on different legs that include radio links as well. I don't > >think we can over provisioning radio links in near future. > >Buffering at the new FA still doesn't solve the problem. This is > >because the transmission speed at old FA still matters. Let's assume > >for example bicasting started with packet of seq no. x. If the old FA > >is transmitting x-2 at handoff (due to poor radio link), packet x-1 > >will be lost; if the old AR is transmitting x+2 at handoff (good radio > >link), the MN has packet duplication. > > > > > >> > >> If the MN handoff > >> from FA1 to FA2, packet x+1 will be lost. If the MN handoff > >> from FA2 to FA1 > >> the MN will receive duplicated packet x+1. > >> Buffering without synchronization won't help here. > >> > >> >> does it take zero time to perform a L2 handoff in this example? > >> >> If it does then I would expect FA2 to transmit x, while > >> FA1 transmits x. > >> >> Then you don't have packet loss or duplication. > > > >[hyli] Whether handoff takes zero time or dt is not important here. If a > >system wants both FAs transmit x at the same time, good synchronization > >mechanism is needed. 2G CDMA systems implement this synchronization > >in soft handoff. However, this synchronization reduces the overall > >throughput of the CDMA systems. You may find some HDR papers that explain > >this problem. > > > >> > >> > >> > -----Original Message----- > >> > From: Karim El-Malki (ERA) [mailto:Karim.El-Malki@era.ericsson.se] > >> > Sent: Tuesday, July 24, 2001 12:03 PM > >> > To: 'mobile-ip@sunroof.eng.sun.com' > >> > Subject: RE: [mobile-ip] Handover Smoothing - What to Do? > >> > > >> > > >> > > GT> The nFA has no way of know at which point the > >> > > transmission was severed > >> > > at the oldFA...i.e.: if the bicasted packets are buffered > >> > at the newFA > >> > > (which I assume they will so this is useful) the TCP > >> issues remain! > >> > > >> > Just a quick answer to this point. You're assuming that you > >> > will buffer > >> > and that may not be needed. It's a MAY in low-latency. If you > >> > do buffer, > >> > and have a fixed buffer/delay at nFA of the size of the > >> > duration of the > >> > L2 handoff (when the MN is disconnected at L2 while moving > >> between oFA > >> > and nFA) then you shouldn't get duplicates. That's a > >> possible solution > >> > since the L2 handover period is normally known in wireless systems. > >> > > >> > Rgds > >> > /Karim > >> > > >> -- Sridhar Guriviredddy, Alcatel- Network Strategic Group, Richardson, TX-75080 Ph: 972.996.2048 From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 24 21:37:09 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA06513 for ; Tue, 24 Jul 2001 21:37:08 -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 SAA01948; Tue, 24 Jul 2001 18:37: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 SAA14767; Tue, 24 Jul 2001 18:37:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6P1ZKe22850 for mobile-ip-dist; Tue, 24 Jul 2001 18:35:20 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6P1ZGY22843 for ; Tue, 24 Jul 2001 18:35:16 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA29971 for ; Tue, 24 Jul 2001 18:35:31 -0700 (PDT) Received: from fluorine.mcis.singnet.com.sg (fluorine.singnet.com.sg [165.21.74.72]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA25998 for ; Tue, 24 Jul 2001 18:35:29 -0700 (PDT) Received: from mail pickup service by fluorine.mcis.singnet.com.sg with Microsoft SMTPSVC; Wed, 25 Jul 2001 09:32:00 +0800 Received: from mx16.singnet.com.sg ([165.21.74.116]) by tellurium.mcis.singnet.com.sg with Microsoft SMTPSVC(5.5.1877.687.68); Wed, 25 Jul 2001 06:13:43 +0800 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by mx16.singnet.com.sg (8.11.4/8.11.3) with ESMTP id f6OMAjR23595 for ; Wed, 25 Jul 2001 06:10:46 +0800 Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA18656; Tue, 24 Jul 2001 15:00: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 OAA04349; Tue, 24 Jul 2001 14:58:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6OLu0F21469 for mobile-ip-dist; Tue, 24 Jul 2001 14:56:00 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6OLtvY21462 for ; Tue, 24 Jul 2001 14:55:57 -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 OAA04769 for ; Tue, 24 Jul 2001 14:56:12 -0700 (PDT) Received: from zcars0m9.ca.nortel.com ([47.129.242.157]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA15589 for ; Tue, 24 Jul 2001 15:57:36 -0600 (MDT) Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f6OLti924397 for ; Tue, 24 Jul 2001 17:55:44 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.ca.nortel.com; Tue, 24 Jul 2001 17:55:46 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Jul 2001 17:55:48 -0400 Message-ID: From: "Hongyi Li" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Handover Smoothing - What to Do? Date: Tue, 24 Jul 2001 17:55:47 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1148B.651DB560" X-Orig: List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: 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_01C1148B.651DB560 Content-Type: text/plain; charset="iso-8859-1" Hi James, My comments are inline. Rgds Hongyi > -----Original Message----- > From: James Kempf [mailto:James.Kempf@Sun.COM] > Sent: Tuesday, July 24, 2001 4:39 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: RE: [mobile-ip] Handover Smoothing - What to Do? > > > Hongyi, > > I agree with your analysis. Basically, what you are saying is that > there can be jitter between the old link and the new that could > result in duplicated packets going to the MN on the new link, > correct? Yes. Jitter between old and new links could result in packet duplication or packet loss in bicasting. > > One way to mitigate this problem is for the FA to get better > handover sequencing information from L2. For example, if nFA > gets an L2 trigger when L2 handover begins, it can start buffering > until the new L2 is fully stabilized. This reduces the window > during which the nFA is buffering. Although it won't synchronize > packet delivery, it will reduce the amount of buffered packets > and therefore the potential for duplication. > > Another way to mitigate it is to make sure the wired network is > properly provisioned for the expected amount of traffic, to > reduce the possibility of congestion and thus jitter. This will > not, of course, solve the problem of the radio link on the > oFA slowing down. That can be mitigated with reducing cell > sizes, etc. to avoid overloading, but, in general, if the > radio propagation conditions become poor enough that retransmits > are necessary, as you point out, oFA could lag behind the > bicast stream. > > In general, I don't know any way to synchronize packet delivery > between oFA and nFA. I believe CDMA does this by having a > very short window (something like 20 ms) during which soft handover > occurs, and using GPS (in cdma2000) to synchronize soft handover > between BTSs. This is not possible in IP, if for no other reason than > the packet sizes can vary, and not all radio protocols have access > to GPS synchronization. There are a variety of heurstics that > could be used, however, and I think it makes sense to write > them down. I agree that it is very difficult to implement CDMA type of synchronization mechanism in IP layer. Based on the perceived value and cost of implementing such a sync. mechanism, it would be better to use heuristics to reduce the packet duplication or loss. The heuristics can be used by network operators for improving their network performance if bicasting is used. > > jak > > >From: "Hongyi Li" > >To: "'mobile-ip@sunroof.eng.sun.com'" > >Subject: RE: [mobile-ip] Handover Smoothing - What to Do? > >Date: Tue, 24 Jul 2001 15:37:27 -0400 > > > >See my comments inline > > > >-Hongyi > > > >> -----Original Message----- > >> From: Karim El-Malki (ERA) [mailto:Karim.El-Malki@era.ericsson.se] > >> Sent: Tuesday, July 24, 2001 12:44 PM > >> To: 'mobile-ip@sunroof.eng.sun.com' > >> Subject: RE: [mobile-ip] Handover Smoothing - What to Do? > >> > >> > >> Comments inline. > >> > >> -----Original Message----- > >> From: Hongyi Li [mailto:hyli@nortelnetworks.com] > >> Sent: den 24 juli 2001 18:27 > >> To: 'mobile-ip@sunroof.eng.sun.com' > >> Subject: RE: [mobile-ip] Handover Smoothing - What to Do? > >> > >> > >> Hi Karim, > >> I think George was right in this point. > >> For a single interface MN, if there is no synchronization > >> between the > >> two FAs, the MN will experience either packet loss or packet > >> duplication > >> depending on the direction of the handoff. > >> Here is an example, at time t, assume FA1 is transmitting > >> packet with > >> seq no. x; FA2 is transmitting packet with seq no. x+2. > >> > >> >> Why is it transmitting x+2? It would be x-2 if FA2 (nFA) > >> is buffering. > >> >> If so my suggestion was to set the buffer to the L2 > >> handoff duration. > > > >[hyli] this is just to show the different transmission speeds on > >the two bicasting legs. The transmission speed depends on the traffic > >conditions on different legs that include radio links as > well. I don't > >think we can over provisioning radio links in near future. > >Buffering at the new FA still doesn't solve the problem. This is > >because the transmission speed at old FA still matters. Let's assume > >for example bicasting started with packet of seq no. x. If the old FA > >is transmitting x-2 at handoff (due to poor radio link), packet x-1 > >will be lost; if the old AR is transmitting x+2 at handoff > (good radio > >link), the MN has packet duplication. > > > > > >> > >> If the MN handoff > >> from FA1 to FA2, packet x+1 will be lost. If the MN handoff > >> from FA2 to FA1 > >> the MN will receive duplicated packet x+1. > >> Buffering without synchronization won't help here. > >> > >> >> does it take zero time to perform a L2 handoff in this example? > >> >> If it does then I would expect FA2 to transmit x, while > >> FA1 transmits x. > >> >> Then you don't have packet loss or duplication. > > > >[hyli] Whether handoff takes zero time or dt is not > important here. If a > >system wants both FAs transmit x at the same time, good > synchronization > >mechanism is needed. 2G CDMA systems implement this synchronization > >in soft handoff. However, this synchronization reduces the overall > >throughput of the CDMA systems. You may find some HDR papers > that explain > >this problem. > > > >> > >> > >> > -----Original Message----- > >> > From: Karim El-Malki (ERA) [mailto:Karim.El-Malki@era.ericsson.se] >> > Sent: Tuesday, July 24, 2001 12:03 PM >> > To: 'mobile-ip@sunroof.eng.sun.com' >> > Subject: RE: [mobile-ip] Handover Smoothing - What to Do? >> > >> > >> > > GT> The nFA has no way of know at which point the >> > > transmission was severed >> > > at the oldFA...i.e.: if the bicasted packets are buffered >> > at the newFA >> > > (which I assume they will so this is useful) the TCP >> issues remain! >> > >> > Just a quick answer to this point. You're assuming that you >> > will buffer >> > and that may not be needed. It's a MAY in low-latency. If you >> > do buffer, >> > and have a fixed buffer/delay at nFA of the size of the >> > duration of the >> > L2 handoff (when the MN is disconnected at L2 while moving >> between oFA >> > and nFA) then you shouldn't get duplicates. That's a >> possible solution >> > since the L2 handover period is normally known in wireless systems. >> > >> > Rgds >> > /Karim >> > >> ------_=_NextPart_001_01C1148B.651DB560 Content-Type: text/html; charset="iso-8859-1" RE: [mobile-ip] Handover Smoothing - What to Do?

Hi James,
 
  My comments are inline.


Rgds

Hongyi



> -----Original Message-----
> From: James Kempf [mailto:James.Kempf@Sun.COM]
> Sent: Tuesday, July 24, 2001 4:39 PM
> To: mobile-ip@sunroof.eng.sun.com
> Subject: RE: [mobile-ip] Handover Smoothing - What to Do?
>
>
> Hongyi,
>
> I agree  with your analysis. Basically, what you are saying is that
> there can be jitter between the old link and the new that could
> result in duplicated packets going to the MN on the new link,
> correct?

Yes. Jitter between old and new links could result in packet duplication
or packet loss in bicasting.

>
> One way to mitigate this problem is for the FA to get better
> handover sequencing information from L2. For example, if nFA
> gets an L2 trigger when L2 handover begins, it can start buffering
> until the new L2 is fully stabilized. This reduces the window
> during which the nFA is buffering. Although it won't synchronize
> packet delivery, it will reduce the amount of buffered packets
> and therefore the potential for duplication.
>
> Another way to mitigate it is to make sure the wired network is
> properly provisioned for the expected amount of traffic, to
> reduce the possibility of congestion and thus jitter. This will
> not, of course, solve the problem of the radio link on the
> oFA slowing down. That can be mitigated with reducing cell
> sizes, etc. to avoid overloading, but, in general, if the
> radio propagation conditions become poor enough that retransmits
> are necessary, as you point out, oFA could lag behind the
> bicast stream.
>
> In general, I don't know any way to synchronize packet delivery
> between oFA and nFA. I believe CDMA does this by having a
> very short window (something like 20 ms) during which soft handover
> occurs, and using GPS (in cdma2000) to synchronize soft handover
> between BTSs. This is not possible in IP, if for no other reason than
> the packet sizes can vary, and not all radio protocols have access
> to GPS synchronization. There are a variety of heurstics that
> could be used, however, and I think it makes sense to write
> them down.

I agree that it is very difficult to implement CDMA type of
synchronization mechanism in IP layer. Based on the perceived value and
cost of implementing such a sync. mechanism, it would be better
to use heuristics to reduce the packet duplication or loss. The
heuristics can be used by network operators for improving their
network performance if bicasting is used.




>
>               jak
>
> >From: "Hongyi Li" <hyli@nortelnetworks.com>
> >To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
> >Subject: RE: [mobile-ip] Handover Smoothing - What to Do?
> >Date: Tue, 24 Jul 2001 15:37:27 -0400
> >
> >See my comments inline
> >
> >-Hongyi
> >
> >> -----Original Message-----
> >> From: Karim El-Malki (ERA) [mailto:Karim.El-Malki@era.ericsson.se]
> >> Sent: Tuesday, July 24, 2001 12:44 PM
> >> To: 'mobile-ip@sunroof.eng.sun.com'
> >> Subject: RE: [mobile-ip] Handover Smoothing - What to Do?
> >>
> >>
> >> Comments inline.
> >>
> >> -----Original Message-----
> >> From: Hongyi Li [mailto:hyli@nortelnetworks.com]
> >> Sent: den 24 juli 2001 18:27
> >> To: 'mobile-ip@sunroof.eng.sun.com'
> >> Subject: RE: [mobile-ip] Handover Smoothing - What to Do?
> >>
> >>
> >> Hi Karim,
> >>   I think George was right in this point.
> >>   For a single interface MN, if there is no synchronization
> >> between the
> >> two FAs, the MN will experience either packet loss or packet
> >> duplication
> >> depending on the direction of the handoff.
> >>   Here is an example, at time t, assume FA1 is transmitting
> >> packet with
> >> seq no. x; FA2 is transmitting packet with seq no. x+2.
> >>
> >> >> Why is it transmitting x+2? It would be x-2 if FA2 (nFA)
> >> is buffering.
> >> >> If so my suggestion was to set the buffer to the L2
> >> handoff duration.
> >
> >[hyli] this is just to show the different transmission speeds on
> >the two bicasting legs. The transmission speed depends on the traffic
> >conditions on different legs that include radio links as
> well. I don't
> >think we can over provisioning radio links in near future.
> >Buffering at the new FA still doesn't solve the problem. This is
> >because the transmission speed at old FA still matters. Let's assume
> >for example bicasting started with packet of seq no. x. If the old FA
> >is transmitting x-2 at handoff (due to poor radio link), packet x-1
> >will be lost; if the old AR is transmitting x+2 at handoff
> (good radio
> >link), the MN has packet duplication.
> >
> >
> >>
> >>  If the MN handoff
> >> from FA1 to FA2, packet x+1 will be lost. If the MN handoff
> >> from FA2 to FA1
> >> the MN will receive duplicated packet x+1.
> >>   Buffering without synchronization won't help here.
> >>
> >> >> does it take zero time to perform a L2 handoff in this example?
> >> >> If it does then I would expect FA2 to transmit x, while
> >> FA1 transmits x.
> >> >> Then you don't have packet loss or duplication.
> >
> >[hyli] Whether handoff takes zero time or dt is not
> important here. If a
> >system wants both FAs transmit x at the same time, good
> synchronization
> >mechanism is needed. 2G CDMA systems implement this synchronization
> >in soft handoff. However, this synchronization reduces the overall
> >throughput of the CDMA systems. You may find some HDR papers
> that explain
> >this problem.
> > 
> >>
> >>
> >> > -----Original Message-----
> >> > From: Karim El-Malki (ERA)
[mailto:Karim.El-Malki@era.ericsson.se]
>> > Sent: Tuesday, July 24, 2001 12:03 PM
>> > To: 'mobile-ip@sunroof.eng.sun.com'
>> > Subject: RE: [mobile-ip] Handover Smoothing - What to Do?
>> >
>> >
>> > > GT> The nFA has no way of know at which point the
>> > > transmission was severed
>> > > at the oldFA...i.e.: if the bicasted packets are buffered
>> > at the newFA
>> > > (which I assume they will so this is useful) the TCP
>> issues remain!
>> >
>> > Just a quick answer to this point. You're assuming that you
>> > will buffer
>> > and that may not be needed. It's a MAY in low-latency. If you
>> > do buffer,
>> > and have a fixed buffer/delay at nFA of the size of the
>> > duration of the
>> > L2 handoff (when the MN is disconnected at L2 while moving
>> between oFA
>> > and nFA) then you shouldn't get duplicates. That's a
>> possible solution
>> > since the L2 handover period is normally known in wireless systems.
>> >
>> > Rgds
>> > /Karim
>> >
>>

------_=_NextPart_001_01C1148B.651DB560-- From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 24 21:39:43 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA06629 for ; Tue, 24 Jul 2001 21:39:42 -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 SAA02619; Tue, 24 Jul 2001 18:40:26 -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 SAA15835; Tue, 24 Jul 2001 18:40:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6P1coX23288 for mobile-ip-dist; Tue, 24 Jul 2001 18:38:50 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6P1cfY23229 for ; Tue, 24 Jul 2001 18:38:41 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA20960 for ; Tue, 24 Jul 2001 18:38:52 -0700 (PDT) Received: from fluorine.mcis.singnet.com.sg (fluorine.singnet.com.sg [165.21.74.72]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA27025 for ; Tue, 24 Jul 2001 18:38:51 -0700 (PDT) Received: from mail pickup service by fluorine.mcis.singnet.com.sg with Microsoft SMTPSVC; Wed, 25 Jul 2001 09:33:46 +0800 Received: from mx13.singnet.com.sg ([165.21.74.113]) by tellurium.mcis.singnet.com.sg with Microsoft SMTPSVC(5.5.1877.687.68); Wed, 25 Jul 2001 06:16:43 +0800 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by mx13.singnet.com.sg (8.11.4/8.11.3) with ESMTP id f6OMGiN32295 for ; Wed, 25 Jul 2001 06:16:45 +0800 Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA20195; Tue, 24 Jul 2001 15:03:04 -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 PAA05077; Tue, 24 Jul 2001 15:01:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6OLwuK21503 for mobile-ip-dist; Tue, 24 Jul 2001 14:58:56 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6OLwqY21494 for ; Tue, 24 Jul 2001 14:58: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 OAA20188 for ; Tue, 24 Jul 2001 14:59:07 -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 PAA15031 for ; Tue, 24 Jul 2001 15:59:04 -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 OAA03935; Tue, 24 Jul 2001 14:57:01 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6OLuxI12676; Tue, 24 Jul 2001 14:56:59 -0700 X-mProtect: Tue, 24 Jul 2001 14:56:59 -0700 Nokia Silicon Valley Messaging Protection Received: from vijayd.iprg.nokia.com (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdazp7Cg; Tue, 24 Jul 2001 14:56:56 PDT Message-ID: <3B5DEF29.CE1C831D@iprg.nokia.com> Date: Tue, 24 Jul 2001 14:56:57 -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: mobile-ip@sunroof.eng.sun.com CC: Alexis , Phil Roberts , "Basavaraj Patil (NTC/Dallas)" , Abha Ahuja , Thomas Narten , Dave Johnson , Jeff Schiller , Marcus Leech , Pekka Nikander Subject: Re: [Fwd: [mobile-ip] Mobile IPv6 clarifications] References: <200107241727.f6OHRlS08219@thunk.east.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: 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 thought the real problem with the use of IPSec was with distinguishing a destination options header containing a BU and a destination options header containing some other option. this is not possible with current IPsec selectors. at least this is what Jeff Schiller said in his presentation at the minneapolis IETF. if piggybacking a BU was the problem, we could have solved it long back. just disallow piggybacking. anyway its a 'MAY' in the current draft. you dont lose much by not piggybacking the BU. of course, the other problem is the lack of a global PKI. Bill Sommerfeld wrote: > If I receive an AH-protected packet containing a binding update and a > TCP SYN, a receiver cannot know for sure whether the sender intended > the AH protection to apply just to the binding update, or also to > subsequent packets that are part of the TCP connection. dont sent those two together, then. you dont HAVE to piggyback. vijay > While I thought this option had been beaten to death, if folks still > want to use IPsec to protect MN/CN traffic, here are two possible ways > to deal: > > 1) disallow piggybacking, and always send binding updates separately > from user traffic. > > 2) since you've already paid the cost of setting up the IPsec > security associations, you might as well just keep using them -- once > a binding is established, *all* traffic between the MN and the CN > should be protected the same way. > > Note that even with this issue resolved, you still have to deal with > the PKI/authentication/etc. issues involved with SA setup; if > anything, this is a much harder problem.. > > - Bill From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 25 03:48:30 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA03698 for ; Wed, 25 Jul 2001 03:48: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 BAA10732; Wed, 25 Jul 2001 01:49: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 AAA02980; Wed, 25 Jul 2001 00:48:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6P7knG26437 for mobile-ip-dist; Wed, 25 Jul 2001 00:46:50 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6P7kkY26430 for ; Wed, 25 Jul 2001 00:46:46 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA23803 for ; Wed, 25 Jul 2001 00:47:00 -0700 (PDT) Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA26774 for ; Wed, 25 Jul 2001 00:46:59 -0700 (PDT) Received: from inrialpes.fr (glandon.inrialpes.fr [194.199.24.105]) by ebene.inrialpes.fr (8.11.3/8.11.3) with ESMTP id f6P7ga411565; Wed, 25 Jul 2001 09:42:36 +0200 (MEST) Message-ID: <3B5E7900.1CB3B95F@inrialpes.fr> Date: Wed, 25 Jul 2001 09:45:04 +0200 From: Claude Castelluccia X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jean-Michel COMBES CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Question on draft-team-mobileip-mipv6-sec-reqts-00.txt References: <697DAA22C5004B4596E033803A7CEF440860AD@daebe007.NOE.Nokia.com> <3B5DA26F.1D35859C@francetelecom.com> Content-Type: multipart/alternative; boundary="------------B7BCC2E7622A75586C7436E4" 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: --------------B7BCC2E7622A75586C7436E4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jean-Michel COMBES wrote: > Hi, > > JMC : In my point of view, the result is like a static host using spoofing > ... the only threat that is specific to MIPv6 is on MN using an > unauthorized H@ when it sends BU. Jean-Michel... sure....but in the static host case one might think that "ingress filtering" might help solving this specific problem sometimes... With the HomeAddress option, ingress filtering can't do anything for you (because the source address is topologically correct)... this makes the problem more difficult to solve and definetly different that the static host case.... I don't think you can argue that "this threat is not specific to MIPv6"....it is! Claude. -- ---------------------------------------- Claude CASTELLUCCIA, INRIA Rhone-Alpes ph: +33 4.76.61.52.15 (fax: 52.52) http://www.inrialpes.fr/planete/ --------------B7BCC2E7622A75586C7436E4 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Jean-Michel COMBES wrote:
Hi,

JMC : In my point of view, the result is like a static host using spoofing
... the only threat that is specific to MIPv6 is on MN using an
unauthorized H@ when it sends BU.

Jean-Michel...

sure....but in the static host case one might think that "ingress filtering" might help
solving this specific problem sometimes...
With the HomeAddress option, ingress filtering can't do anything for you (because
the source address is topologically correct)... this makes the problem more difficult to
solve and definetly different that the static host case....
I don't think you can argue that "this threat is not specific to MIPv6"....it is!

Claude.
  

-- 

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes  
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/
  --------------B7BCC2E7622A75586C7436E4-- From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 25 03:51:06 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA03789 for ; Wed, 25 Jul 2001 03:51:06 -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 BAA11765; Wed, 25 Jul 2001 01:51: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 AAA03120; Wed, 25 Jul 2001 00:51:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6P7nkS26477 for mobile-ip-dist; Wed, 25 Jul 2001 00:49:46 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6P7ngY26469 for ; Wed, 25 Jul 2001 00:49:42 -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 AAA23999 for ; Wed, 25 Jul 2001 00:49:56 -0700 (PDT) Received: from explore.kwangwoon.ac.kr ([128.134.70.30]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA08964 for ; Wed, 25 Jul 2001 01:51:19 -0600 (MDT) Received: from ics-svr3 (ics-svr3.kwangwoon.ac.kr [128.134.70.20]) by explore.kwangwoon.ac.kr (8.9.3/8.9.3) with SMTP id QAA28306; Wed, 25 Jul 2001 16:44:19 +0900 (KST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA10759; Wed, 25 Jul 2001 01:49: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 AAA02980; Wed, 25 Jul 2001 00:48:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6P7knG26437 for mobile-ip-dist; Wed, 25 Jul 2001 00:46:50 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6P7kkY26430 for ; Wed, 25 Jul 2001 00:46:46 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA23803 for ; Wed, 25 Jul 2001 00:47:00 -0700 (PDT) Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA26774 for ; Wed, 25 Jul 2001 00:46:59 -0700 (PDT) Received: from inrialpes.fr (glandon.inrialpes.fr [194.199.24.105]) by ebene.inrialpes.fr (8.11.3/8.11.3) with ESMTP id f6P7ga411565; Wed, 25 Jul 2001 09:42:36 +0200 (MEST) Message-ID: <3B5E7900.1CB3B95F@inrialpes.fr> Date: Wed, 25 Jul 2001 09:45:04 +0200 From: Claude Castelluccia X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jean-Michel COMBES CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Question on draft-team-mobileip-mipv6-sec-reqts-00.txt References: <697DAA22C5004B4596E033803A7CEF440860AD@daebe007.NOE.Nokia.com> <3B5DA26F.1D35859C@francetelecom.com> Content-Type: multipart/alternative; boundary="------------B7BCC2E7622A75586C7436E4" List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: 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: --------------B7BCC2E7622A75586C7436E4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jean-Michel COMBES wrote: > Hi, > > JMC : In my point of view, the result is like a static host using spoofing > ... the only threat that is specific to MIPv6 is on MN using an > unauthorized H@ when it sends BU. Jean-Michel... sure....but in the static host case one might think that "ingress filtering" might help solving this specific problem sometimes... With the HomeAddress option, ingress filtering can't do anything for you (because the source address is topologically correct)... this makes the problem more difficult to solve and definetly different that the static host case.... I don't think you can argue that "this threat is not specific to MIPv6"....it is! Claude. -- ---------------------------------------- Claude CASTELLUCCIA, INRIA Rhone-Alpes ph: +33 4.76.61.52.15 (fax: 52.52) http://www.inrialpes.fr/planete/ --------------B7BCC2E7622A75586C7436E4 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Jean-Michel COMBES wrote:
Hi,

JMC : In my point of view, the result is like a static host using spoofing
... the only threat that is specific to MIPv6 is on MN using an
unauthorized H@ when it sends BU.

Jean-Michel...

sure....but in the static host case one might think that "ingress filtering" might help
solving this specific problem sometimes...
With the HomeAddress option, ingress filtering can't do anything for you (because
the source address is topologically correct)... this makes the problem more difficult to
solve and definetly different that the static host case....
I don't think you can argue that "this threat is not specific to MIPv6"....it is!

Claude.
  

-- 

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes  
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/
  --------------B7BCC2E7622A75586C7436E4-- From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 25 03:51:42 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA03810 for ; Wed, 25 Jul 2001 03:51:42 -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 AAA15511; Wed, 25 Jul 2001 00:52:08 -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 AAA03222; Wed, 25 Jul 2001 00:51:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6P7oO126503 for mobile-ip-dist; Wed, 25 Jul 2001 00:50:24 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6P7oJY26496 for ; Wed, 25 Jul 2001 00:50:20 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA24095 for ; Wed, 25 Jul 2001 00:50:33 -0700 (PDT) Received: from explore.kwangwoon.ac.kr ([128.134.70.30]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA15743 for ; Wed, 25 Jul 2001 00:50:31 -0700 (PDT) Received: from ics-svr3 (ics-svr3.kwangwoon.ac.kr [128.134.70.20]) by explore.kwangwoon.ac.kr (8.9.3/8.9.3) with SMTP id QAA28377; Wed, 25 Jul 2001 16:45:04 +0900 (KST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA11017; Wed, 25 Jul 2001 01:49:44 -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 AAA02972; Wed, 25 Jul 2001 00:48:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6P7knG26437 for mobile-ip-dist; Wed, 25 Jul 2001 00:46:50 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6P7kkY26430 for ; Wed, 25 Jul 2001 00:46:46 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA23803 for ; Wed, 25 Jul 2001 00:47:00 -0700 (PDT) Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA26774 for ; Wed, 25 Jul 2001 00:46:59 -0700 (PDT) Received: from inrialpes.fr (glandon.inrialpes.fr [194.199.24.105]) by ebene.inrialpes.fr (8.11.3/8.11.3) with ESMTP id f6P7ga411565; Wed, 25 Jul 2001 09:42:36 +0200 (MEST) Message-ID: <3B5E7900.1CB3B95F@inrialpes.fr> Date: Wed, 25 Jul 2001 09:45:04 +0200 From: Claude Castelluccia X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jean-Michel COMBES CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Question on draft-team-mobileip-mipv6-sec-reqts-00.txt References: <697DAA22C5004B4596E033803A7CEF440860AD@daebe007.NOE.Nokia.com> <3B5DA26F.1D35859C@francetelecom.com> Content-Type: multipart/alternative; boundary="------------B7BCC2E7622A75586C7436E4" List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: 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: --------------B7BCC2E7622A75586C7436E4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jean-Michel COMBES wrote: > Hi, > > JMC : In my point of view, the result is like a static host using spoofing > ... the only threat that is specific to MIPv6 is on MN using an > unauthorized H@ when it sends BU. Jean-Michel... sure....but in the static host case one might think that "ingress filtering" might help solving this specific problem sometimes... With the HomeAddress option, ingress filtering can't do anything for you (because the source address is topologically correct)... this makes the problem more difficult to solve and definetly different that the static host case.... I don't think you can argue that "this threat is not specific to MIPv6"....it is! Claude. -- ---------------------------------------- Claude CASTELLUCCIA, INRIA Rhone-Alpes ph: +33 4.76.61.52.15 (fax: 52.52) http://www.inrialpes.fr/planete/ --------------B7BCC2E7622A75586C7436E4 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Jean-Michel COMBES wrote:
Hi,

JMC : In my point of view, the result is like a static host using spoofing
... the only threat that is specific to MIPv6 is on MN using an
unauthorized H@ when it sends BU.

Jean-Michel...

sure....but in the static host case one might think that "ingress filtering" might help
solving this specific problem sometimes...
With the HomeAddress option, ingress filtering can't do anything for you (because
the source address is topologically correct)... this makes the problem more difficult to
solve and definetly different that the static host case....
I don't think you can argue that "this threat is not specific to MIPv6"....it is!

Claude.
  

-- 

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes  
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/
  --------------B7BCC2E7622A75586C7436E4-- From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 25 03:53:43 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA03866 for ; Wed, 25 Jul 2001 03:53:43 -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 BAA13621; Wed, 25 Jul 2001 01:54: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 AAA03858; Wed, 25 Jul 2001 00:54:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6P7qJv26675 for mobile-ip-dist; Wed, 25 Jul 2001 00:52:19 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6P7qEY26657 for ; Wed, 25 Jul 2001 00:52:14 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA18564 for ; Wed, 25 Jul 2001 00:52:27 -0700 (PDT) Received: from explore.kwangwoon.ac.kr ([128.134.70.30]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA16590 for ; Wed, 25 Jul 2001 00:52:24 -0700 (PDT) Received: from ics-svr3 (ics-svr3.kwangwoon.ac.kr [128.134.70.20]) by explore.kwangwoon.ac.kr (8.9.3/8.9.3) with SMTP id QAA28530; Wed, 25 Jul 2001 16:46:58 +0900 (KST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA12100; Wed, 25 Jul 2001 01:51:47 -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 AAA03100; Wed, 25 Jul 2001 00:50:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6P7nkS26477 for mobile-ip-dist; Wed, 25 Jul 2001 00:49:46 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6P7ngY26469 for ; Wed, 25 Jul 2001 00:49:42 -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 AAA23999 for ; Wed, 25 Jul 2001 00:49:56 -0700 (PDT) Received: from explore.kwangwoon.ac.kr ([128.134.70.30]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA08964 for ; Wed, 25 Jul 2001 01:51:19 -0600 (MDT) Received: from ics-svr3 (ics-svr3.kwangwoon.ac.kr [128.134.70.20]) by explore.kwangwoon.ac.kr (8.9.3/8.9.3) with SMTP id QAA28306; Wed, 25 Jul 2001 16:44:19 +0900 (KST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA10759; Wed, 25 Jul 2001 01:49: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 AAA02980; Wed, 25 Jul 2001 00:48:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6P7knG26437 for mobile-ip-dist; Wed, 25 Jul 2001 00:46:50 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6P7kkY26430 for ; Wed, 25 Jul 2001 00:46:46 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA23803 for ; Wed, 25 Jul 2001 00:47:00 -0700 (PDT) Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA26774 for ; Wed, 25 Jul 2001 00:46:59 -0700 (PDT) Received: from inrialpes.fr (glandon.inrialpes.fr [194.199.24.105]) by ebene.inrialpes.fr (8.11.3/8.11.3) with ESMTP id f6P7ga411565; Wed, 25 Jul 2001 09:42:36 +0200 (MEST) Message-ID: <3B5E7900.1CB3B95F@inrialpes.fr> Date: Wed, 25 Jul 2001 09:45:04 +0200 From: Claude Castelluccia X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jean-Michel COMBES CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Question on draft-team-mobileip-mipv6-sec-reqts-00.txt References: <697DAA22C5004B4596E033803A7CEF440860AD@daebe007.NOE.Nokia.com> <3B5DA26F.1D35859C@francetelecom.com> Content-Type: multipart/alternative; boundary="------------B7BCC2E7622A75586C7436E4" List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: 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: --------------B7BCC2E7622A75586C7436E4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jean-Michel COMBES wrote: > Hi, > > JMC : In my point of view, the result is like a static host using spoofing > ... the only threat that is specific to MIPv6 is on MN using an > unauthorized H@ when it sends BU. Jean-Michel... sure....but in the static host case one might think that "ingress filtering" might help solving this specific problem sometimes... With the HomeAddress option, ingress filtering can't do anything for you (because the source address is topologically correct)... this makes the problem more difficult to solve and definetly different that the static host case.... I don't think you can argue that "this threat is not specific to MIPv6"....it is! Claude. -- ---------------------------------------- Claude CASTELLUCCIA, INRIA Rhone-Alpes ph: +33 4.76.61.52.15 (fax: 52.52) http://www.inrialpes.fr/planete/ --------------B7BCC2E7622A75586C7436E4 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Jean-Michel COMBES wrote:
Hi,

JMC : In my point of view, the result is like a static host using spoofing
... the only threat that is specific to MIPv6 is on MN using an
unauthorized H@ when it sends BU.

Jean-Michel...

sure....but in the static host case one might think that "ingress filtering" might help
solving this specific problem sometimes...
With the HomeAddress option, ingress filtering can't do anything for you (because
the source address is topologically correct)... this makes the problem more difficult to
solve and definetly different that the static host case....
I don't think you can argue that "this threat is not specific to MIPv6"....it is!

Claude.
  

-- 

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes  
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/
  --------------B7BCC2E7622A75586C7436E4-- From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 25 03:54:52 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA03892 for ; Wed, 25 Jul 2001 03:54:52 -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 BAA14484; Wed, 25 Jul 2001 01:55: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 AAA04457; Wed, 25 Jul 2001 00:54:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6P7qrE26779 for mobile-ip-dist; Wed, 25 Jul 2001 00:52:53 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6P7qjY26756 for ; Wed, 25 Jul 2001 00:52:45 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA24405 for ; Wed, 25 Jul 2001 00:52:59 -0700 (PDT) Received: from explore.kwangwoon.ac.kr ([128.134.70.30]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA16913 for ; Wed, 25 Jul 2001 00:52:56 -0700 (PDT) Received: from ics-svr3 (ics-svr3.kwangwoon.ac.kr [128.134.70.20]) by explore.kwangwoon.ac.kr (8.9.3/8.9.3) with SMTP id QAA28610; Wed, 25 Jul 2001 16:47:29 +0900 (KST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA15530; Wed, 25 Jul 2001 00:52: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 AAA03222; Wed, 25 Jul 2001 00:51:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6P7oO126503 for mobile-ip-dist; Wed, 25 Jul 2001 00:50:24 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6P7oJY26496 for ; Wed, 25 Jul 2001 00:50:20 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA24095 for ; Wed, 25 Jul 2001 00:50:33 -0700 (PDT) Received: from explore.kwangwoon.ac.kr ([128.134.70.30]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA15743 for ; Wed, 25 Jul 2001 00:50:31 -0700 (PDT) Received: from ics-svr3 (ics-svr3.kwangwoon.ac.kr [128.134.70.20]) by explore.kwangwoon.ac.kr (8.9.3/8.9.3) with SMTP id QAA28377; Wed, 25 Jul 2001 16:45:04 +0900 (KST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA11017; Wed, 25 Jul 2001 01:49:44 -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 AAA02972; Wed, 25 Jul 2001 00:48:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6P7knG26437 for mobile-ip-dist; Wed, 25 Jul 2001 00:46:50 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6P7kkY26430 for ; Wed, 25 Jul 2001 00:46:46 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA23803 for ; Wed, 25 Jul 2001 00:47:00 -0700 (PDT) Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA26774 for ; Wed, 25 Jul 2001 00:46:59 -0700 (PDT) Received: from inrialpes.fr (glandon.inrialpes.fr [194.199.24.105]) by ebene.inrialpes.fr (8.11.3/8.11.3) with ESMTP id f6P7ga411565; Wed, 25 Jul 2001 09:42:36 +0200 (MEST) Message-ID: <3B5E7900.1CB3B95F@inrialpes.fr> Date: Wed, 25 Jul 2001 09:45:04 +0200 From: Claude Castelluccia X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jean-Michel COMBES CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Question on draft-team-mobileip-mipv6-sec-reqts-00.txt References: <697DAA22C5004B4596E033803A7CEF440860AD@daebe007.NOE.Nokia.com> <3B5DA26F.1D35859C@francetelecom.com> Content-Type: multipart/alternative; boundary="------------B7BCC2E7622A75586C7436E4" List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: 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: --------------B7BCC2E7622A75586C7436E4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jean-Michel COMBES wrote: > Hi, > > JMC : In my point of view, the result is like a static host using spoofing > ... the only threat that is specific to MIPv6 is on MN using an > unauthorized H@ when it sends BU. Jean-Michel... sure....but in the static host case one might think that "ingress filtering" might help solving this specific problem sometimes... With the HomeAddress option, ingress filtering can't do anything for you (because the source address is topologically correct)... this makes the problem more difficult to solve and definetly different that the static host case.... I don't think you can argue that "this threat is not specific to MIPv6"....it is! Claude. -- ---------------------------------------- Claude CASTELLUCCIA, INRIA Rhone-Alpes ph: +33 4.76.61.52.15 (fax: 52.52) http://www.inrialpes.fr/planete/ --------------B7BCC2E7622A75586C7436E4 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Jean-Michel COMBES wrote:
Hi,

JMC : In my point of view, the result is like a static host using spoofing
... the only threat that is specific to MIPv6 is on MN using an
unauthorized H@ when it sends BU.

Jean-Michel...

sure....but in the static host case one might think that "ingress filtering" might help
solving this specific problem sometimes...
With the HomeAddress option, ingress filtering can't do anything for you (because
the source address is topologically correct)... this makes the problem more difficult to
solve and definetly different that the static host case....
I don't think you can argue that "this threat is not specific to MIPv6"....it is!

Claude.
  

-- 

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes  
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/
  --------------B7BCC2E7622A75586C7436E4-- From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 25 03:55:18 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA03908 for ; Wed, 25 Jul 2001 03:55:17 -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 BAA15004; Wed, 25 Jul 2001 01:55:58 -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 AAA05042; Wed, 25 Jul 2001 00:55:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6P7rQK26874 for mobile-ip-dist; Wed, 25 Jul 2001 00:53:26 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6P7rEY26842 for ; Wed, 25 Jul 2001 00:53: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 AAA24450 for ; Wed, 25 Jul 2001 00:53:28 -0700 (PDT) Received: from explore.kwangwoon.ac.kr ([128.134.70.30]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA13017 for ; Wed, 25 Jul 2001 01:53:21 -0600 (MDT) Received: from ics-svr3 (ics-svr3.kwangwoon.ac.kr [128.134.70.20]) by explore.kwangwoon.ac.kr (8.9.3/8.9.3) with SMTP id QAA28637; Wed, 25 Jul 2001 16:47:55 +0900 (KST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA15714; Wed, 25 Jul 2001 00:52: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 AAA03141; Wed, 25 Jul 2001 00:51:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6P7oO126503 for mobile-ip-dist; Wed, 25 Jul 2001 00:50:24 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6P7oJY26496 for ; Wed, 25 Jul 2001 00:50:20 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA24095 for ; Wed, 25 Jul 2001 00:50:33 -0700 (PDT) Received: from explore.kwangwoon.ac.kr ([128.134.70.30]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA15743 for ; Wed, 25 Jul 2001 00:50:31 -0700 (PDT) Received: from ics-svr3 (ics-svr3.kwangwoon.ac.kr [128.134.70.20]) by explore.kwangwoon.ac.kr (8.9.3/8.9.3) with SMTP id QAA28377; Wed, 25 Jul 2001 16:45:04 +0900 (KST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA11017; Wed, 25 Jul 2001 01:49:44 -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 AAA02972; Wed, 25 Jul 2001 00:48:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6P7knG26437 for mobile-ip-dist; Wed, 25 Jul 2001 00:46:50 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6P7kkY26430 for ; Wed, 25 Jul 2001 00:46:46 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA23803 for ; Wed, 25 Jul 2001 00:47:00 -0700 (PDT) Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA26774 for ; Wed, 25 Jul 2001 00:46:59 -0700 (PDT) Received: from inrialpes.fr (glandon.inrialpes.fr [194.199.24.105]) by ebene.inrialpes.fr (8.11.3/8.11.3) with ESMTP id f6P7ga411565; Wed, 25 Jul 2001 09:42:36 +0200 (MEST) Message-ID: <3B5E7900.1CB3B95F@inrialpes.fr> Date: Wed, 25 Jul 2001 09:45:04 +0200 From: Claude Castelluccia X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jean-Michel COMBES CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Question on draft-team-mobileip-mipv6-sec-reqts-00.txt References: <697DAA22C5004B4596E033803A7CEF440860AD@daebe007.NOE.Nokia.com> <3B5DA26F.1D35859C@francetelecom.com> Content-Type: multipart/alternative; boundary="------------B7BCC2E7622A75586C7436E4" List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: 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: --------------B7BCC2E7622A75586C7436E4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jean-Michel COMBES wrote: > Hi, > > JMC : In my point of view, the result is like a static host using spoofing > ... the only threat that is specific to MIPv6 is on MN using an > unauthorized H@ when it sends BU. Jean-Michel... sure....but in the static host case one might think that "ingress filtering" might help solving this specific problem sometimes... With the HomeAddress option, ingress filtering can't do anything for you (because the source address is topologically correct)... this makes the problem more difficult to solve and definetly different that the static host case.... I don't think you can argue that "this threat is not specific to MIPv6"....it is! Claude. -- ---------------------------------------- Claude CASTELLUCCIA, INRIA Rhone-Alpes ph: +33 4.76.61.52.15 (fax: 52.52) http://www.inrialpes.fr/planete/ --------------B7BCC2E7622A75586C7436E4 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Jean-Michel COMBES wrote:
Hi,

JMC : In my point of view, the result is like a static host using spoofing
... the only threat that is specific to MIPv6 is on MN using an
unauthorized H@ when it sends BU.

Jean-Michel...

sure....but in the static host case one might think that "ingress filtering" might help
solving this specific problem sometimes...
With the HomeAddress option, ingress filtering can't do anything for you (because
the source address is topologically correct)... this makes the problem more difficult to
solve and definetly different that the static host case....
I don't think you can argue that "this threat is not specific to MIPv6"....it is!

Claude.
  

-- 

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes  
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/
  --------------B7BCC2E7622A75586C7436E4-- From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 25 03:56:50 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA03947 for ; Wed, 25 Jul 2001 03:56:50 -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 BAA13436; Wed, 25 Jul 2001 01:54: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 AAA03748; Wed, 25 Jul 2001 00:53:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6P7q5M26621 for mobile-ip-dist; Wed, 25 Jul 2001 00:52:05 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6P7q0Y26603 for ; Wed, 25 Jul 2001 00:52:00 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA18521 for ; Wed, 25 Jul 2001 00:52:09 -0700 (PDT) Received: from explore.kwangwoon.ac.kr ([128.134.70.30]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA16378 for ; Wed, 25 Jul 2001 00:52:03 -0700 (PDT) Received: from ics-svr3 (ics-svr3.kwangwoon.ac.kr [128.134.70.20]) by explore.kwangwoon.ac.kr (8.9.3/8.9.3) with SMTP id QAA28503; Wed, 25 Jul 2001 16:46:32 +0900 (KST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA11791; Wed, 25 Jul 2001 01:51:19 -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 AAA03120; Wed, 25 Jul 2001 00:51:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6P7nkS26477 for mobile-ip-dist; Wed, 25 Jul 2001 00:49:46 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6P7ngY26469 for ; Wed, 25 Jul 2001 00:49:42 -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 AAA23999 for ; Wed, 25 Jul 2001 00:49:56 -0700 (PDT) Received: from explore.kwangwoon.ac.kr ([128.134.70.30]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA08964 for ; Wed, 25 Jul 2001 01:51:19 -0600 (MDT) Received: from ics-svr3 (ics-svr3.kwangwoon.ac.kr [128.134.70.20]) by explore.kwangwoon.ac.kr (8.9.3/8.9.3) with SMTP id QAA28306; Wed, 25 Jul 2001 16:44:19 +0900 (KST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA10759; Wed, 25 Jul 2001 01:49: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 AAA02980; Wed, 25 Jul 2001 00:48:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6P7knG26437 for mobile-ip-dist; Wed, 25 Jul 2001 00:46:50 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6P7kkY26430 for ; Wed, 25 Jul 2001 00:46:46 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA23803 for ; Wed, 25 Jul 2001 00:47:00 -0700 (PDT) Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA26774 for ; Wed, 25 Jul 2001 00:46:59 -0700 (PDT) Received: from inrialpes.fr (glandon.inrialpes.fr [194.199.24.105]) by ebene.inrialpes.fr (8.11.3/8.11.3) with ESMTP id f6P7ga411565; Wed, 25 Jul 2001 09:42:36 +0200 (MEST) Message-ID: <3B5E7900.1CB3B95F@inrialpes.fr> Date: Wed, 25 Jul 2001 09:45:04 +0200 From: Claude Castelluccia X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jean-Michel COMBES CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Question on draft-team-mobileip-mipv6-sec-reqts-00.txt References: <697DAA22C5004B4596E033803A7CEF440860AD@daebe007.NOE.Nokia.com> <3B5DA26F.1D35859C@francetelecom.com> Content-Type: multipart/alternative; boundary="------------B7BCC2E7622A75586C7436E4" List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: 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: --------------B7BCC2E7622A75586C7436E4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jean-Michel COMBES wrote: > Hi, > > JMC : In my point of view, the result is like a static host using spoofing > ... the only threat that is specific to MIPv6 is on MN using an > unauthorized H@ when it sends BU. Jean-Michel... sure....but in the static host case one might think that "ingress filtering" might help solving this specific problem sometimes... With the HomeAddress option, ingress filtering can't do anything for you (because the source address is topologically correct)... this makes the problem more difficult to solve and definetly different that the static host case.... I don't think you can argue that "this threat is not specific to MIPv6"....it is! Claude. -- ---------------------------------------- Claude CASTELLUCCIA, INRIA Rhone-Alpes ph: +33 4.76.61.52.15 (fax: 52.52) http://www.inrialpes.fr/planete/ --------------B7BCC2E7622A75586C7436E4 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Jean-Michel COMBES wrote:
Hi,

JMC : In my point of view, the result is like a static host using spoofing
... the only threat that is specific to MIPv6 is on MN using an
unauthorized H@ when it sends BU.

Jean-Michel...

sure....but in the static host case one might think that "ingress filtering" might help
solving this specific problem sometimes...
With the HomeAddress option, ingress filtering can't do anything for you (because
the source address is topologically correct)... this makes the problem more difficult to
solve and definetly different that the static host case....
I don't think you can argue that "this threat is not specific to MIPv6"....it is!

Claude.
  

-- 

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes  
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/
  --------------B7BCC2E7622A75586C7436E4-- From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 25 06:20:50 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA06924 for ; Wed, 25 Jul 2001 06:20:49 -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 EAA26280; Wed, 25 Jul 2001 04:20:48 -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 DAA01423; Wed, 25 Jul 2001 03:20:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PAJ0A05112 for mobile-ip-dist; Wed, 25 Jul 2001 03:19:00 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PAIuY05105 for ; Wed, 25 Jul 2001 03:18:56 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA01052 for ; Wed, 25 Jul 2001 03:19:08 -0700 (PDT) Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA15463; Wed, 25 Jul 2001 03:19:06 -0700 (PDT) Received: from inrialpes.fr (glandon.inrialpes.fr [194.199.24.105]) by ebene.inrialpes.fr (8.11.3/8.11.3) with ESMTP id f6PAGO815997; Wed, 25 Jul 2001 12:16:24 +0200 (MEST) Message-ID: <3B5E9D0C.84721835@inrialpes.fr> Date: Wed, 25 Jul 2001 12:18:52 +0200 From: Claude Castelluccia X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com, gab@sun.com Subject: Re: [mobile-ip] Question on draft-team-mobileip-mipv6-sec-reqts-00.txt References: <697DAA22C5004B4596E033803A7CEF440860AD@daebe007.NOE.Nokia.com> <3B5DA26F.1D35859C@francetelecom.com> Content-Type: multipart/alternative; boundary="------------F4096A00787F822305497EF7" 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: --------------F4096A00787F822305497EF7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, BTW in relation with the MIPv6 security requirement draft, we (Gabriel Montenegro and myself) have submitted a new version of the SUCV draft. This draft describes the SUCV ID/address concepts and the associated protocol (SUCVp). It also contains a detailled security analysis of it... Comments will be appreciated.... The draft (v1.0) can be retrieved at: http://www.inrialpes.fr/planete/people/ccastel/draft-montenegro-sucv-01.txt enjoy it ;-) Claude. PS: note we do not consider the draft-team-mobileip-mipv6-sec-reqts-00.txt draft in our draft since it was not available at the time we wrote it... -- ---------------------------------------- Claude CASTELLUCCIA, INRIA Rhone-Alpes ph: +33 4.76.61.52.15 (fax: 52.52) http://www.inrialpes.fr/planete/ --------------F4096A00787F822305497EF7 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hello,

BTW in relation with the MIPv6 security requirement draft, we (Gabriel Montenegro and myself)  have submitted
a new version of the SUCV draft.
This draft describes the SUCV ID/address concepts and the associated protocol (SUCVp). It also contains a detailled security
analysis of it...
Comments will be appreciated....
The draft (v1.0) can be retrieved at: http://www.inrialpes.fr/planete/people/ccastel/draft-montenegro-sucv-01.txt

enjoy it ;-)

Claude.

PS: note we do not consider the draft-team-mobileip-mipv6-sec-reqts-00.txt draft in our draft since it was not available
at the time we wrote it...
 
 
 
  

-- 

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes  
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/
  --------------F4096A00787F822305497EF7-- From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 25 06:32:53 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA07467 for ; Wed, 25 Jul 2001 06:32: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 EAA01296; Wed, 25 Jul 2001 04:33:29 -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 DAA22485; Wed, 25 Jul 2001 03:33:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PAVpp05199 for mobile-ip-dist; Wed, 25 Jul 2001 03:31:51 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PAVlY05192 for ; Wed, 25 Jul 2001 03:31:47 -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 DAA02235 for ; Wed, 25 Jul 2001 03:31:59 -0700 (PDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA23183 for ; Wed, 25 Jul 2001 04:33:24 -0600 (MDT) Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f6PAVuO09516 for ; Wed, 25 Jul 2001 12:31:57 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Wed Jul 25 12:31:53 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Jul 2001 12:31:52 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008B51@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Handover Smoothing - What to Do? Date: Wed, 25 Jul 2001 12:31:52 +0200 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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Mike, > > The issue is whether the FMIP work is completely useless without > > smoothing, or whether smoothing is so intertwined with the FMIP > > work that it is impossible to put it into a separate spec. I think > > the fact that the FMIPv6 draft managed to successfully disentangle > > them argues that the smoothing work can be separated out from > > a design perspective. Whether or not FMIP is useless without > > smoothing from an operational or implementation perspective > > is something that can only be determined by experiment. > > I'd say that it's not useless: if you have two interfaces, > FMIP alone is probably sufficient since you can do a make > before break while listening on both for some period of > time. It might be pointed out that you could do that without > the FMIP AR, but latencies back to the CN/HA may require a > more localized solution to achieve a reasonable handoff. > => Yes but if you have two interfaces then I'd argue that anticipation is not needed or not a realistic action to expect. This is due to the fact that most devices with two interfaces are typically connected to different access technologies. It seems unrealistic IMHO to expect a WLAN network to anticipate your movement to a CDMA network and vice versa. All you would need in that case is a localised agent to minimise the BU latencies and the number of BUs sent. FMIP was not designed for the multi-interfaces case or if a system has a carefully designed make before break handover. Hesham From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 25 06:36:37 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA08081 for ; Wed, 25 Jul 2001 06:36:36 -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 DAA29956; Wed, 25 Jul 2001 03:37:05 -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 DAA22797; Wed, 25 Jul 2001 03:36:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PAZjS05315 for mobile-ip-dist; Wed, 25 Jul 2001 03:35:45 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PAZeY05308 for ; Wed, 25 Jul 2001 03:35:40 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA02631 for ; Wed, 25 Jul 2001 03:35:52 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA21093 for ; Wed, 25 Jul 2001 03:35:51 -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 GAA07722; Wed, 25 Jul 2001 06:34:51 -0400 (EDT) Message-Id: <200107251034.GAA07722@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-montenegro-sucv-01.txt Date: Wed, 25 Jul 2001 06:34:51 -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. Title : SUCV Identifiers and Addresses Author(s) : G. Montenegro, C. Castelluccia Filename : draft-montenegro-sucv-01.txt Pages : 23 Date : 24-Jul-01 This document addresses the identifier ownership problem. It does so by using characteristics of Statistic Uniqueness and Cryptographic Verifiability (SUCV) of certain entities which this document calls SUCV Identifiers (SUCV ID's). This note also proposes using these SUCV characteristics in related entities called SUCV Addresses in order to severely limit certain classes of denial of service attacks and hijacking attacks. SUCV addresses are particularly applicable to solve the 'address ownership' problem that severely undermines confidence in mechanisms like Binding Updates in Mobile IP for IPv6. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-montenegro-sucv-01.txt 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-montenegro-sucv-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-montenegro-sucv-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: <20010724132501.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-montenegro-sucv-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-montenegro-sucv-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010724132501.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 25 06:39:11 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA08229 for ; Wed, 25 Jul 2001 06:39:10 -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 EAA04916; Wed, 25 Jul 2001 04:39: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 DAA23047; Wed, 25 Jul 2001 03:39:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PAcLp05521 for mobile-ip-dist; Wed, 25 Jul 2001 03:38:21 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PAcEY05506 for ; Wed, 25 Jul 2001 03:38: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 DAA02322 for ; Wed, 25 Jul 2001 03:38:26 -0700 (PDT) Received: from explore.kwangwoon.ac.kr ([128.134.70.30]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA03930 for ; Wed, 25 Jul 2001 04:38:23 -0600 (MDT) Received: from ics-svr3 (ics-svr3.kwangwoon.ac.kr [128.134.70.20]) by explore.kwangwoon.ac.kr (8.9.3/8.9.3) with SMTP id TAA09778; Wed, 25 Jul 2001 19:32:57 +0900 (KST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA03566; Wed, 25 Jul 2001 04:37:44 -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 DAA22782; Wed, 25 Jul 2001 03:36:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PAZjS05315 for mobile-ip-dist; Wed, 25 Jul 2001 03:35:45 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PAZeY05308 for ; Wed, 25 Jul 2001 03:35:40 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA02631 for ; Wed, 25 Jul 2001 03:35:52 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA21093 for ; Wed, 25 Jul 2001 03:35:51 -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 GAA07722; Wed, 25 Jul 2001 06:34:51 -0400 (EDT) Message-Id: <200107251034.GAA07722@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-montenegro-sucv-01.txt Date: Wed, 25 Jul 2001 06:34:51 -0400 List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: 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 : SUCV Identifiers and Addresses Author(s) : G. Montenegro, C. Castelluccia Filename : draft-montenegro-sucv-01.txt Pages : 23 Date : 24-Jul-01 This document addresses the identifier ownership problem. It does so by using characteristics of Statistic Uniqueness and Cryptographic Verifiability (SUCV) of certain entities which this document calls SUCV Identifiers (SUCV ID's). This note also proposes using these SUCV characteristics in related entities called SUCV Addresses in order to severely limit certain classes of denial of service attacks and hijacking attacks. SUCV addresses are particularly applicable to solve the 'address ownership' problem that severely undermines confidence in mechanisms like Binding Updates in Mobile IP for IPv6. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-montenegro-sucv-01.txt 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-montenegro-sucv-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-montenegro-sucv-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: <20010724132501.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-montenegro-sucv-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-montenegro-sucv-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010724132501.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 25 06:39:42 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA08272 for ; Wed, 25 Jul 2001 06:39:41 -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 DAA01052; Wed, 25 Jul 2001 03:40: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 DAA23143; Wed, 25 Jul 2001 03:40:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PAcZk05547 for mobile-ip-dist; Wed, 25 Jul 2001 03:38:35 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PAcNY05525 for ; Wed, 25 Jul 2001 03:38:24 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA09373 for ; Wed, 25 Jul 2001 03:38:35 -0700 (PDT) Received: from explore.kwangwoon.ac.kr ([128.134.70.30]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA19440 for ; Wed, 25 Jul 2001 03:38:30 -0700 (PDT) Received: from ics-svr3 (ics-svr3.kwangwoon.ac.kr [128.134.70.20]) by explore.kwangwoon.ac.kr (8.9.3/8.9.3) with SMTP id TAA09809; Wed, 25 Jul 2001 19:33:03 +0900 (KST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA29987; Wed, 25 Jul 2001 03:37:12 -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 DAA22797; Wed, 25 Jul 2001 03:36:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PAZjS05315 for mobile-ip-dist; Wed, 25 Jul 2001 03:35:45 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PAZeY05308 for ; Wed, 25 Jul 2001 03:35:40 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA02631 for ; Wed, 25 Jul 2001 03:35:52 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA21093 for ; Wed, 25 Jul 2001 03:35:51 -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 GAA07722; Wed, 25 Jul 2001 06:34:51 -0400 (EDT) Message-Id: <200107251034.GAA07722@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-montenegro-sucv-01.txt Date: Wed, 25 Jul 2001 06:34:51 -0400 List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: 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 : SUCV Identifiers and Addresses Author(s) : G. Montenegro, C. Castelluccia Filename : draft-montenegro-sucv-01.txt Pages : 23 Date : 24-Jul-01 This document addresses the identifier ownership problem. It does so by using characteristics of Statistic Uniqueness and Cryptographic Verifiability (SUCV) of certain entities which this document calls SUCV Identifiers (SUCV ID's). This note also proposes using these SUCV characteristics in related entities called SUCV Addresses in order to severely limit certain classes of denial of service attacks and hijacking attacks. SUCV addresses are particularly applicable to solve the 'address ownership' problem that severely undermines confidence in mechanisms like Binding Updates in Mobile IP for IPv6. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-montenegro-sucv-01.txt 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-montenegro-sucv-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-montenegro-sucv-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: <20010724132501.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-montenegro-sucv-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-montenegro-sucv-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010724132501.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 25 06:40:42 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA08373 for ; Wed, 25 Jul 2001 06:40:41 -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 EAA06019; Wed, 25 Jul 2001 04:41:15 -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 DAA23334; Wed, 25 Jul 2001 03:41:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PAd2i05595 for mobile-ip-dist; Wed, 25 Jul 2001 03:39:02 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PAcvY05582 for ; Wed, 25 Jul 2001 03:38:57 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA02884 for ; Wed, 25 Jul 2001 03:39:09 -0700 (PDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA19593 for ; Wed, 25 Jul 2001 03:39:08 -0700 (PDT) Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f6PAd6O12760 for ; Wed, 25 Jul 2001 12:39:07 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Wed Jul 25 12:39:03 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Jul 2001 12:39:02 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008B52@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Handover Smoothing - What to Do? Date: Wed, 25 Jul 2001 12:38:56 +0200 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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: James, > I think we agree that specifications of smoothing and fast handoff do not need > to be linked, if only for practical considerations. > => I would like to understand your point here. What difference does it make if we put the smoothing techniques in the same draft (as the low latency draft does) or leave them out (as in the v6 draft) ? If we believe smoothing is essential as you said below then why keep it out of a draft which was designed specifically to reduce L3 losses and delays due to the MIP handover ? If I'm implementing this function in a product, don't I have to do the smoothing anyway ? Therefore, I think for prctical reasons we should actually have them in the same draft. Otherwise the only difference would be more drafts, more paper work and unncessary cycles consumed. Hesham From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 25 06:42:45 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA08637 for ; Wed, 25 Jul 2001 06:42:44 -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 DAA01762; Wed, 25 Jul 2001 03:42:56 -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 DAA23919; Wed, 25 Jul 2001 03:42:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PAf3I06367 for mobile-ip-dist; Wed, 25 Jul 2001 03:41:03 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PAeqY06290 for ; Wed, 25 Jul 2001 03:40:52 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA02865 for ; Wed, 25 Jul 2001 03:40:52 -0700 (PDT) Received: from explore.kwangwoon.ac.kr ([128.134.70.30]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA23091 for ; Wed, 25 Jul 2001 03:40:50 -0700 (PDT) Received: from ics-svr3 (ics-svr3.kwangwoon.ac.kr [128.134.70.20]) by explore.kwangwoon.ac.kr (8.9.3/8.9.3) with SMTP id TAA09954; Wed, 25 Jul 2001 19:35:23 +0900 (KST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA05117; Wed, 25 Jul 2001 04:40: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 DAA23047; Wed, 25 Jul 2001 03:39:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PAcLp05521 for mobile-ip-dist; Wed, 25 Jul 2001 03:38:21 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PAcEY05506 for ; Wed, 25 Jul 2001 03:38: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 DAA02322 for ; Wed, 25 Jul 2001 03:38:26 -0700 (PDT) Received: from explore.kwangwoon.ac.kr ([128.134.70.30]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA03930 for ; Wed, 25 Jul 2001 04:38:23 -0600 (MDT) Received: from ics-svr3 (ics-svr3.kwangwoon.ac.kr [128.134.70.20]) by explore.kwangwoon.ac.kr (8.9.3/8.9.3) with SMTP id TAA09778; Wed, 25 Jul 2001 19:32:57 +0900 (KST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA03566; Wed, 25 Jul 2001 04:37:44 -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 DAA22782; Wed, 25 Jul 2001 03:36:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PAZjS05315 for mobile-ip-dist; Wed, 25 Jul 2001 03:35:45 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PAZeY05308 for ; Wed, 25 Jul 2001 03:35:40 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA02631 for ; Wed, 25 Jul 2001 03:35:52 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA21093 for ; Wed, 25 Jul 2001 03:35:51 -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 GAA07722; Wed, 25 Jul 2001 06:34:51 -0400 (EDT) Message-Id: <200107251034.GAA07722@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-montenegro-sucv-01.txt Date: Wed, 25 Jul 2001 06:34:51 -0400 List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: 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 : SUCV Identifiers and Addresses Author(s) : G. Montenegro, C. Castelluccia Filename : draft-montenegro-sucv-01.txt Pages : 23 Date : 24-Jul-01 This document addresses the identifier ownership problem. It does so by using characteristics of Statistic Uniqueness and Cryptographic Verifiability (SUCV) of certain entities which this document calls SUCV Identifiers (SUCV ID's). This note also proposes using these SUCV characteristics in related entities called SUCV Addresses in order to severely limit certain classes of denial of service attacks and hijacking attacks. SUCV addresses are particularly applicable to solve the 'address ownership' problem that severely undermines confidence in mechanisms like Binding Updates in Mobile IP for IPv6. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-montenegro-sucv-01.txt 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-montenegro-sucv-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-montenegro-sucv-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: <20010724132501.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-montenegro-sucv-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-montenegro-sucv-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010724132501.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 25 06:43:30 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA08671 for ; Wed, 25 Jul 2001 06:43:30 -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 EAA07778; Wed, 25 Jul 2001 04:44: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 DAA24569; Wed, 25 Jul 2001 03:43:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PAfsx06735 for mobile-ip-dist; Wed, 25 Jul 2001 03:41:54 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PAfdY06624 for ; Wed, 25 Jul 2001 03:41:39 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA23614 for ; Wed, 25 Jul 2001 03:41:41 -0700 (PDT) Received: from explore.kwangwoon.ac.kr ([128.134.70.30]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA23341 for ; Wed, 25 Jul 2001 03:41:28 -0700 (PDT) Received: from ics-svr3 (ics-svr3.kwangwoon.ac.kr [128.134.70.20]) by explore.kwangwoon.ac.kr (8.9.3/8.9.3) with SMTP id TAA10009; Wed, 25 Jul 2001 19:36:01 +0900 (KST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA01164; Wed, 25 Jul 2001 03:40:51 -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 DAA23143; Wed, 25 Jul 2001 03:40:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PAcZk05547 for mobile-ip-dist; Wed, 25 Jul 2001 03:38:35 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PAcNY05525 for ; Wed, 25 Jul 2001 03:38:24 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA09373 for ; Wed, 25 Jul 2001 03:38:35 -0700 (PDT) Received: from explore.kwangwoon.ac.kr ([128.134.70.30]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA19440 for ; Wed, 25 Jul 2001 03:38:30 -0700 (PDT) Received: from ics-svr3 (ics-svr3.kwangwoon.ac.kr [128.134.70.20]) by explore.kwangwoon.ac.kr (8.9.3/8.9.3) with SMTP id TAA09809; Wed, 25 Jul 2001 19:33:03 +0900 (KST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA29987; Wed, 25 Jul 2001 03:37:12 -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 DAA22797; Wed, 25 Jul 2001 03:36:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PAZjS05315 for mobile-ip-dist; Wed, 25 Jul 2001 03:35:45 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PAZeY05308 for ; Wed, 25 Jul 2001 03:35:40 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA02631 for ; Wed, 25 Jul 2001 03:35:52 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA21093 for ; Wed, 25 Jul 2001 03:35:51 -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 GAA07722; Wed, 25 Jul 2001 06:34:51 -0400 (EDT) Message-Id: <200107251034.GAA07722@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-montenegro-sucv-01.txt Date: Wed, 25 Jul 2001 06:34:51 -0400 List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: 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 : SUCV Identifiers and Addresses Author(s) : G. Montenegro, C. Castelluccia Filename : draft-montenegro-sucv-01.txt Pages : 23 Date : 24-Jul-01 This document addresses the identifier ownership problem. It does so by using characteristics of Statistic Uniqueness and Cryptographic Verifiability (SUCV) of certain entities which this document calls SUCV Identifiers (SUCV ID's). This note also proposes using these SUCV characteristics in related entities called SUCV Addresses in order to severely limit certain classes of denial of service attacks and hijacking attacks. SUCV addresses are particularly applicable to solve the 'address ownership' problem that severely undermines confidence in mechanisms like Binding Updates in Mobile IP for IPv6. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-montenegro-sucv-01.txt 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-montenegro-sucv-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-montenegro-sucv-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: <20010724132501.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-montenegro-sucv-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-montenegro-sucv-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010724132501.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 25 06:43:46 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA08706 for ; Wed, 25 Jul 2001 06:43:45 -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 DAA02297; Wed, 25 Jul 2001 03:44:29 -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 DAA24745; Wed, 25 Jul 2001 03:44:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PAgTa06987 for mobile-ip-dist; Wed, 25 Jul 2001 03:42:29 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PAgFY06894 for ; Wed, 25 Jul 2001 03:42:16 -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 DAA03122 for ; Wed, 25 Jul 2001 03:42:18 -0700 (PDT) Received: from explore.kwangwoon.ac.kr ([128.134.70.30]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA28424 for ; Wed, 25 Jul 2001 04:43:42 -0600 (MDT) Received: from ics-svr3 (ics-svr3.kwangwoon.ac.kr [128.134.70.20]) by explore.kwangwoon.ac.kr (8.9.3/8.9.3) with SMTP id TAA10049; Wed, 25 Jul 2001 19:36:39 +0900 (KST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA01339; Wed, 25 Jul 2001 03:41: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 DAA23012; Wed, 25 Jul 2001 03:39:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PAcZk05547 for mobile-ip-dist; Wed, 25 Jul 2001 03:38:35 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PAcNY05525 for ; Wed, 25 Jul 2001 03:38:24 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA09373 for ; Wed, 25 Jul 2001 03:38:35 -0700 (PDT) Received: from explore.kwangwoon.ac.kr ([128.134.70.30]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA19440 for ; Wed, 25 Jul 2001 03:38:30 -0700 (PDT) Received: from ics-svr3 (ics-svr3.kwangwoon.ac.kr [128.134.70.20]) by explore.kwangwoon.ac.kr (8.9.3/8.9.3) with SMTP id TAA09809; Wed, 25 Jul 2001 19:33:03 +0900 (KST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA29987; Wed, 25 Jul 2001 03:37:12 -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 DAA22797; Wed, 25 Jul 2001 03:36:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PAZjS05315 for mobile-ip-dist; Wed, 25 Jul 2001 03:35:45 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PAZeY05308 for ; Wed, 25 Jul 2001 03:35:40 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA02631 for ; Wed, 25 Jul 2001 03:35:52 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA21093 for ; Wed, 25 Jul 2001 03:35:51 -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 GAA07722; Wed, 25 Jul 2001 06:34:51 -0400 (EDT) Message-Id: <200107251034.GAA07722@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-montenegro-sucv-01.txt Date: Wed, 25 Jul 2001 06:34:51 -0400 List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: 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 : SUCV Identifiers and Addresses Author(s) : G. Montenegro, C. Castelluccia Filename : draft-montenegro-sucv-01.txt Pages : 23 Date : 24-Jul-01 This document addresses the identifier ownership problem. It does so by using characteristics of Statistic Uniqueness and Cryptographic Verifiability (SUCV) of certain entities which this document calls SUCV Identifiers (SUCV ID's). This note also proposes using these SUCV characteristics in related entities called SUCV Addresses in order to severely limit certain classes of denial of service attacks and hijacking attacks. SUCV addresses are particularly applicable to solve the 'address ownership' problem that severely undermines confidence in mechanisms like Binding Updates in Mobile IP for IPv6. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-montenegro-sucv-01.txt 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-montenegro-sucv-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-montenegro-sucv-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: <20010724132501.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-montenegro-sucv-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-montenegro-sucv-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010724132501.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 25 06:49:57 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA08919 for ; Wed, 25 Jul 2001 06:49:56 -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 EAA11510; Wed, 25 Jul 2001 04:50:26 -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 DAA28328; Wed, 25 Jul 2001 03:50:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PAnIQ10005 for mobile-ip-dist; Wed, 25 Jul 2001 03:49:18 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PAn9Y09942 for ; Wed, 25 Jul 2001 03:49:09 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA26611 for ; Wed, 25 Jul 2001 03:46:32 -0700 (PDT) Received: from explore.kwangwoon.ac.kr ([128.134.70.30]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA22663 for ; Wed, 25 Jul 2001 03:46:31 -0700 (PDT) Received: from ics-svr3 (ics-svr3.kwangwoon.ac.kr [128.134.70.20]) by explore.kwangwoon.ac.kr (8.9.3/8.9.3) with SMTP id TAA10395; Wed, 25 Jul 2001 19:41:05 +0900 (KST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA05499; Wed, 25 Jul 2001 04:40:34 -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 DAA22986; Wed, 25 Jul 2001 03:39:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PAcLp05521 for mobile-ip-dist; Wed, 25 Jul 2001 03:38:21 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PAcEY05506 for ; Wed, 25 Jul 2001 03:38: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 DAA02322 for ; Wed, 25 Jul 2001 03:38:26 -0700 (PDT) Received: from explore.kwangwoon.ac.kr ([128.134.70.30]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA03930 for ; Wed, 25 Jul 2001 04:38:23 -0600 (MDT) Received: from ics-svr3 (ics-svr3.kwangwoon.ac.kr [128.134.70.20]) by explore.kwangwoon.ac.kr (8.9.3/8.9.3) with SMTP id TAA09778; Wed, 25 Jul 2001 19:32:57 +0900 (KST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA03566; Wed, 25 Jul 2001 04:37:44 -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 DAA22782; Wed, 25 Jul 2001 03:36:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PAZjS05315 for mobile-ip-dist; Wed, 25 Jul 2001 03:35:45 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PAZeY05308 for ; Wed, 25 Jul 2001 03:35:40 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA02631 for ; Wed, 25 Jul 2001 03:35:52 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA21093 for ; Wed, 25 Jul 2001 03:35:51 -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 GAA07722; Wed, 25 Jul 2001 06:34:51 -0400 (EDT) Message-Id: <200107251034.GAA07722@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-montenegro-sucv-01.txt Date: Wed, 25 Jul 2001 06:34:51 -0400 List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: 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 : SUCV Identifiers and Addresses Author(s) : G. Montenegro, C. Castelluccia Filename : draft-montenegro-sucv-01.txt Pages : 23 Date : 24-Jul-01 This document addresses the identifier ownership problem. It does so by using characteristics of Statistic Uniqueness and Cryptographic Verifiability (SUCV) of certain entities which this document calls SUCV Identifiers (SUCV ID's). This note also proposes using these SUCV characteristics in related entities called SUCV Addresses in order to severely limit certain classes of denial of service attacks and hijacking attacks. SUCV addresses are particularly applicable to solve the 'address ownership' problem that severely undermines confidence in mechanisms like Binding Updates in Mobile IP for IPv6. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-montenegro-sucv-01.txt 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-montenegro-sucv-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-montenegro-sucv-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: <20010724132501.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-montenegro-sucv-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-montenegro-sucv-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010724132501.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 25 07:24:58 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA10800 for ; Wed, 25 Jul 2001 07:24:57 -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 FAA26478; Wed, 25 Jul 2001 05:25:24 -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 EAA14003; Wed, 25 Jul 2001 04:25:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PBO1S12162 for mobile-ip-dist; Wed, 25 Jul 2001 04:24:01 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PBNwY12155 for ; Wed, 25 Jul 2001 04:23:58 -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 EAA03344 for ; Wed, 25 Jul 2001 04:24:10 -0700 (PDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA18351 for ; Wed, 25 Jul 2001 05:25:33 -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.11.0/8.11.0/WIREfire-1.3) with SMTP id f6PBO7N25584 for ; Wed, 25 Jul 2001 13:24:07 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed Jul 25 13:24:03 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Jul 2001 13:24:03 +0200 Message-ID: <795A014AF92DD21182AF0008C7A404320C52048F@esealnt117> From: "Karim El-Malki (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Handover Smoothing - What to Do? Date: Wed, 25 Jul 2001 13:24:00 +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: Regarding the CDMA thread, I think we're going away from the problem. Synchronisation of basestations is important for soft handoff but I cannot see the relation with the smoothing function we are talking about. We just want to minimise the period the MN is disconnected at L3 following a handoff (FMIP), but we do not aim to address recombination or anything like that. Synchronising the basestations for soft handoff does not mean that you won't get duplicate/delayed packets at L3. Of course, as pointed out by Arthur, its important to consider different L2 characteristics but in this case I think that getting into base station synch issues is not relevant. Rgds /Karim > -----Original Message----- > From: Arthur Ross [mailto:a.ross@ieee.org] > Sent: den 24 juli 2001 23:48 > To: mobile-ip@sunroof.eng.sun.com > Subject: RE: [mobile-ip] Handover Smoothing - What to Do? > > > At 13:39 -0700 07/24/2001, James Kempf wrote: > > > >In general, I don't know any way to synchronize packet delivery > >between oFA and nFA. I believe CDMA does this by having a > >very short window (something like 20 ms) during which soft handover > >occurs, and using GPS (in cdma2000) to synchronize soft handover > >between BTSs. This is not possible in IP, if for no other reason than > >the packet sizes can vary, and not all radio protocols have access > >to GPS synchronization. There are a variety of heurstics that > >could be used, however, and I think it makes sense to write > >them down. > > > James et al: > > The issue here is the nature of the diversity that is available in > any given RAN technology. The simplest is unsynchronized multicasting > - packets are sent from more than one source, without any attempt at > synchronization other than that imposed by sequence numbering. > > The various flavors of CDMA technology, on the other hand, employ a > very sophisticated symbol-by-symbol optimal ratio (in the downlink) > combining. This substantially improves error performance under > adverse propagation conditions. That combining is, in essence, a > vector sum of received symbol amplitude estimates from whatever > sources are available. The signal components add amplitude-wise, > while the noise components add power-wise (i.e. rss), hence the > improvement in overall SNR of the resultant. This technique relies on > the same sequence of symbols be radiated the various BTSs > participating in this "soft" handoff. > > The CDMA return link diversity combining is done in a different way, > but also makes use of multiple symbol streams from the various BTS > receivers involved in the handoff. > > As you say, this is done with the aid of GPS-derived precise timing. > Synchronization is not fundamentally necessary, but it is extremely > convenient in implementing the combining, and helps keep the latency > low. Other less precisely timed forms are possible in principle, but > have not, as far as I know, ever been proposed or implemented. To do > so would require substantially buffering and de-skewing of the symbol > streams. That buffering and deskewing would contribute objectionable > latency and variance of latency, both very objectionable in a speech > service. > > The 20 ms of which you speak is the CDMA frame size. That size has > its origins in the size of the vocoder frames. The FEC is blocked in > those 20 ms frames - each frame can be decoded and CRC checked > independently. Again, not fundamental, but because of the dominance > of the speech service, it is probably here to stay, or at least will > be around for a long time. > > Re "handoff smoothing" - It is, I think, desirable to recognize the > variety of diversity techniques that may be used in the radio link, > depending on the particular technology, and to provide the > tools/mechanisms the can accommodate that variety somehow. This is, > obviously, intimately intertwined with the QoS issues. What is ok for > a dumb datagram service may be manifestly awful for a speech service. > > Just my 2 cents worth ... > > -- Regards, AHMR > From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 25 08:13:29 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA13984 for ; Wed, 25 Jul 2001 08:13:29 -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 FAA23995; Wed, 25 Jul 2001 05:14:10 -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 FAA11136; Wed, 25 Jul 2001 05:13:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PCCF112291 for mobile-ip-dist; Wed, 25 Jul 2001 05:12:15 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PCCBY12284 for ; Wed, 25 Jul 2001 05:12: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 FAA17634 for ; Wed, 25 Jul 2001 05:12:24 -0700 (PDT) Received: from p-mail2.cnet.fr (p-mail2.rd.francetelecom.fr [193.49.124.32]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id GAA16689 for ; Wed, 25 Jul 2001 06:12:21 -0600 (MDT) Received: by p-voyageur.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Jul 2001 14:11:53 +0200 Received: from francetelecom.com (p-dico.rd.francetelecom.fr [139.100.18.135]) by p-grive.rd.francetelecom.fr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3ZBB7WHC; Wed, 25 Jul 2001 14:11:49 +0200 Message-ID: <3B5EB756.2DA0B166@francetelecom.com> Date: Wed, 25 Jul 2001 14:11:02 +0200 From: Jean-Michel COMBES Organization: France =?iso-8859-1?Q?T=E9l=E9com?= R&D X-Mailer: Mozilla 4.75 [fr] (Windows NT 5.0; U) X-Accept-Language: fr MIME-Version: 1.0 To: Claude Castelluccia CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Question on draft-team-mobileip-mipv6-sec-reqts-00.txt References: <697DAA22C5004B4596E033803A7CEF440860AD@daebe007.NOE.Nokia.com> <3B5DA26F.1D35859C@francetelecom.com> <3B5E7900.1CB3B95F@inrialpes.fr> 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: X-MIME-Autoconverted: from 8bit to quoted-printable by mercury.Sun.COM id FAA23995 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA13984 Hi Claude, Claude Castelluccia a écrit : > Jean-Michel COMBES wrote: > >> Hi, >> >> JMC : In my point of view, the result is like a static host using >> spoofing >> ... the only threat that is specific to MIPv6 is on MN using an >> unauthorized H@ when it sends BU. > > Jean-Michel... > > sure....but in the static host case one might think that "ingress > filtering" might help > solving this specific problem sometimes... > With the HomeAddress option, ingress filtering can't do anything for > you (because > the source address is topologically correct)... JMC : You are right. > this makes the problem more difficult to > solve JMC : You are right again. :-) > and definetly different that the static host case.... JMC : I don't think so. What is ingress filtering ? A mecanism that filters packets, checks Source Address validity and authorizes (or not) them to go to their destination. Wrong ? (BTW, is there any draft about IPv6 Ingress Filtering ?). That's look like AAAv6 with intendant filtering fonction based on H@. > > I don't think you can argue that "this threat is not specific to > MIPv6"....it is! JMC : I'm not totally convinced. JMC. > > > Claude. > > > -- > > ---------------------------------------- > Claude CASTELLUCCIA, INRIA Rhone-Alpes > ph: +33 4.76.61.52.15 (fax: 52.52) > http://www.inrialpes.fr/planete/ > > -- 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 From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 25 08:16:14 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA14189 for ; Wed, 25 Jul 2001 08:16:13 -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 GAA18882; Wed, 25 Jul 2001 06:16: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 FAA11450; Wed, 25 Jul 2001 05:16:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PCFPD12347 for mobile-ip-dist; Wed, 25 Jul 2001 05:15:25 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PCFLY12340 for ; Wed, 25 Jul 2001 05:15:21 -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 FAA07012 for ; Wed, 25 Jul 2001 05:15:34 -0700 (PDT) Received: from explore.kwangwoon.ac.kr ([128.134.70.30]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA18324 for ; Wed, 25 Jul 2001 06:15:30 -0600 (MDT) Received: from ics-svr3 (ics-svr3.kwangwoon.ac.kr [128.134.70.20]) by explore.kwangwoon.ac.kr (8.9.3/8.9.3) with SMTP id VAA22294; Wed, 25 Jul 2001 21:10:04 +0900 (KST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA17819; Wed, 25 Jul 2001 06:14:42 -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 FAA11112; Wed, 25 Jul 2001 05:13:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PCCF112291 for mobile-ip-dist; Wed, 25 Jul 2001 05:12:15 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PCCBY12284 for ; Wed, 25 Jul 2001 05:12: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 FAA17634 for ; Wed, 25 Jul 2001 05:12:24 -0700 (PDT) Received: from p-mail2.cnet.fr (p-mail2.rd.francetelecom.fr [193.49.124.32]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id GAA16689 for ; Wed, 25 Jul 2001 06:12:21 -0600 (MDT) Received: by p-voyageur.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Jul 2001 14:11:53 +0200 Received: from francetelecom.com (p-dico.rd.francetelecom.fr [139.100.18.135]) by p-grive.rd.francetelecom.fr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3ZBB7WHC; Wed, 25 Jul 2001 14:11:49 +0200 Message-ID: <3B5EB756.2DA0B166@francetelecom.com> Date: Wed, 25 Jul 2001 14:11:02 +0200 From: Jean-Michel COMBES Organization: France =?iso-8859-1?Q?T=E9l=E9com?= R&D X-Mailer: Mozilla 4.75 [fr] (Windows NT 5.0; U) X-Accept-Language: fr MIME-Version: 1.0 To: Claude Castelluccia CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Question on draft-team-mobileip-mipv6-sec-reqts-00.txt References: <697DAA22C5004B4596E033803A7CEF440860AD@daebe007.NOE.Nokia.com> <3B5DA26F.1D35859C@francetelecom.com> <3B5E7900.1CB3B95F@inrialpes.fr> Content-Type: text/plain; charset=iso-8859-1 List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by patan.sun.com id GAA17819 X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f6PCFLY12341 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: X-MIME-Autoconverted: from 8bit to quoted-printable by patan.sun.com id GAA18882 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA14189 Hi Claude, Claude Castelluccia a écrit : > Jean-Michel COMBES wrote: > >> Hi, >> >> JMC : In my point of view, the result is like a static host using >> spoofing >> ... the only threat that is specific to MIPv6 is on MN using an >> unauthorized H@ when it sends BU. > > Jean-Michel... > > sure....but in the static host case one might think that "ingress > filtering" might help > solving this specific problem sometimes... > With the HomeAddress option, ingress filtering can't do anything for > you (because > the source address is topologically correct)... JMC : You are right. > this makes the problem more difficult to > solve JMC : You are right again. :-) > and definetly different that the static host case.... JMC : I don't think so. What is ingress filtering ? A mecanism that filters packets, checks Source Address validity and authorizes (or not) them to go to their destination. Wrong ? (BTW, is there any draft about IPv6 Ingress Filtering ?). That's look like AAAv6 with intendant filtering fonction based on H@. > > I don't think you can argue that "this threat is not specific to > MIPv6"....it is! JMC : I'm not totally convinced. JMC. > > > Claude. > > > -- > > ---------------------------------------- > Claude CASTELLUCCIA, INRIA Rhone-Alpes > ph: +33 4.76.61.52.15 (fax: 52.52) > http://www.inrialpes.fr/planete/ > > -- 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 From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 25 08:18:45 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA14363 for ; Wed, 25 Jul 2001 08:18:44 -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 GAA20379; Wed, 25 Jul 2001 06:19:21 -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 FAA11967; Wed, 25 Jul 2001 05:19:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PCHPm12479 for mobile-ip-dist; Wed, 25 Jul 2001 05:17:25 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PCHIY12437 for ; Wed, 25 Jul 2001 05:17:18 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA07175 for ; Wed, 25 Jul 2001 05:17:31 -0700 (PDT) Received: from explore.kwangwoon.ac.kr ([128.134.70.30]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA20602 for ; Wed, 25 Jul 2001 05:17:30 -0700 (PDT) Received: from ics-svr3 (ics-svr3.kwangwoon.ac.kr [128.134.70.20]) by explore.kwangwoon.ac.kr (8.9.3/8.9.3) with SMTP id VAA22566; Wed, 25 Jul 2001 21:12:02 +0900 (KST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA18908; Wed, 25 Jul 2001 06:16: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 FAA11450; Wed, 25 Jul 2001 05:16:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PCFPD12347 for mobile-ip-dist; Wed, 25 Jul 2001 05:15:25 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PCFLY12340 for ; Wed, 25 Jul 2001 05:15:21 -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 FAA07012 for ; Wed, 25 Jul 2001 05:15:34 -0700 (PDT) Received: from explore.kwangwoon.ac.kr ([128.134.70.30]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA18324 for ; Wed, 25 Jul 2001 06:15:30 -0600 (MDT) Received: from ics-svr3 (ics-svr3.kwangwoon.ac.kr [128.134.70.20]) by explore.kwangwoon.ac.kr (8.9.3/8.9.3) with SMTP id VAA22294; Wed, 25 Jul 2001 21:10:04 +0900 (KST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA17819; Wed, 25 Jul 2001 06:14:42 -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 FAA11112; Wed, 25 Jul 2001 05:13:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PCCF112291 for mobile-ip-dist; Wed, 25 Jul 2001 05:12:15 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PCCBY12284 for ; Wed, 25 Jul 2001 05:12: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 FAA17634 for ; Wed, 25 Jul 2001 05:12:24 -0700 (PDT) Received: from p-mail2.cnet.fr (p-mail2.rd.francetelecom.fr [193.49.124.32]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id GAA16689 for ; Wed, 25 Jul 2001 06:12:21 -0600 (MDT) Received: by p-voyageur.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Jul 2001 14:11:53 +0200 Received: from francetelecom.com (p-dico.rd.francetelecom.fr [139.100.18.135]) by p-grive.rd.francetelecom.fr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3ZBB7WHC; Wed, 25 Jul 2001 14:11:49 +0200 Message-ID: <3B5EB756.2DA0B166@francetelecom.com> Date: Wed, 25 Jul 2001 14:11:02 +0200 From: Jean-Michel COMBES Organization: France =?iso-8859-1?Q?T=E9l=E9com?= R&D X-Mailer: Mozilla 4.75 [fr] (Windows NT 5.0; U) X-Accept-Language: fr MIME-Version: 1.0 To: Claude Castelluccia CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Question on draft-team-mobileip-mipv6-sec-reqts-00.txt References: <697DAA22C5004B4596E033803A7CEF440860AD@daebe007.NOE.Nokia.com> <3B5DA26F.1D35859C@francetelecom.com> <3B5E7900.1CB3B95F@inrialpes.fr> Content-Type: text/plain; charset=iso-8859-1 List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by patan.sun.com id GAA17819 X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f6PCFLY12341 List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by patan.sun.com id GAA18908 X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f6PCHJY12441 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: X-MIME-Autoconverted: from 8bit to quoted-printable by patan.sun.com id GAA20379 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA14363 Hi Claude, Claude Castelluccia a écrit : > Jean-Michel COMBES wrote: > >> Hi, >> >> JMC : In my point of view, the result is like a static host using >> spoofing >> ... the only threat that is specific to MIPv6 is on MN using an >> unauthorized H@ when it sends BU. > > Jean-Michel... > > sure....but in the static host case one might think that "ingress > filtering" might help > solving this specific problem sometimes... > With the HomeAddress option, ingress filtering can't do anything for > you (because > the source address is topologically correct)... JMC : You are right. > this makes the problem more difficult to > solve JMC : You are right again. :-) > and definetly different that the static host case.... JMC : I don't think so. What is ingress filtering ? A mecanism that filters packets, checks Source Address validity and authorizes (or not) them to go to their destination. Wrong ? (BTW, is there any draft about IPv6 Ingress Filtering ?). That's look like AAAv6 with intendant filtering fonction based on H@. > > I don't think you can argue that "this threat is not specific to > MIPv6"....it is! JMC : I'm not totally convinced. JMC. > > > Claude. > > > -- > > ---------------------------------------- > Claude CASTELLUCCIA, INRIA Rhone-Alpes > ph: +33 4.76.61.52.15 (fax: 52.52) > http://www.inrialpes.fr/planete/ > > -- 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 From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 25 08:18:46 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA14364 for ; Wed, 25 Jul 2001 08:18: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 GAA20390; Wed, 25 Jul 2001 06:19:22 -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 FAA11968; Wed, 25 Jul 2001 05:19:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PCHXt12502 for mobile-ip-dist; Wed, 25 Jul 2001 05:17:33 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PCHSY12491 for ; Wed, 25 Jul 2001 05:17:28 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA11655 for ; Wed, 25 Jul 2001 05:17:41 -0700 (PDT) Received: from explore.kwangwoon.ac.kr ([128.134.70.30]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA00042 for ; Wed, 25 Jul 2001 05:17:39 -0700 (PDT) Received: from ics-svr3 (ics-svr3.kwangwoon.ac.kr [128.134.70.20]) by explore.kwangwoon.ac.kr (8.9.3/8.9.3) with SMTP id VAA22616; Wed, 25 Jul 2001 21:12:08 +0900 (KST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA24052; Wed, 25 Jul 2001 05:14: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 FAA11136; Wed, 25 Jul 2001 05:13:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PCCF112291 for mobile-ip-dist; Wed, 25 Jul 2001 05:12:15 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PCCBY12284 for ; Wed, 25 Jul 2001 05:12: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 FAA17634 for ; Wed, 25 Jul 2001 05:12:24 -0700 (PDT) Received: from p-mail2.cnet.fr (p-mail2.rd.francetelecom.fr [193.49.124.32]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id GAA16689 for ; Wed, 25 Jul 2001 06:12:21 -0600 (MDT) Received: by p-voyageur.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Jul 2001 14:11:53 +0200 Received: from francetelecom.com (p-dico.rd.francetelecom.fr [139.100.18.135]) by p-grive.rd.francetelecom.fr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3ZBB7WHC; Wed, 25 Jul 2001 14:11:49 +0200 Message-ID: <3B5EB756.2DA0B166@francetelecom.com> Date: Wed, 25 Jul 2001 14:11:02 +0200 From: Jean-Michel COMBES Organization: France =?iso-8859-1?Q?T=E9l=E9com?= R&D X-Mailer: Mozilla 4.75 [fr] (Windows NT 5.0; U) X-Accept-Language: fr MIME-Version: 1.0 To: Claude Castelluccia CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Question on draft-team-mobileip-mipv6-sec-reqts-00.txt References: <697DAA22C5004B4596E033803A7CEF440860AD@daebe007.NOE.Nokia.com> <3B5DA26F.1D35859C@francetelecom.com> <3B5E7900.1CB3B95F@inrialpes.fr> Content-Type: text/plain; charset=iso-8859-1 List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by mercury.Sun.COM id FAA24052 X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f6PCHSY12492 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: X-MIME-Autoconverted: from 8bit to quoted-printable by patan.sun.com id GAA20390 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA14364 Hi Claude, Claude Castelluccia a écrit : > Jean-Michel COMBES wrote: > >> Hi, >> >> JMC : In my point of view, the result is like a static host using >> spoofing >> ... the only threat that is specific to MIPv6 is on MN using an >> unauthorized H@ when it sends BU. > > Jean-Michel... > > sure....but in the static host case one might think that "ingress > filtering" might help > solving this specific problem sometimes... > With the HomeAddress option, ingress filtering can't do anything for > you (because > the source address is topologically correct)... JMC : You are right. > this makes the problem more difficult to > solve JMC : You are right again. :-) > and definetly different that the static host case.... JMC : I don't think so. What is ingress filtering ? A mecanism that filters packets, checks Source Address validity and authorizes (or not) them to go to their destination. Wrong ? (BTW, is there any draft about IPv6 Ingress Filtering ?). That's look like AAAv6 with intendant filtering fonction based on H@. > > I don't think you can argue that "this threat is not specific to > MIPv6"....it is! JMC : I'm not totally convinced. JMC. > > > Claude. > > > -- > > ---------------------------------------- > Claude CASTELLUCCIA, INRIA Rhone-Alpes > ph: +33 4.76.61.52.15 (fax: 52.52) > http://www.inrialpes.fr/planete/ > > -- 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 From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 25 08:20:34 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA14547 for ; Wed, 25 Jul 2001 08:20:33 -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 FAA26424; Wed, 25 Jul 2001 05:20:59 -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 FAA12456; Wed, 25 Jul 2001 05:19:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PCIRT12612 for mobile-ip-dist; Wed, 25 Jul 2001 05:18:27 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PCIMY12590 for ; Wed, 25 Jul 2001 05:18:22 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA07216 for ; Wed, 25 Jul 2001 05:18:35 -0700 (PDT) Received: from explore.kwangwoon.ac.kr ([128.134.70.30]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA20944 for ; Wed, 25 Jul 2001 05:18:34 -0700 (PDT) Received: from ics-svr3 (ics-svr3.kwangwoon.ac.kr [128.134.70.20]) by explore.kwangwoon.ac.kr (8.9.3/8.9.3) with SMTP id VAA22841; Wed, 25 Jul 2001 21:13:07 +0900 (KST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA19471; Wed, 25 Jul 2001 06:17:57 -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 FAA11425; Wed, 25 Jul 2001 05:16:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PCFPD12347 for mobile-ip-dist; Wed, 25 Jul 2001 05:15:25 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PCFLY12340 for ; Wed, 25 Jul 2001 05:15:21 -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 FAA07012 for ; Wed, 25 Jul 2001 05:15:34 -0700 (PDT) Received: from explore.kwangwoon.ac.kr ([128.134.70.30]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA18324 for ; Wed, 25 Jul 2001 06:15:30 -0600 (MDT) Received: from ics-svr3 (ics-svr3.kwangwoon.ac.kr [128.134.70.20]) by explore.kwangwoon.ac.kr (8.9.3/8.9.3) with SMTP id VAA22294; Wed, 25 Jul 2001 21:10:04 +0900 (KST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA17819; Wed, 25 Jul 2001 06:14:42 -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 FAA11112; Wed, 25 Jul 2001 05:13:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PCCF112291 for mobile-ip-dist; Wed, 25 Jul 2001 05:12:15 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PCCBY12284 for ; Wed, 25 Jul 2001 05:12: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 FAA17634 for ; Wed, 25 Jul 2001 05:12:24 -0700 (PDT) Received: from p-mail2.cnet.fr (p-mail2.rd.francetelecom.fr [193.49.124.32]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id GAA16689 for ; Wed, 25 Jul 2001 06:12:21 -0600 (MDT) Received: by p-voyageur.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Jul 2001 14:11:53 +0200 Received: from francetelecom.com (p-dico.rd.francetelecom.fr [139.100.18.135]) by p-grive.rd.francetelecom.fr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3ZBB7WHC; Wed, 25 Jul 2001 14:11:49 +0200 Message-ID: <3B5EB756.2DA0B166@francetelecom.com> Date: Wed, 25 Jul 2001 14:11:02 +0200 From: Jean-Michel COMBES Organization: France =?iso-8859-1?Q?T=E9l=E9com?= R&D X-Mailer: Mozilla 4.75 [fr] (Windows NT 5.0; U) X-Accept-Language: fr MIME-Version: 1.0 To: Claude Castelluccia CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Question on draft-team-mobileip-mipv6-sec-reqts-00.txt References: <697DAA22C5004B4596E033803A7CEF440860AD@daebe007.NOE.Nokia.com> <3B5DA26F.1D35859C@francetelecom.com> <3B5E7900.1CB3B95F@inrialpes.fr> Content-Type: text/plain; charset=iso-8859-1 List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by patan.sun.com id GAA17819 X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f6PCFLY12341 List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by patan.sun.com id GAA19471 X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f6PCINY12593 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: X-MIME-Autoconverted: from 8bit to quoted-printable by mercury.Sun.COM id FAA26424 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA14547 Hi Claude, Claude Castelluccia a écrit : > Jean-Michel COMBES wrote: > >> Hi, >> >> JMC : In my point of view, the result is like a static host using >> spoofing >> ... the only threat that is specific to MIPv6 is on MN using an >> unauthorized H@ when it sends BU. > > Jean-Michel... > > sure....but in the static host case one might think that "ingress > filtering" might help > solving this specific problem sometimes... > With the HomeAddress option, ingress filtering can't do anything for > you (because > the source address is topologically correct)... JMC : You are right. > this makes the problem more difficult to > solve JMC : You are right again. :-) > and definetly different that the static host case.... JMC : I don't think so. What is ingress filtering ? A mecanism that filters packets, checks Source Address validity and authorizes (or not) them to go to their destination. Wrong ? (BTW, is there any draft about IPv6 Ingress Filtering ?). That's look like AAAv6 with intendant filtering fonction based on H@. > > I don't think you can argue that "this threat is not specific to > MIPv6"....it is! JMC : I'm not totally convinced. JMC. > > > Claude. > > > -- > > ---------------------------------------- > Claude CASTELLUCCIA, INRIA Rhone-Alpes > ph: +33 4.76.61.52.15 (fax: 52.52) > http://www.inrialpes.fr/planete/ > > -- 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 From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 25 08:22:24 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA14707 for ; Wed, 25 Jul 2001 08:22:23 -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 FAA27109; Wed, 25 Jul 2001 05:23:03 -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 FAA14519; Wed, 25 Jul 2001 05:22:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PCKD713188 for mobile-ip-dist; Wed, 25 Jul 2001 05:20:13 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PCK5Y13135 for ; Wed, 25 Jul 2001 05:20: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 FAA07327 for ; Wed, 25 Jul 2001 05:19:44 -0700 (PDT) Received: from p-mail2.cnet.fr (p-mail2.rd.francetelecom.fr [193.49.124.32]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id GAA20708 for ; Wed, 25 Jul 2001 06:19:42 -0600 (MDT) Received: by p-voyageur.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Jul 2001 14:19:28 +0200 Received: from francetelecom.com (p-dico.rd.francetelecom.fr [139.100.18.135]) by p-grive.rd.francetelecom.fr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3ZBB7WHW; Wed, 25 Jul 2001 14:19:24 +0200 Message-ID: <3B5EB91D.AA53720D@francetelecom.com> Date: Wed, 25 Jul 2001 14:18:37 +0200 From: Jean-Michel COMBES Organization: France =?iso-8859-1?Q?T=E9l=E9com?= R&D X-Mailer: Mozilla 4.75 [fr] (Windows NT 5.0; U) X-Accept-Language: fr MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [Fwd: [mobile-ip] Mobile IPv6 clarifications] References: <200107241727.f6OHRlS08219@thunk.east.sun.com> <3B5DEF29.CE1C831D@iprg.nokia.com> 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: X-MIME-Autoconverted: from 8bit to quoted-printable by mercury.Sun.COM id FAA27109 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA14707 Hi Vijay, Vijay Devarapalli a écrit : > hello, > > i thought the real problem with the use of IPSec was with > distinguishing a destination options header containing a > BU and a destination options header containing some other > option. this is not possible with current IPsec selectors. JMC : why not attribute a different "Next Header" value (ie. not equal to 60) to BU/BAck ? With this solution and "no piggybacking", IPsec will work fine. 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 From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 25 08:22:37 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA14729 for ; Wed, 25 Jul 2001 08:22:36 -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 GAA23452; Wed, 25 Jul 2001 06:23:13 -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 FAA14732; Wed, 25 Jul 2001 05:23:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PCLDW13625 for mobile-ip-dist; Wed, 25 Jul 2001 05:21:13 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PCL0Y13528 for ; Wed, 25 Jul 2001 05:21:00 -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 FAA07621 for ; Wed, 25 Jul 2001 05:20:53 -0700 (PDT) Received: from explore.kwangwoon.ac.kr ([128.134.70.30]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA21762 for ; Wed, 25 Jul 2001 06:20:50 -0600 (MDT) Received: from ics-svr3 (ics-svr3.kwangwoon.ac.kr [128.134.70.20]) by explore.kwangwoon.ac.kr (8.9.3/8.9.3) with SMTP id VAA23189; Wed, 25 Jul 2001 21:15:20 +0900 (KST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA21142; Wed, 25 Jul 2001 06:20: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 FAA11772; Wed, 25 Jul 2001 05:18:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PCHXt12502 for mobile-ip-dist; Wed, 25 Jul 2001 05:17:33 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PCHSY12491 for ; Wed, 25 Jul 2001 05:17:28 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA11655 for ; Wed, 25 Jul 2001 05:17:41 -0700 (PDT) Received: from explore.kwangwoon.ac.kr ([128.134.70.30]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA00042 for ; Wed, 25 Jul 2001 05:17:39 -0700 (PDT) Received: from ics-svr3 (ics-svr3.kwangwoon.ac.kr [128.134.70.20]) by explore.kwangwoon.ac.kr (8.9.3/8.9.3) with SMTP id VAA22616; Wed, 25 Jul 2001 21:12:08 +0900 (KST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA24052; Wed, 25 Jul 2001 05:14: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 FAA11136; Wed, 25 Jul 2001 05:13:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PCCF112291 for mobile-ip-dist; Wed, 25 Jul 2001 05:12:15 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PCCBY12284 for ; Wed, 25 Jul 2001 05:12: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 FAA17634 for ; Wed, 25 Jul 2001 05:12:24 -0700 (PDT) Received: from p-mail2.cnet.fr (p-mail2.rd.francetelecom.fr [193.49.124.32]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id GAA16689 for ; Wed, 25 Jul 2001 06:12:21 -0600 (MDT) Received: by p-voyageur.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Jul 2001 14:11:53 +0200 Received: from francetelecom.com (p-dico.rd.francetelecom.fr [139.100.18.135]) by p-grive.rd.francetelecom.fr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3ZBB7WHC; Wed, 25 Jul 2001 14:11:49 +0200 Message-ID: <3B5EB756.2DA0B166@francetelecom.com> Date: Wed, 25 Jul 2001 14:11:02 +0200 From: Jean-Michel COMBES Organization: France =?iso-8859-1?Q?T=E9l=E9com?= R&D X-Mailer: Mozilla 4.75 [fr] (Windows NT 5.0; U) X-Accept-Language: fr MIME-Version: 1.0 To: Claude Castelluccia CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Question on draft-team-mobileip-mipv6-sec-reqts-00.txt References: <697DAA22C5004B4596E033803A7CEF440860AD@daebe007.NOE.Nokia.com> <3B5DA26F.1D35859C@francetelecom.com> <3B5E7900.1CB3B95F@inrialpes.fr> Content-Type: text/plain; charset=iso-8859-1 List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by mercury.Sun.COM id FAA24052 X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f6PCHSY12492 List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by patan.sun.com id GAA21142 X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f6PCL1Y13531 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: X-MIME-Autoconverted: from 8bit to quoted-printable by patan.sun.com id GAA23452 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA14729 Hi Claude, Claude Castelluccia a écrit : > Jean-Michel COMBES wrote: > >> Hi, >> >> JMC : In my point of view, the result is like a static host using >> spoofing >> ... the only threat that is specific to MIPv6 is on MN using an >> unauthorized H@ when it sends BU. > > Jean-Michel... > > sure....but in the static host case one might think that "ingress > filtering" might help > solving this specific problem sometimes... > With the HomeAddress option, ingress filtering can't do anything for > you (because > the source address is topologically correct)... JMC : You are right. > this makes the problem more difficult to > solve JMC : You are right again. :-) > and definetly different that the static host case.... JMC : I don't think so. What is ingress filtering ? A mecanism that filters packets, checks Source Address validity and authorizes (or not) them to go to their destination. Wrong ? (BTW, is there any draft about IPv6 Ingress Filtering ?). That's look like AAAv6 with intendant filtering fonction based on H@. > > I don't think you can argue that "this threat is not specific to > MIPv6"....it is! JMC : I'm not totally convinced. JMC. > > > Claude. > > > -- > > ---------------------------------------- > Claude CASTELLUCCIA, INRIA Rhone-Alpes > ph: +33 4.76.61.52.15 (fax: 52.52) > http://www.inrialpes.fr/planete/ > > -- 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 From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 25 08:34:56 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA15771 for ; Wed, 25 Jul 2001 08:34:55 -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 GAA00130; Wed, 25 Jul 2001 06:35:32 -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 FAA19428; Wed, 25 Jul 2001 05:35:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PCVaT16736 for mobile-ip-dist; Wed, 25 Jul 2001 05:31:36 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PCVWY16729 for ; Wed, 25 Jul 2001 05:31:32 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA18173 for ; Wed, 25 Jul 2001 05:31:34 -0700 (PDT) Received: from RRMAIL01.RADIOROUTER_NT ([63.103.94.23]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA06298 for ; Wed, 25 Jul 2001 05:31:33 -0700 (PDT) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Jul 2001 08:31:31 -0400 Message-ID: <8C92E23A3E87FB479988285F9E22BE460546B2@ftmail> From: George Tsirtsis To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Handover Smoothing - What to Do? Date: Wed, 25 Jul 2001 08:31:30 -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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: -----Original Message----- From: Hesham Soliman (ERA) [mailto:Hesham.Soliman@era.ericsson.se] Sent: Wednesday, July 25, 2001 11:32 AM To: 'mobile-ip@sunroof.eng.sun.com' Subject: RE: [mobile-ip] Handover Smoothing - What to Do? > > The issue is whether the FMIP work is completely useless without > > smoothing, or whether smoothing is so intertwined with the FMIP > > work that it is impossible to put it into a separate spec. I think > > the fact that the FMIPv6 draft managed to successfully disentangle > > them argues that the smoothing work can be separated out from > > a design perspective. Whether or not FMIP is useless without > > smoothing from an operational or implementation perspective > > is something that can only be determined by experiment. > > I'd say that it's not useless: if you have two interfaces, > FMIP alone is probably sufficient since you can do a make > before break while listening on both for some period of > time. It might be pointed out that you could do that without > the FMIP AR, but latencies back to the CN/HA may require a > more localized solution to achieve a reasonable handoff. > => Yes but if you have two interfaces then I'd argue that anticipation is not needed or not a realistic action to expect. This is due to the fact that most devices with two interfaces are typically connected to different access technologies. It seems unrealistic IMHO to expect a WLAN network to anticipate your movement to a CDMA network and vice versa. All you would need in that case is a localised agent to minimise the BU latencies and the number of BUs sent. FMIP was not designed for the multi-interfaces case or if a system has a carefully designed make before break handover. GT> Hesham you make some assumptions here that I do not agree with..a single radio technology can have make before break capabilities in which case a node can be multihomed to two ARs for a short amount of time (via the same interface/technology) and to the same domain. The multihomed time needs to be minimized for radio/spectrum/resource efficiency reasons in which case the FMIP specs become very useful indeed. George From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 25 08:34:59 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA15792 for ; Wed, 25 Jul 2001 08:34:58 -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 GAA00099; Wed, 25 Jul 2001 06:35:29 -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 FAA19429; Wed, 25 Jul 2001 05:35:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PCRkv16185 for mobile-ip-dist; Wed, 25 Jul 2001 05:27:46 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PCRfY16162 for ; Wed, 25 Jul 2001 05:27:41 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA13536 for ; Wed, 25 Jul 2001 05:25:46 -0700 (PDT) Received: from meshpdc.meshnetworks.com ([205.245.27.196]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA23980 for ; Wed, 25 Jul 2001 05:25:45 -0700 (PDT) Received: by meshpdc.meshnetworks.com with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Jul 2001 08:25:43 -0400 Message-ID: <0DF9FBC42474A24CA50F7A27FB08E0484455E4@meshpdc.meshnetworks.com> From: Phillip Neumiller To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Handover Smoothing - What to Do? Date: Wed, 25 Jul 2001 08:25:39 -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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: James, Arthur's explanation is right on. BTW, if you are interested in doing handover smoothing over IP for CDMA/3G RANs see US patents: 6,226,283 Method and selector for performing selection in a communication system 6,141,559 Method and apparatus for performing selection and distribution in a communication system 6,072,790 Method and apparatus for performing distribution in a communication system It is VERY possible to do macro-scopic diversity combining/selection OVER IP. In fact SCTP offers a nice way to do this. My two cents... Phil Neumiller MeshNetworks, Inc. > -----Original Message----- > From: Arthur Ross [mailto:a.ross@ieee.org] > Sent: Tuesday, July 24, 2001 5:48 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: RE: [mobile-ip] Handover Smoothing - What to Do? > > > At 13:39 -0700 07/24/2001, James Kempf wrote: > > > >In general, I don't know any way to synchronize packet delivery > >between oFA and nFA. I believe CDMA does this by having a > >very short window (something like 20 ms) during which soft handover > >occurs, and using GPS (in cdma2000) to synchronize soft handover > >between BTSs. This is not possible in IP, if for no other reason than > >the packet sizes can vary, and not all radio protocols have access > >to GPS synchronization. There are a variety of heurstics that > >could be used, however, and I think it makes sense to write > >them down. > > > James et al: > > The issue here is the nature of the diversity that is available in > any given RAN technology. The simplest is unsynchronized multicasting > - packets are sent from more than one source, without any attempt at > synchronization other than that imposed by sequence numbering. > > The various flavors of CDMA technology, on the other hand, employ a > very sophisticated symbol-by-symbol optimal ratio (in the downlink) > combining. This substantially improves error performance under > adverse propagation conditions. That combining is, in essence, a > vector sum of received symbol amplitude estimates from whatever > sources are available. The signal components add amplitude-wise, > while the noise components add power-wise (i.e. rss), hence the > improvement in overall SNR of the resultant. This technique relies on > the same sequence of symbols be radiated the various BTSs > participating in this "soft" handoff. > > The CDMA return link diversity combining is done in a different way, > but also makes use of multiple symbol streams from the various BTS > receivers involved in the handoff. > > As you say, this is done with the aid of GPS-derived precise timing. > Synchronization is not fundamentally necessary, but it is extremely > convenient in implementing the combining, and helps keep the latency > low. Other less precisely timed forms are possible in principle, but > have not, as far as I know, ever been proposed or implemented. To do > so would require substantially buffering and de-skewing of the symbol > streams. That buffering and deskewing would contribute objectionable > latency and variance of latency, both very objectionable in a speech > service. > > The 20 ms of which you speak is the CDMA frame size. That size has > its origins in the size of the vocoder frames. The FEC is blocked in > those 20 ms frames - each frame can be decoded and CRC checked > independently. Again, not fundamental, but because of the dominance > of the speech service, it is probably here to stay, or at least will > be around for a long time. > > Re "handoff smoothing" - It is, I think, desirable to recognize the > variety of diversity techniques that may be used in the radio link, > depending on the particular technology, and to provide the > tools/mechanisms the can accommodate that variety somehow. This is, > obviously, intimately intertwined with the QoS issues. What is ok for > a dumb datagram service may be manifestly awful for a speech service. > > Just my 2 cents worth ... > > -- Regards, AHMR > From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 25 08:35:36 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA15864 for ; Wed, 25 Jul 2001 08:35:35 -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 GAA00652; Wed, 25 Jul 2001 06:36:06 -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 FAA19518; Wed, 25 Jul 2001 05:35:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PCQUF15778 for mobile-ip-dist; Wed, 25 Jul 2001 05:26:30 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PCQLY15712 for ; Wed, 25 Jul 2001 05:26:21 -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 FAA16199 for ; Wed, 25 Jul 2001 05:26:02 -0700 (PDT) Received: from RRMAIL01.RADIOROUTER_NT ([63.103.94.23]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA25179 for ; Wed, 25 Jul 2001 06:25:57 -0600 (MDT) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Jul 2001 08:25:57 -0400 Message-ID: <8C92E23A3E87FB479988285F9E22BE460546B1@ftmail> From: George Tsirtsis To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Handover Smoothing - What to Do? Date: Wed, 25 Jul 2001 08:25:56 -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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: -----Original Message----- From: Hesham Soliman (ERA) [mailto:Hesham.Soliman@era.ericsson.se] Sent: Wednesday, July 25, 2001 11:39 AM To: 'mobile-ip@sunroof.eng.sun.com' Subject: RE: [mobile-ip] Handover Smoothing - What to Do? James, > I think we agree that specifications of smoothing and fast handoff do not need > to be linked, if only for practical considerations. > => I would like to understand your point here. What difference does it make if we put the smoothing techniques in the same draft (as the low latency draft does) or leave them out (as in the v6 draft) ? If we believe smoothing is essential as you said below then why keep it out of a draft which was designed specifically to reduce L3 losses and delays due to the MIP handover ? GT> The difference is that we have relative agreement on the FMIP specs NOW! We do not have the same agreement on smoothing...putting them together will delay both which is not what we want...I think... If I'm implementing this function in a product, don't I have to do the smoothing anyway ? GT> You may do...but as I said there are ways to do smoothing without any "protocol work" i.e.: a router can buffer or even bicast without involving any other element in the network in which case there is no need to have a protocol specification for it and your implementation can still work fine. George From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 25 08:38:13 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA16146 for ; Wed, 25 Jul 2001 08:38:12 -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 GAA02306; Wed, 25 Jul 2001 06:38:50 -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 FAA20648; Wed, 25 Jul 2001 05:38:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PCbI717824 for mobile-ip-dist; Wed, 25 Jul 2001 05:37:18 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PCbDY17807 for ; Wed, 25 Jul 2001 05:37:13 -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 FAA12143 for ; Wed, 25 Jul 2001 05:20:08 -0700 (PDT) Received: from explore.kwangwoon.ac.kr ([128.134.70.30]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA21038 for ; Wed, 25 Jul 2001 06:20:04 -0600 (MDT) Received: from ics-svr3 (ics-svr3.kwangwoon.ac.kr [128.134.70.20]) by explore.kwangwoon.ac.kr (8.9.3/8.9.3) with SMTP id VAA23083; Wed, 25 Jul 2001 21:14:38 +0900 (KST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA20438; Wed, 25 Jul 2001 06:19:25 -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 FAA11968; Wed, 25 Jul 2001 05:19:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PCHXt12502 for mobile-ip-dist; Wed, 25 Jul 2001 05:17:33 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PCHSY12491 for ; Wed, 25 Jul 2001 05:17:28 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA11655 for ; Wed, 25 Jul 2001 05:17:41 -0700 (PDT) Received: from explore.kwangwoon.ac.kr ([128.134.70.30]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA00042 for ; Wed, 25 Jul 2001 05:17:39 -0700 (PDT) Received: from ics-svr3 (ics-svr3.kwangwoon.ac.kr [128.134.70.20]) by explore.kwangwoon.ac.kr (8.9.3/8.9.3) with SMTP id VAA22616; Wed, 25 Jul 2001 21:12:08 +0900 (KST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA24052; Wed, 25 Jul 2001 05:14: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 FAA11136; Wed, 25 Jul 2001 05:13:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PCCF112291 for mobile-ip-dist; Wed, 25 Jul 2001 05:12:15 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PCCBY12284 for ; Wed, 25 Jul 2001 05:12: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 FAA17634 for ; Wed, 25 Jul 2001 05:12:24 -0700 (PDT) Received: from p-mail2.cnet.fr (p-mail2.rd.francetelecom.fr [193.49.124.32]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id GAA16689 for ; Wed, 25 Jul 2001 06:12:21 -0600 (MDT) Received: by p-voyageur.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Jul 2001 14:11:53 +0200 Received: from francetelecom.com (p-dico.rd.francetelecom.fr [139.100.18.135]) by p-grive.rd.francetelecom.fr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3ZBB7WHC; Wed, 25 Jul 2001 14:11:49 +0200 Message-ID: <3B5EB756.2DA0B166@francetelecom.com> Date: Wed, 25 Jul 2001 14:11:02 +0200 From: Jean-Michel COMBES Organization: France =?iso-8859-1?Q?T=E9l=E9com?= R&D X-Mailer: Mozilla 4.75 [fr] (Windows NT 5.0; U) X-Accept-Language: fr MIME-Version: 1.0 To: Claude Castelluccia CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Question on draft-team-mobileip-mipv6-sec-reqts-00.txt References: <697DAA22C5004B4596E033803A7CEF440860AD@daebe007.NOE.Nokia.com> <3B5DA26F.1D35859C@francetelecom.com> <3B5E7900.1CB3B95F@inrialpes.fr> Content-Type: text/plain; charset=iso-8859-1 List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by mercury.Sun.COM id FAA24052 X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f6PCHSY12492 List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by patan.sun.com id GAA20438 X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f6PCbEY17809 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: X-MIME-Autoconverted: from 8bit to quoted-printable by patan.sun.com id GAA02306 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA16146 Hi Claude, Claude Castelluccia a écrit : > Jean-Michel COMBES wrote: > >> Hi, >> >> JMC : In my point of view, the result is like a static host using >> spoofing >> ... the only threat that is specific to MIPv6 is on MN using an >> unauthorized H@ when it sends BU. > > Jean-Michel... > > sure....but in the static host case one might think that "ingress > filtering" might help > solving this specific problem sometimes... > With the HomeAddress option, ingress filtering can't do anything for > you (because > the source address is topologically correct)... JMC : You are right. > this makes the problem more difficult to > solve JMC : You are right again. :-) > and definetly different that the static host case.... JMC : I don't think so. What is ingress filtering ? A mecanism that filters packets, checks Source Address validity and authorizes (or not) them to go to their destination. Wrong ? (BTW, is there any draft about IPv6 Ingress Filtering ?). That's look like AAAv6 with intendant filtering fonction based on H@. > > I don't think you can argue that "this threat is not specific to > MIPv6"....it is! JMC : I'm not totally convinced. JMC. > > > Claude. > > > -- > > ---------------------------------------- > Claude CASTELLUCCIA, INRIA Rhone-Alpes > ph: +33 4.76.61.52.15 (fax: 52.52) > http://www.inrialpes.fr/planete/ > > -- 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 From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 25 08:42:21 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA16600 for ; Wed, 25 Jul 2001 08:42:20 -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 FAB03635; Wed, 25 Jul 2001 05:42:57 -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 FAA22911; Wed, 25 Jul 2001 05:42:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PCfC419007 for mobile-ip-dist; Wed, 25 Jul 2001 05:41:12 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PCf4Y18945 for ; Wed, 25 Jul 2001 05:41:04 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA22044 for ; Wed, 25 Jul 2001 05:41:08 -0700 (PDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA29367 for ; Wed, 25 Jul 2001 05:41:07 -0700 (PDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f6PCf6N05949 for ; Wed, 25 Jul 2001 14:41:06 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Wed Jul 25 14:41:02 2001 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Jul 2001 14:34:57 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008B56@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Handover Smoothing - What to Do? Date: Wed, 25 Jul 2001 14:40:56 +0200 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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > > The issue is whether the FMIP work is completely useless without > > > smoothing, or whether smoothing is so intertwined with the FMIP > > > work that it is impossible to put it into a separate spec. I think > > > the fact that the FMIPv6 draft managed to successfully disentangle > > > them argues that the smoothing work can be separated out from > > > a design perspective. Whether or not FMIP is useless without > > > smoothing from an operational or implementation perspective > > > is something that can only be determined by experiment. > > > > I'd say that it's not useless: if you have two interfaces, > > FMIP alone is probably sufficient since you can do a make > > before break while listening on both for some period of > > time. It might be pointed out that you could do that without > > the FMIP AR, but latencies back to the CN/HA may require a > > more localized solution to achieve a reasonable handoff. > > > => Yes but if you have two interfaces then I'd argue that > anticipation > is not needed or not a realistic action to expect. This is due to > the fact > that most devices with two interfaces are typically connected to > different access technologies. It seems unrealistic IMHO to expect > a WLAN network to anticipate your movement to a CDMA network > and vice versa. > > All you would need in that case is a localised agent to minimise the > BU latencies > and the number of BUs sent. FMIP was not designed for the > multi-interfaces > case or if a system has a carefully designed make before break > handover. > > > GT> Hesham you make some assumptions here that I do not agree with..a single > radio technology can have make before break capabilities in which case a > node can be multihomed to two ARs for a short amount of time (via the same > interface/technology) and to the same domain. > => Understood. That's what I meant in the last line above. > The multihomed time needs to > be minimized for radio/spectrum/resource efficiency reasons in which case > the FMIP specs become very useful indeed. > => Yes but could it not be long enough to send one BU ? Hesham From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 25 08:48:15 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA17189 for ; Wed, 25 Jul 2001 08:48:15 -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 GAA07570; Wed, 25 Jul 2001 06:48: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 FAA11566; Wed, 25 Jul 2001 05:48:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PClO819590 for mobile-ip-dist; Wed, 25 Jul 2001 05:47:24 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PClKY19583 for ; Wed, 25 Jul 2001 05:47:21 -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 FAA22651 for ; Wed, 25 Jul 2001 05:47:33 -0700 (PDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA28272 for ; Wed, 25 Jul 2001 06:48:57 -0600 (MDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f6PClVN09213 for ; Wed, 25 Jul 2001 14:47:31 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Wed Jul 25 14:47:27 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Jul 2001 14:47:31 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008B57@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Handover Smoothing - What to Do? Date: Wed, 25 Jul 2001 14:47:26 +0200 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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > I think we agree that specifications of smoothing and fast handoff do not > need > > to be linked, if only for practical considerations. > > > => I would like to understand your point here. What difference does > it > make if we put the smoothing techniques in the same draft > (as the low latency draft does) or leave them out (as in the v6 > draft) ? > If we believe smoothing is essential as you said below then why keep > it > out of a draft which was designed specifically to reduce L3 losses > and > delays due to the MIP handover ? > > GT> The difference is that we have relative agreement on the FMIP specs NOW! > We do not have the same agreement on smoothing...putting them together will > delay both which is not what we want...I think... > => Ok so the difference is on the technical merits of the solution. Hence putting it in another draft will not solve this difference. So why don't we discuss these differences on the technical side first and agree to have the solution or not have it altogether (ie in any draft) ? Wouldn't that be better for the group, instead of writing another set of drafts and dragging this for even longer periods. > If I'm implementing this function in a product, don't I have to do > the smoothing > anyway ? > > GT> You may do...but as I said there are ways to do smoothing without any > "protocol work" i.e.: a router can buffer or even bicast without involving > => There are two cases that are common in both the v4 and v6 drafts. In one case the MN sends a BU/registration and in another it doesn't. What you say above is applicable to the latter but not the former. A MN must be able to request bicasting otherwise if it moves back to the old AR (ping pong) it will need to send a new BU since it will have no knowledge that bicasting was happening or for how long. So this case would require the protocol work described in the bicasting draft. Hesham From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 25 08:52:42 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA17616 for ; Wed, 25 Jul 2001 08:52:41 -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 GAA10338; Wed, 25 Jul 2001 06:53: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 FAA11950; Wed, 25 Jul 2001 05:53:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PCqA319677 for mobile-ip-dist; Wed, 25 Jul 2001 05:52:10 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PCq7Y19670 for ; Wed, 25 Jul 2001 05:52:07 -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 FAA16706 for ; Wed, 25 Jul 2001 05:52:20 -0700 (PDT) Received: from RRMAIL01.RADIOROUTER_NT ([63.103.94.23]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA00318 for ; Wed, 25 Jul 2001 06:53:36 -0600 (MDT) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Jul 2001 08:52:05 -0400 Message-ID: <8C92E23A3E87FB479988285F9E22BE460546B5@ftmail> From: George Tsirtsis To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Handover Smoothing - What to Do? Date: Wed, 25 Jul 2001 08:52:05 -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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: -----Original Message----- From: Hesham Soliman (ERA) [mailto:Hesham.Soliman@era.ericsson.se] Sent: Wednesday, July 25, 2001 1:41 PM To: 'mobile-ip@sunroof.eng.sun.com' Subject: RE: [mobile-ip] Handover Smoothing - What to Do? > > > The issue is whether the FMIP work is completely useless without > > > smoothing, or whether smoothing is so intertwined with the FMIP > > > work that it is impossible to put it into a separate spec. I think > > > the fact that the FMIPv6 draft managed to successfully disentangle > > > them argues that the smoothing work can be separated out from > > > a design perspective. Whether or not FMIP is useless without > > > smoothing from an operational or implementation perspective > > > is something that can only be determined by experiment. > > > > I'd say that it's not useless: if you have two interfaces, > > FMIP alone is probably sufficient since you can do a make > > before break while listening on both for some period of > > time. It might be pointed out that you could do that without > > the FMIP AR, but latencies back to the CN/HA may require a > > more localized solution to achieve a reasonable handoff. > > > => Yes but if you have two interfaces then I'd argue that > anticipation > is not needed or not a realistic action to expect. This is due to > the fact > that most devices with two interfaces are typically connected to > different access technologies. It seems unrealistic IMHO to expect > a WLAN network to anticipate your movement to a CDMA network > and vice versa. > > All you would need in that case is a localised agent to minimise the > BU latencies > and the number of BUs sent. FMIP was not designed for the > multi-interfaces > case or if a system has a carefully designed make before break > handover. > > > GT> Hesham you make some assumptions here that I do not agree with..a single > radio technology can have make before break capabilities in which case a > node can be multihomed to two ARs for a short amount of time (via the same > interface/technology) and to the same domain. > => Understood. That's what I meant in the last line above. > The multihomed time needs to > be minimized for radio/spectrum/resource efficiency reasons in which case > the FMIP specs become very useful indeed. > => Yes but could it not be long enough to send one BU ? GT> That is a call that we can not make here but you can imagine that weather is long enough to send a BU may depend on many factors like RTT times and topological distance between ARs etc...No matter, I think the point was that FMIP can be useful in make before break. George From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 25 09:09:48 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA18877 for ; Wed, 25 Jul 2001 09:09:47 -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 GAA12658; Wed, 25 Jul 2001 06:10: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 GAA13790; Wed, 25 Jul 2001 06:10:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PD8u119797 for mobile-ip-dist; Wed, 25 Jul 2001 06:08:56 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PD8rY19790 for ; Wed, 25 Jul 2001 06:08:53 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA18425 for ; Wed, 25 Jul 2001 06:09:06 -0700 (PDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA08814 for ; Wed, 25 Jul 2001 06:09:05 -0700 (PDT) Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f6PD94O01289 for ; Wed, 25 Jul 2001 15:09:04 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Wed Jul 25 15:09:04 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Jul 2001 15:09:04 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008B59@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] draft-tkn-mobileip-qosbinding-mipv6-00.txt Date: Wed, 25 Jul 2001 15:08:54 +0200 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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > > > Why do we need CT(oldAR to MAP)? Since downlink data flows thorugh MAP and > > assuming that QoS was established using h-b-h option, MAP can just store > > that object along with mobility bindings. So when it receives BU from > > whaterver router (old or new) for this binding, it knows how to and where to > > send h-b-h option in BA. Doing CT from AR to MAP will open up can of worms > > each worm trying to do CT between AR and its application proxy. > > Theoretically the QoS can be stored either in MAP or AR. However, if > storing > in MAP, what happens for an inter-MAP mobility? A MN may initate a new > BU+QoS from MN-->(nAR)-->MAP? Or ask the oMAP to perform > CT(oMAP-->nMAP)? > Or additionally, ask QoS-CT(oMAP-->nAR)? Note we have to further the > BU+QoS > towards the higher level of hierarchy until the switching point (either > might be a MAP or HA or even CN), and this may result in a strange > sequence > in BU and QoS setup. > > In contrast, if storing in MAP, except the case of Fast Handoffs, > => You can do the same for the Fast Handoffs case as well. You could check Appendix A of HMIPv6 for the details (no QoS just the interactionwith Fast Handoffs). => Hesham From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 25 10:52:14 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA27757 for ; Wed, 25 Jul 2001 10:52:13 -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 HAA21444; Wed, 25 Jul 2001 07:52: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 HAA17889; Wed, 25 Jul 2001 07:51:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PEoPZ21756 for mobile-ip-dist; Wed, 25 Jul 2001 07:50:25 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PEoMY21749 for ; Wed, 25 Jul 2001 07:50: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 HAA01824 for ; Wed, 25 Jul 2001 07:50:34 -0700 (PDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id IAA29684 for ; Wed, 25 Jul 2001 08:50:32 -0600 (MDT) Received: (qmail 3672 invoked by uid 500); 25 Jul 2001 14:39:33 -0000 Date: Wed, 25 Jul 2001 07:39:33 -0700 From: Pat Calhoun To: mobile-ip@sunroof.eng.sun.com Cc: iesg@ietf.org Subject: Re: [mobile-ip] RE: Last Call: Generalized NAI (GNAIE) Extension to Proposed Standard Message-ID: <20010725073933.B10225@charizard.diameter.org> References: <200107201604.MAA14030@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from fredrik.johansson@ipunplugged.com on Wed, Jul 25, 2001 at 02:15:41PM +0200 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: It was removed because it conflicted with the MN NAI defined in RFC 2794. So, instead of introducing multiple ways to encode the same thing, and end up with possible interoperability problems, we decided to eliminate the subtype. Perhaps one day a mobile will have a different type of identity to add (e.g. old foreign agent's NAI), so the sentence is still valid. PatC On Wed, Jul 25, 2001 at 02:15:41PM +0200, Fredrik Johansson wrote: > In sectin 3.0, subtypes are defined. > > 1. Is there a reason to why the MN_NAI has been removed as a subtype? > 2. If there is no MN_NAI subtype, the sentence > "When a mobile node or home agent adds a GNAI extension to a > registration message, the extension MUST appear prior to any > authentication extensions." > doesn't make sence. Why should a mobile node add a GNAI with a subtype of > the FA or HA? > > I suggest that the MN_NAI subtype be added again. > > "Sub-Type > > This field describes the type of the entity which owns the NAI. > The following subtypes are defined: > > 1 HA_NAI > 2 FA_NAI > > When a mobile node or home agent adds a GNAI extension to a > registration message, the extension MUST appear prior to any > authentication extensions." > > /Fredrik > > >-----Original Message----- > >From: scoya@cnri.reston.va.us [mailto:scoya@cnri.reston.va.us]On Behalf > >Of The IESG > >Sent: den 20 juli 2001 18:05 > >To: IETF-Announce: > >Cc: mobile-ip@sunroof.eng.sun.com > >Subject: Last Call: Generalized NAI (GNAIE) Extension to Proposed > >Standard > > > > > > > >The IESG has received a request from the IP Routing for Wireless/Mobile > >Hosts Working Group to consider Generalized NAI (GNAIE) Extension > > as a Proposed Standard. > > > >The IESG plans to make a decision in the next few weeks, and solicits > >final comments on this action. Please send any comments to the > >iesg@ietf.org or ietf@ietf.org mailing lists by August 17, 2001. > > > >Files can be obtained via > >http://www.ietf.org/internet-drafts/draft-ietf-mobileip-gnaie-04.txt > > > > > From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 25 11:42:52 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA02638 for ; Wed, 25 Jul 2001 11:42:51 -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 JAA15827; Wed, 25 Jul 2001 09:43:28 -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 IAA07755; Wed, 25 Jul 2001 08:43:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PFfaF22108 for mobile-ip-dist; Wed, 25 Jul 2001 08:41:36 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PFfXY22101 for ; Wed, 25 Jul 2001 08:41:33 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id IAA28726 for ; Wed, 25 Jul 2001 08:41:46 -0700 (PDT) Message-Id: <200107251541.IAA28726@heliopolis.eng.sun.com> Date: Wed, 25 Jul 2001 08:41:45 -0700 (PDT) From: James Kempf Subject: RE: [mobile-ip] Handover Smoothing - What to Do? To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: FpoVa9miyWW9HIjFi9ybkA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 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: Hi Hesham, >> I think we agree that specifications of smoothing and fast handoff do not need >> to be linked, if only for practical considerations. >> > => I would like to understand your point here. What difference does it > make if we put the smoothing techniques in the same draft > (as the low latency draft does) or leave them out (as in the v6 draft) ? > If we believe smoothing is essential as you said below then why keep it > out of a draft which was designed specifically to reduce L3 losses and > delays due to the MIP handover ? > Like I said, practical considerations. The difference may be a year delay in whether the base FMIP gets through the IESG to proposed standard. I think there is wide agreement (dare I say rough concensus? :-) on FMIP, but there appears to be no concensus on smoothing. > If I'm implementing this function in a product, don't I have to do the smoothing > anyway ? > Agree 100%. But we've got to have a better understanding of the issues before we can standardize. > Therefore, I think for prctical reasons we should actually have them in the > same draft. Otherwise the only difference would be more drafts, more paper > work and unncessary cycles consumed. > Well, I understand where you are coming from, as I would like a complete handover solution to be done soon too. But realistically, it takes as long as it takes. If we can peel off the FMIP work and get IESG to take a look at that, we can reduce the amount of time later when we do reach concensus on smoothing. I'd like to hear from the WG chairs and ADs on this, I guess, since it seems to me basically a procedural issue. Raj has already come out for keeping smoothing separate for now, what do the rest of you think? jak From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 25 11:59:20 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA04387 for ; Wed, 25 Jul 2001 11:59:18 -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 JAA01671; Wed, 25 Jul 2001 09:59: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 IAA11459; Wed, 25 Jul 2001 08:59:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PFvt222477 for mobile-ip-dist; Wed, 25 Jul 2001 08:57:55 -0700 (PDT) Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PFvpY22467 for ; Wed, 25 Jul 2001 08:57:51 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA20353; Wed, 25 Jul 2001 11:57:06 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f6PFuTS21588; Wed, 25 Jul 2001 11:56:29 -0400 (EDT) Message-Id: <200107251556.f6PFuTS21588@thunk.east.sun.com> From: Bill Sommerfeld To: mobile-ip@sunroof.eng.sun.com cc: Alexis , Phil Roberts , "Basavaraj Patil (NTC/Dallas)" , Abha Ahuja , Thomas Narten , Dave Johnson , Jeff Schiller , Marcus Leech , Pekka Nikander Subject: Re: [Fwd: [mobile-ip] Mobile IPv6 clarifications] In-reply-to: Your message of "Tue, 24 Jul 2001 14:56:57 PDT." <3B5DEF29.CE1C831D@iprg.nokia.com> Date: Wed, 25 Jul 2001 11:56:29 -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: > i thought the real problem with the use of IPSec was with > distinguishing a destination options header containing a > BU and a destination options header containing some other > option. this is not possible with current IPsec selectors. Vijay, This is a *consequence* of the issue I pointed out yesterday: namely, that if you allow for traffic on a connection/flow to contain a mix of encrypted and unencrypted packets, you open yourself up to various nasty denial of service attacks, and IPsec cannot provide useful guarantees to upper layers. > if piggybacking a BU was the problem, we could have solved > it long back. just disallow piggybacking. anyway its a 'MAY' > in the current draft. you dont lose much by not piggybacking > the BU. I disagree. If it's a "MAY", then folks will build implementations which always piggyback, which will cause interoperabilty problems with IPsec implementations (such as Solaris's) which do per-connection policy checks. > of course, the other problem is the lack of a global PKI. > > If I receive an AH-protected packet containing a binding update and a > > TCP SYN, a receiver cannot know for sure whether the sender intended > > the AH protection to apply just to the binding update, or also to > > subsequent packets that are part of the TCP connection. > > dont sent those two together, then. you dont HAVE to piggyback. It's not that simple. It's an interoperability issue. If piggybacking remains optional, the sender chooses whether to piggyback, while the *receiver* either does or does not do the connection-oriented policy checks which would cause subsequent unencrypted packets to the connection to be dropped.. This causes a perverse result that high quality IPsec implementations which do the policy checks will fail to interoperate, while low quality IPsec implementations will appear to work (while not providing appropriate levels of protection to the traffic). - Bill (Solaris IPsec implementor) From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 25 12:07:12 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05202 for ; Wed, 25 Jul 2001 12:07:11 -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 KAA10194; Wed, 25 Jul 2001 10:07: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 IAA10817; Wed, 25 Jul 2001 08:57:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PFsr022273 for mobile-ip-dist; Wed, 25 Jul 2001 08:54:53 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PFsnY22266 for ; Wed, 25 Jul 2001 08:54:49 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id IAA29423 for ; Wed, 25 Jul 2001 08:55:03 -0700 (PDT) Message-Id: <200107251555.IAA29423@heliopolis.eng.sun.com> Date: Wed, 25 Jul 2001 08:55:02 -0700 (PDT) From: James Kempf Subject: RE: [mobile-ip] Handover Smoothing - What to Do? To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: PYUdwPS7MD32GwrsR+Cq4Q== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 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: Hesham, >> GT> The difference is that we have relative agreement on the FMIP specs NOW! >> We do not have the same agreement on smoothing...putting them together will >> delay both which is not what we want...I think... >> > => Ok so the difference is on the technical merits of the solution. > Hence putting it in another draft will not solve this difference. > So why don't we discuss these differences on the technical side > first and agree to have the solution or not have it altogether (ie in any draft) ? > Wouldn't that be better for the group, instead of writing another > set of drafts and dragging this for even longer periods. > The problem is that the technical disagreement is so severe it will probably take a couple of implementations and some data collection to work them out. At least, that is my perception. And that takes time. jak From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 25 12:09:41 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05542 for ; Wed, 25 Jul 2001 12:09: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 KAA13094; Wed, 25 Jul 2001 10:10:15 -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 JAA12861; Wed, 25 Jul 2001 09:04:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PG3Wx23200 for mobile-ip-dist; Wed, 25 Jul 2001 09:03:32 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PG3SY23193 for ; Wed, 25 Jul 2001 09:03:28 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id JAA29951 for ; Wed, 25 Jul 2001 09:03:42 -0700 (PDT) Message-Id: <200107251603.JAA29951@heliopolis.eng.sun.com> Date: Wed, 25 Jul 2001 09:03:41 -0700 (PDT) From: James Kempf Subject: Re: [mobile-ip] Handover Smoothing - What to Do? To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: weLQ6XKoeR4eRPrdMdtozA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 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: Behcet, I don't think anybody has proposed integrating LMM, FMIP and smoothing, and, in fact, I think that would probably draw out the standardization even longer. W.r.t. LMM, we should probably start a separate thread about what to do, which I will let up to you if you like. jak >Date: Wed, 25 Jul 2001 10:56:40 -0500 >From: Behcet Sarikaya >To: mobile-ip@sunroof.eng.sun.com >Subject: Re: [mobile-ip] Handover Smoothing - What to Do? > >Fast handovers are good, smooth and fast handovers are even better. >I favor coming up preferrably a single draft which achieves this integrated into the >LMM, and it seems that the leading draft for LMM is HMIP. > >This put into the fast track standardization should resolve Raj's concerns. >Any thoughts on this? > >Regards, > >James Kempf wrote: > >> Hi Hesham, >> >> >> I think we agree that specifications of smoothing and fast handoff do not >> need >> >> to be linked, if only for practical considerations. >> >> >> > => I would like to understand your point here. What difference does it >> > make if we put the smoothing techniques in the same draft >> > (as the low latency draft does) or leave them out (as in the v6 draft) ? >> > If we believe smoothing is essential as you said below then why keep it >> > out of a draft which was designed specifically to reduce L3 losses and >> > delays due to the MIP handover ? >> > >> >> Like I said, practical considerations. The difference may be a year >> delay in whether the base FMIP gets through the IESG to proposed standard. >> I think there is wide agreement (dare I say rough concensus? :-) on FMIP, >> but there appears to be no concensus on smoothing. >> >> > If I'm implementing this function in a product, don't I have to do the >> smoothing >> > anyway ? >> > >> >> Agree 100%. But we've got to have a better understanding of >> the issues before we can standardize. >> >> > Therefore, I think for prctical reasons we should actually have them in >> the >> > same draft. Otherwise the only difference would be more drafts, more >> paper >> > work and unncessary cycles consumed. >> > >> >> Well, I understand where you are coming from, as I would like a complete >> handover solution to be done soon too. But realistically, it takes as >> long as it takes. If we can peel off the FMIP work and get IESG to >> take a look at that, we can reduce the amount of time later when >> we do reach concensus on smoothing. >> >> I'd like to hear from the WG chairs and ADs on this, I guess, since >> it seems to me basically a procedural issue. Raj has already come >> out for keeping smoothing separate for now, what do the rest of >> you think? >> >> jak > >-- >Behcet > From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 25 12:19:15 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA06480 for ; Wed, 25 Jul 2001 12:19:14 -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 JAA03399; Wed, 25 Jul 2001 09:20: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 JAA03251; Wed, 25 Jul 2001 09:19:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PGIF823948 for mobile-ip-dist; Wed, 25 Jul 2001 09:18:15 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PGICY23941 for ; Wed, 25 Jul 2001 09:18:12 -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 JAA21880 for ; Wed, 25 Jul 2001 09:18:25 -0700 (PDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA19548 for ; Wed, 25 Jul 2001 10:18:22 -0600 (MDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f6PGIMN13252 for ; Wed, 25 Jul 2001 18:18:22 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Wed Jul 25 18:18:18 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Jul 2001 18:18:22 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008B5C@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Handover Smoothing - What to Do? Date: Wed, 25 Jul 2001 18:18:17 +0200 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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi James, I'll respond to both mails in one. > >> I think we agree that specifications of smoothing and fast handoff do not > need > >> to be linked, if only for practical considerations. > >> > > => I would like to understand your point here. What difference does it > > make if we put the smoothing techniques in the same draft > > (as the low latency draft does) or leave them out (as in the v6 draft) ? > > If we believe smoothing is essential as you said below then why keep it > > out of a draft which was designed specifically to reduce L3 losses and > > delays due to the MIP handover ? > > > > Like I said, practical considerations. The difference may be a year > delay in whether the base FMIP gets through the IESG to proposed standard. > => I don't understand the reasoning here. You say in another mail that the technical differences are severe. So far I haven't heard one technical objection yet. All the objections are on whether we should have it in the same draft or not. Since I know you do agree with the concepts for smoothing, it would be good if people highlight exactly what's missing (_technically_) in the proposal. This shouldn't take long. As for the technical concerns raised in the v6 DT (I don't know if you know about these) they are all addressed in the draft. As to whether we have agreement on FMIP, we do agree so far on the v4 draft (no one objected to the bicasting or buffering there) but certainly I can't agree that the v6 draft is ready when there is a major gap that would cause packet losses. The gap is addressed in the v4 draft and no one objected to that. > > If I'm implementing this function in a product, don't I have to do the > smoothing > > anyway ? > > > > Agree 100%. But we've got to have a better understanding of > the issues before we can standardize. > => I can only speak of our propsal, this is almost 18 months old now. This is quite unusual for a draft. So I think now is the right time to voice concerns. > > Therefore, I think for prctical reasons we should actually have them in > the > > same draft. Otherwise the only difference would be more drafts, more > paper > > work and unncessary cycles consumed. > > > > Well, I understand where you are coming from, as I would like a complete > handover solution to be done soon too. But realistically, it takes as > long as it takes. If we can peel off the FMIP work and get IESG to > take a look at that, we can reduce the amount of time later when > we do reach concensus on smoothing. > => MIPv6 is a good analogy. It can't go ahead because security is an integral part of the solution. The initial goal o Fast Handoffs was to minimise latencies and packet loss due to MIP handovers. If we introduce anticipation without a supporting mechanism then we haven't actually met the initial target. This discussion can carry on for a long time, but as I said above, without people voicing technical objections we're really wasting the WG's valuable time. Hesham From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 25 12:19:53 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA06534 for ; Wed, 25 Jul 2001 12:19:53 -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 JAA03819; Wed, 25 Jul 2001 09:20:49 -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 JAA03438; Wed, 25 Jul 2001 09:20:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PGJEE23993 for mobile-ip-dist; Wed, 25 Jul 2001 09:19:14 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PGJAY23983 for ; Wed, 25 Jul 2001 09:19:10 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA22065 for ; Wed, 25 Jul 2001 09:19:22 -0700 (PDT) Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA10372 for ; Wed, 25 Jul 2001 09:19:22 -0700 (PDT) Received: from inrialpes.fr (glandon.inrialpes.fr [194.199.24.105]) by ebene.inrialpes.fr (8.11.3/8.11.3) with ESMTP id f6PGGd825202; Wed, 25 Jul 2001 18:16:39 +0200 (MEST) Message-ID: <3B5EF17B.6558FBB@inrialpes.fr> Date: Wed, 25 Jul 2001 18:19:07 +0200 From: Thierry Ernst Organization: INRIA Rhone-Alpes X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Mobile IP CC: Hong-Yon Lach , Claude Castelluccia Subject: [mobile-ip] Network Mobility Support: Requirements 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 Dear all, In order to prepare the next IETF meeting, I would like to point out that we (MOTOROLA and INRIA Planete) have submitted a new draft that deals with mobility of an entire network: "Network Mobility Support in IPv6: Problem Statement and Requirements" http://search.ietf.org/internet-drafts/draft-ernst-mobileip-monetv6-00.txt This new draft discusses characteristics and problems and define the terminology. More importantly, it lists a number of REQUIREMENTS for Network Mobility Support. I would like interested people to go read the draft on to discuss it on the mailing list prior to next meeting. I have a slot to discuss issues and requirements pertaining to this. Following this discussion, I would like to ask to include "Network Mobiliy Support" in the Mobile IP Working Group charter. Many people have already manifested interest in this, and nobody is against it up to now. Then, your feedback is very important. Actually, we have 2 drafts. Please do not confuse them: - "Network Mobility Support in IPv6: Problem Statement and Requirements" http://search.ietf.org/internet-drafts/draft-ernst-mobileip-monetv6-00.txt Motorola Labs and INRIA Planete, France 13 July 2001 This draft is generic and does not propose any solutions, just problems and requirements. - "Mobile Networks Support in Mobile IPv6 (Prefix Scope Binding Updates)" http://search.ietf.org/internet-drafts/draft-ernst-mobileip-v6-network-02.txt Motorola Labs and INRIA Planete, France Last Update: 22 June 2001 - draft-00 presented at 48th IETF Pittsburgh. This draft proposes Mobile IPv6 enhancements (advertising a careof address for a prefix). The "security issues" section has been enhanced in the last update, together with other things. See section changes. If you have any comments on this, please discuss it on the mailing list too. The terminology used in the two drafts is a bit different, because there was a need to refine it. Thanks, Thierry. -- * mailto:Thierry.Ernst@inrialpes.fr Tel +33 (0) 4 76 61 52 69 * INRIA Rhone-Alpes Projet PLANETE (fax 52 52) * and MOTOROLA Labs Paris * http://www.inrialpes.fr/planete/people/ernst/Welcome.html From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 25 12:22:22 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA06851 for ; Wed, 25 Jul 2001 12:22: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 KAA25041; Wed, 25 Jul 2001 10:23: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 JAA04190; Wed, 25 Jul 2001 09:22:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PGLpE24105 for mobile-ip-dist; Wed, 25 Jul 2001 09:21:51 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PGLmY24098 for ; Wed, 25 Jul 2001 09:21:48 -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 JAA03897 for ; Wed, 25 Jul 2001 09:22:01 -0700 (PDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA23557 for ; Wed, 25 Jul 2001 10:21:58 -0600 (MDT) Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f6PGLvO24608 for ; Wed, 25 Jul 2001 18:21:57 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Wed Jul 25 18:21:57 2001 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Jul 2001 18:15:48 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008B5D@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Handover Smoothing - What to Do? Date: Wed, 25 Jul 2001 18:21:53 +0200 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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi James, > I don't think anybody has proposed integrating LMM, FMIP and smoothing, > and, in fact, I think that would probably draw out the standardization > even longer. > => No need to do addition standards work for that. we proposed it, Please check : http://www.globecom.net/ietf/draft/draft-elmalki-soliman-hmipv4v6-00.html which was presented in Adelaide last year and Appendix A of the new HMIPv6. They show how FMIP and HMIPv6 can be combined > W.r.t. LMM, we should probably start a separate thread about what to > do, which I will let up to you if you like. > => Agreed. Hesham From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 25 12:25:33 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07138 for ; Wed, 25 Jul 2001 12:25:32 -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 JAA07042; Wed, 25 Jul 2001 09:26:27 -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 JAA05294; Wed, 25 Jul 2001 09:26:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PGPAV24192 for mobile-ip-dist; Wed, 25 Jul 2001 09:25:10 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PGP6Y24185 for ; Wed, 25 Jul 2001 09:25:06 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA05718 for ; Wed, 25 Jul 2001 09:25:18 -0700 (PDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA14885 for ; Wed, 25 Jul 2001 09:25:09 -0700 (PDT) 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 f6PGAqJ20657; Wed, 25 Jul 2001 09:13:42 -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 AAW07018; Wed, 25 Jul 2001 09:12:35 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA10773; Wed, 25 Jul 2001 09:12:35 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15198.61427.638753.967320@thomasm-u1.cisco.com> Date: Wed, 25 Jul 2001 09:12:35 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Cc: Alexis , Phil Roberts , "Basavaraj Patil (NTC/Dallas)" , Abha Ahuja , Thomas Narten , Dave Johnson , Jeff Schiller , Marcus Leech , Pekka Nikander Subject: Re: [Fwd: [mobile-ip] Mobile IPv6 clarifications] In-Reply-To: <200107251556.f6PFuTS21588@thunk.east.sun.com> References: <3B5DEF29.CE1C831D@iprg.nokia.com> <200107251556.f6PFuTS21588@thunk.east.sun.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 Bill Sommerfeld writes: > > i thought the real problem with the use of IPSec was with > > distinguishing a destination options header containing a > > BU and a destination options header containing some other > > option. this is not possible with current IPsec selectors. > > Vijay, > > This is a *consequence* of the issue I pointed out yesterday: namely, > that if you allow for traffic on a connection/flow to contain a mix of > encrypted and unencrypted packets, you open yourself up to various > nasty denial of service attacks, and IPsec cannot provide useful > guarantees to upper layers. Bill, I think you two are actually in violent agreement, as I read Vijay's comment as meaning that killing piggybacking in the spec if that were necessary wouldn't be any huge loss. However, your comment about mixed traffic bothers me quite a bit. A very ordinary mix of traffic for mobile nodes will probably be SRTP (secure RTP) media probably over ROHC header compression, but using IPsec for most other signaling. This is an extremely appealing combination since the high bandwidth media is heavily optimized, but the relatively low bandwidth signaling is fully protected. If you think this is a bogus use of IPsec, I'd appreciate if you'd elaborate on it more. Mike From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 25 12:30:36 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07717 for ; Wed, 25 Jul 2001 12:30:31 -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 JAA09913; Wed, 25 Jul 2001 09:31: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 JAA06664; Wed, 25 Jul 2001 09:31:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PGTPU24285 for mobile-ip-dist; Wed, 25 Jul 2001 09:29:25 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PGTLY24274 for ; Wed, 25 Jul 2001 09:29:21 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id JAA01230 for ; Wed, 25 Jul 2001 09:29:35 -0700 (PDT) Message-Id: <200107251629.JAA01230@heliopolis.eng.sun.com> Date: Wed, 25 Jul 2001 09:29:34 -0700 (PDT) From: James Kempf Subject: RE: [mobile-ip] Handover Smoothing - What to Do? To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: wzalODXSXZVQJpXZnSeqEA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 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: Hi Hesham, > As for the technical concerns raised in the v6 DT (I don't know > if you know about these) they are all addressed in the draft. > Yes, that's what I meant. My impression from George's email is that he is still not comfortable with the work in the draft. Hongli also brought up the issue of jitter. I'm working on a note concerning that at the moment, which I hope to post later today. > As to whether we have agreement on FMIP, we do agree so far > on the v4 draft (no one objected to the bicasting or buffering there) > but certainly I can't agree that the v6 draft is ready when there > is a major gap that would cause packet losses. The gap is addressed > in the v4 draft and no one objected to that. > I believe the intent is not to completely exclude mention of smoothing, but rather to make a reference to it in the FMIP drafts. Of course, if we do this, then we have effectively linked them, because the FMIP drafts can't go to RFC without the smoothing drafts also going to RFC. > => MIPv6 is a good analogy. It can't go ahead because security > is an integral part of the solution. The initial goal o Fast Handoffs > was to minimise latencies and packet loss due to MIP handovers. > If we introduce anticipation without a supporting mechanism > then we haven't actually met the initial target. > > This discussion can carry on for a long time, but as I said > above, without people voicing technical objections we're > really wasting the WG's valuable time. > I certainly agree there. jak From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 25 13:18:53 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12969 for ; Wed, 25 Jul 2001 13:18:53 -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 LAA14285; Wed, 25 Jul 2001 11:19:38 -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 KAA20197; Wed, 25 Jul 2001 10:19:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PHHT824650 for mobile-ip-dist; Wed, 25 Jul 2001 10:17:29 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.82.166] (may be forged)) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PHHOY24643 for ; Wed, 25 Jul 2001 10:17:24 -0700 (PDT) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by jurassic.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with SMTP id f6PHHZS714792 for ; Wed, 25 Jul 2001 10:17:35 -0700 (PDT) Message-Id: <200107251717.f6PHHZS714792@jurassic.eng.sun.com> Date: Wed, 25 Jul 2001 13:18:01 -0400 (EDT) From: Steven Glass - Solaris Software Subject: [mobile-ip] The recent mail-loop... To: mobile-ip@sunroof.eng.sun.com X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5_11 SunOS 5.8.1 sun4u sparc Content-Type: text X-Sun-Text-Type: 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 believe the email loop problem we just experienced has been fixed. The timing, existing as it does, had this happenned overnight here in the US, and so wasn't noticed until this morning. I'll be monitoring the headers a little closer for a while to make sure it's done with. For the curious, it was a machine in .kr, and (hopefully) ironically, one of the email addresses I removed was "memories@..." Cheers, Steve From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 25 13:20:55 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13297 for ; Wed, 25 Jul 2001 13:20:55 -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 LAA16456; Wed, 25 Jul 2001 11:21: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 KAA20742; Wed, 25 Jul 2001 10:21:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PHKS324687 for mobile-ip-dist; Wed, 25 Jul 2001 10:20:28 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PHKPY24680 for ; Wed, 25 Jul 2001 10:20:25 -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 KAA20582 for ; Wed, 25 Jul 2001 10:20:38 -0700 (PDT) Received: from RRMAIL01.RADIOROUTER_NT ([63.103.94.23]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA15214 for ; Wed, 25 Jul 2001 11:20:36 -0600 (MDT) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Jul 2001 13:20:36 -0400 Message-ID: <8C92E23A3E87FB479988285F9E22BE460546B8@ftmail> From: George Tsirtsis To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Handover Smoothing - What to Do? Date: Wed, 25 Jul 2001 13:20:33 -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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: -----Original Message----- From: James Kempf [mailto:James.Kempf@Sun.COM] Sent: Wednesday, July 25, 2001 5:30 PM To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Handover Smoothing - What to Do? Hi Hesham, > As for the technical concerns raised in the v6 DT (I don't know > if you know about these) they are all addressed in the draft. > Yes, that's what I meant. My impression from George's email is that he is still not comfortable with the work in the draft. Hongli also brought up the issue of jitter. I'm working on a note concerning that at the moment, which I hope to post later today. > As to whether we have agreement on FMIP, we do agree so far > on the v4 draft (no one objected to the bicasting or buffering there) > but certainly I can't agree that the v6 draft is ready when there > is a major gap that would cause packet losses. The gap is addressed > in the v4 draft and no one objected to that. > I believe the intent is not to completely exclude mention of smoothing, but rather to make a reference to it in the FMIP drafts. Of course, if we do this, then we have effectively linked them, because the FMIP drafts can't go to RFC without the smoothing drafts also going to RFC. > => MIPv6 is a good analogy. It can't go ahead because security > is an integral part of the solution. The initial goal o Fast Handoffs > was to minimise latencies and packet loss due to MIP handovers. > If we introduce anticipation without a supporting mechanism > then we haven't actually met the initial target. > > This discussion can carry on for a long time, but as I said > above, without people voicing technical objections we're > really wasting the WG's valuable time. > I certainly agree there. GT> My very first e-mail on this thread included a *technical* concern about this...which boils down (again!) to the undisputed fact that bicasting may affect TCP in the ways I stated before and in the circumstance that were discussed in this thread. The argument has not been disputed; Instead Hesham/Karim has pointed to the EIFEL work which I bet is good and it actually confirms that there IS a problem with bicasting (otherwise why is there a draft about fixing the problem??). My objection to this is that even if Eifel becomes a standard RFC today it would not help! the question is how long it would take to go into all the Internet connected Hosts...albeit long time? Any word from Microsoft implementing it yet? So, IMO a spec that suggest a mechanism that at the moment has unknown potential effects to the Internet at large I think is not responsible behavior by the IETF, even if it is only a MAY. Putting bicasting in a different draft would allow it to become Information or Experimental RFC until EIFEL becomes available and we get some implementation experience. I think it is unfair to say that the argument is not technical...we have actually discussed this before in the DT and every time it kind of annoys me when you guys say that. It seams that you think that my technical objection is not important and I respect your opinion but that does not mean that there is no *technical* argument. I hope the WG chairs make a decision on this...I think the arguments are reasonably clear and there is no point discussing this further unless *other* people want to voice opinions. Regards George From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 25 13:32:18 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14435 for ; Wed, 25 Jul 2001 13:32:17 -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 KAA11741; Wed, 25 Jul 2001 10:33:07 -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 KAA23519; Wed, 25 Jul 2001 10:32:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PHUQ424802 for mobile-ip-dist; Wed, 25 Jul 2001 10:30:26 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PHULY24795 for ; Wed, 25 Jul 2001 10:30:21 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA22769 for ; Wed, 25 Jul 2001 10:30:28 -0700 (PDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id KAA29589 for ; Wed, 25 Jul 2001 10:30:28 -0700 (PDT) Received: (qmail 5345 invoked by uid 500); 25 Jul 2001 17:19:27 -0000 Date: Wed, 25 Jul 2001 10:19:27 -0700 From: Pat Calhoun To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] The recent mail-loop... Message-ID: <20010725101927.J10225@charizard.diameter.org> References: <200107251717.f6PHHZS714792@jurassic.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200107251717.f6PHHZS714792@jurassic.eng.sun.com>; from glass@jurassic.eng.sun.com on Wed, Jul 25, 2001 at 01:18:01PM -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: FWIW, I've been noticing problems on the seamoby list, but because of the filters I've applied, it didn't actually cause a loop. I've removed the e-mail address you mention below, and it seems to have fixed the problem. PatC On Wed, Jul 25, 2001 at 01:18:01PM -0400, Steven Glass - Solaris Software wrote: > I believe the email loop problem we just experienced has been fixed. The > timing, existing as it does, had this happenned overnight here in the US, and so > wasn't noticed until this morning. I'll be monitoring the headers a little > closer for a while to make sure it's done with. > > For the curious, it was a machine in .kr, and (hopefully) ironically, one of > the email addresses I removed was "memories@..." > > Cheers, > Steve From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 25 13:32:22 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14454 for ; Wed, 25 Jul 2001 13:32: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 LAA25876; Wed, 25 Jul 2001 11:33: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 KAA23618; Wed, 25 Jul 2001 10:33:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PHVmw24824 for mobile-ip-dist; Wed, 25 Jul 2001 10:31:48 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PHViY24817 for ; Wed, 25 Jul 2001 10:31:44 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id KAA04580 for ; Wed, 25 Jul 2001 10:31:58 -0700 (PDT) Message-Id: <200107251731.KAA04580@heliopolis.eng.sun.com> Date: Wed, 25 Jul 2001 10:31:57 -0700 (PDT) From: James Kempf Subject: [mobile-ip] Analysis of Jitter in Bicasting To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: p8Q1r5W4zwW9RDVu8bTwCA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 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: Hongyi's note about jitter and bicasting spurred a bit of pondering about how to get a better idea of the problem, similiar to the bounds on buffering in draft-kempf-beth-ipv6-01.txt. The following is an analysis, not as mathematically based as the buffering bounds, but still perhaps useful. It seems to me that jitter is one technical problem that the proponents of bicasting need to address in order to have a convincing solution. Consider the following sequence of packets from the CN: CN packet stream: x,x+1,x+2,x+3,x+4,x+5... where x is the sequence number when bicasting begins. There are two possible cases where jitter could cause duplication or dropped packets: 1) A packet is delayed on the bicast link to the new AR due to network congestion between the source of the bicast and the new AR: old L2 packet stream: x,x+1,x+2,x+3,x+4,x+5... new AR packet stream: x,x+1,...,x+2,x+3,x+4,x+5... In this case, the MN gets a duplicate packet when it appears on the new L2. For example, if the MN hands off at x+3, it gets a duplicate x+4 packet. 2) A packet is delayed on the old L2 link due to deterioration in the radio conditions approaching handoff: old L2 packet stream: x,x+1,...,x+2,x+3,x+4,x+5,... new AR packet stream: x,x+1,x+2,x+3,x+4,x+5,... In this case, a packet is dropped. For example, if the MN hands off at x+3, it will miss x+4. In the case of 1, the probability of a duplicate packet has nothing whatsoever to do with the radio link. It is purely a matter of traffic engineering in the wired network. So the probablility of a duplicate packet can be reduced by properly engineering the wired network. In addition, the probability is likely to increase with the topological distance between the new AR and the source of the bicast (simply because, the more network a packet has to traverse, the more likely it is that a congestion event may cause delay). Since engineering of the wired network is largely under the network operator's control, this problem is fairly straightforward to solve, though it may require measures such as overprovisioning. The same is not true of 2. Radio conditions at handover are not entirely controllable through network engineering. They change based on dynamic factors such as what types of objects (like big trucks) sit between the MN and the radio AP, in addition to more static factors. So a more likely source of problems due to jitter is a dropped packet due to delay of a packet on the radio link. Before drilling down on this problem, I'd like to consider two different kinds of bicasting that have been proposed, since I think they have very different properties with regard to a solution. The differences may not be clear in people's minds, though there have been illusions to them in the email. They are: 1) Simultaneous bindings, in which an agent (HA/RegReg/MAP, etc.) back in the network is bicasting simultaneously to the old AR and new AR (reference: draft-elmalki-mobileip-bicasting-v6-00.txt). 2) Edge tunnels, in which the old AR is bicasting to the new AR (references: draft-kempf-beth-ipv6-01.txt, draft-ietf-mobileip-lowlatency-handoffs-ipv4-01.txt, and implied in draft-ietf-mobileip-fast-mipv6-01.txt if the old CoA is used on the new AR). In 1), signalling from the MN establishes simultaneous bindings for old and new CoA. In 2), the routers (or FAs for MIPv4) bicast without the MN becoming involved. The delay of a packet on the radio link usually happens because radio conditions deteriorate. Bit error rates around handover can escalate to 10**-3 or 10**-2, something unheard of on wired networks. At 10**-3, one could expect a bit error on every Ethernet-sized (1500 byte) packet. To counter this, most radio protocols have relatively small L2 frame sizes, and perform retransmit on a frame basis. So a bit error in a single radio frame doesn't require the entire packet to drop. The net effect of increased bit error rate and retransmit is that the MN begins to see a decrease in the IP data rate as radio conditions become worse during handover. If the rate near the center of the cell is 9.6 kbps, maybe it drops to 5 kbps as handover approaches. Of course, if the MN doesn't handover, it drops to 0 kbps and the connection is severed. If we assume that the wired network provides a data rate considerably higher (like 2-3 orders of magnitude) than the radio network, one way to solve this problem is to clock the bicast data rate to the radio link rate. So if the radio link slows down to 5 kbps, the bicast link going out from the source does too. If this is done, the bicast source can delay sending a packet out over the bicast stream until it is finished sending on the radio link. This assures that the packet does not get to the new AR (where it will be dropped if the MN hasn't arrived yet) before it gets to the MN. Or, it can even *not* send the packet since the bicast source knows the MN has go it, and only send packets when the MN actually disappears due to L2 handover. In any event, with the simultaneous binding approach, the HA/RegReg/MAP agent is too far away from the radio link to be able to fine tune bicasting in this way without additional help. One could imagine further protocol support for getting this information to the agent, but since there would be a delay due to the transport time, it probably wouldn't help, as there could be hysteresis as the agent tried to catch up to the varying quality of the radio link. With the edge tunnel approach, since the tunnel runs from the old AR, the AR is in a position to obtain timely and accurate information on the dynamically changing data rate over the radio link. Examples here are the PDSN and GGSN for cdma2000 and wCDMA (resp.). For WLAN protocols, the AR might not be directly connected to the radio link, the radio link may rather be available via a radio AP that acts as a transparent bridge. These cases are harder to solve, since they have the same problem as the simultaneous bindings approach, namely the information on radio link data rate is not available at the AR. Again, protocol support for transferring the L2 information from the AP to the AR might help, and the delay is likely to be less because the AP is on link with the AR, but there is nevertheless the potential. So, in sum, the solution to jitter in bicasting is to tightly couple bicasting with the performance of the radio link, so that the bicast stream accurately reflects what the MN has received. This is not as strong a coupling as the synchronization used in CDMA, but it should work to reduce or eliminate packet drop for the most common case. In addition, the wired network must be properly provisioned to avoid congestion and thus duplicate packets on the bicast link. Comments? Did I miss anything? From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 25 13:33:31 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14567 for ; Wed, 25 Jul 2001 13:33:31 -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 LAA27123; Wed, 25 Jul 2001 11:34:23 -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 KAA23940; Wed, 25 Jul 2001 10:34:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PHWw024858 for mobile-ip-dist; Wed, 25 Jul 2001 10:32:58 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PHWrY24850 for ; Wed, 25 Jul 2001 10:32:53 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA23645 for ; Wed, 25 Jul 2001 10:33:06 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA00948 for ; Wed, 25 Jul 2001 10:33: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 KAA00827; Wed, 25 Jul 2001 10:31:43 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6PHVfC08782; Wed, 25 Jul 2001 10:31:41 -0700 X-mProtect: Wed, 25 Jul 2001 10:31:41 -0700 Nokia Silicon Valley Messaging Protection Received: from vijayd.iprg.nokia.com (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpd6LNHHE; Wed, 25 Jul 2001 10:31:39 PDT Message-ID: <3B5F027B.B4C09347@iprg.nokia.com> Date: Wed, 25 Jul 2001 10:31:39 -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: mobile-ip@sunroof.eng.sun.com CC: Alexis , Phil Roberts , "Basavaraj Patil (NTC/Dallas)" , Abha Ahuja , Thomas Narten , Dave Johnson , Jeff Schiller , Marcus Leech , Pekka Nikander Subject: Re: [Fwd: [mobile-ip] Mobile IPv6 clarifications] References: <200107251556.f6PFuTS21588@thunk.east.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 Bill, i meant 'if piggybacking the BU is a problem, we can put an explicit statement in the mobile ip draft which says BU MUST not be piggybacked with any packet'. this wont lead to any interoperability problems. the actual problem is every packet from the MN to the CN would have a home address option in a destination options header. i cant have an IPsec SA in which i can say 'protect only the packet which has protocol 60 AND a BU destination option'. i can only say 'protect protocol 60'. of course this can be solved by a simple hack in the implementation (i have done this), but everybody would have to implement this hack. and i dont see the IPSec specs being changed anytime. Vijay ( Nokia's MIPv6 AH implementor :-) ) Bill Sommerfeld wrote: > > > i thought the real problem with the use of IPSec was with > > distinguishing a destination options header containing a > > BU and a destination options header containing some other > > option. this is not possible with current IPsec selectors. > > Vijay, > > This is a *consequence* of the issue I pointed out yesterday: namely, > that if you allow for traffic on a connection/flow to contain a mix of > encrypted and unencrypted packets, you open yourself up to various > nasty denial of service attacks, and IPsec cannot provide useful > guarantees to upper layers. > > > if piggybacking a BU was the problem, we could have solved > > it long back. just disallow piggybacking. anyway its a 'MAY' > > in the current draft. you dont lose much by not piggybacking > > the BU. > > I disagree. If it's a "MAY", then folks will build implementations > which always piggyback, which will cause interoperabilty problems with > IPsec implementations (such as Solaris's) which do per-connection > policy checks. > > > of course, the other problem is the lack of a global PKI. > > > > If I receive an AH-protected packet containing a binding update and a > > > TCP SYN, a receiver cannot know for sure whether the sender intended > > > the AH protection to apply just to the binding update, or also to > > > subsequent packets that are part of the TCP connection. > > > > dont sent those two together, then. you dont HAVE to piggyback. > > It's not that simple. It's an interoperability issue. If > piggybacking remains optional, the sender chooses whether to > piggyback, while the *receiver* either does or does not do the > connection-oriented policy checks which would cause subsequent > unencrypted packets to the connection to be dropped.. > > This causes a perverse result that high quality IPsec implementations > which do the policy checks will fail to interoperate, while low > quality IPsec implementations will appear to work (while not providing > appropriate levels of protection to the traffic). > > - Bill > (Solaris IPsec implementor) From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 25 13:34:24 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14637 for ; Wed, 25 Jul 2001 13:34:23 -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 KAA12880; Wed, 25 Jul 2001 10:35:17 -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 KAA24209; Wed, 25 Jul 2001 10:35:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PHXsk24884 for mobile-ip-dist; Wed, 25 Jul 2001 10:33:54 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PHXpY24877 for ; Wed, 25 Jul 2001 10:33:51 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id KAA04673 for ; Wed, 25 Jul 2001 10:34:05 -0700 (PDT) Message-Id: <200107251734.KAA04673@heliopolis.eng.sun.com> Date: Wed, 25 Jul 2001 10:34:04 -0700 (PDT) From: James Kempf Subject: RE: [mobile-ip] Handover Smoothing - What to Do? To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: iIBd99ZhUiqI53MHFsNRtQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 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: George, I think there are ways to reduce or eliminate the problems with duplicate packets. I just sent out an analysis on this. I understand your concerns about EIFFEL. jak >From: George Tsirtsis >To: "'mobile-ip@sunroof.eng.sun.com'" >Subject: RE: [mobile-ip] Handover Smoothing - What to Do? >Date: Wed, 25 Jul 2001 13:20:33 -0400 > > >-----Original Message----- >From: James Kempf [mailto:James.Kempf@Sun.COM] >Sent: Wednesday, July 25, 2001 5:30 PM >To: mobile-ip@sunroof.eng.sun.com >Subject: RE: [mobile-ip] Handover Smoothing - What to Do? > > >Hi Hesham, > > >> As for the technical concerns raised in the v6 DT (I don't know >> if you know about these) they are all addressed in the draft. >> > >Yes, that's what I meant. My impression from George's email is >that he is still not comfortable with the work in the draft. Hongli >also brought up the issue of jitter. I'm working on a note >concerning that at the moment, which I hope to post later today. > >> As to whether we have agreement on FMIP, we do agree so far >> on the v4 draft (no one objected to the bicasting or buffering >there) >> but certainly I can't agree that the v6 draft is ready when there >> is a major gap that would cause packet losses. The gap is addressed >> in the v4 draft and no one objected to that. >> > >I believe the intent is not to completely exclude mention of >smoothing, but rather to make a reference to it in the FMIP drafts. >Of course, if we do this, then we have effectively linked them, because >the FMIP drafts can't go to RFC without the smoothing drafts also >going to RFC. > > >> => MIPv6 is a good analogy. It can't go ahead because security >> is an integral part of the solution. The initial goal o Fast >Handoffs >> was to minimise latencies and packet loss due to MIP handovers. >> If we introduce anticipation without a supporting mechanism >> then we haven't actually met the initial target. >> >> This discussion can carry on for a long time, but as I said >> above, without people voicing technical objections we're >> really wasting the WG's valuable time. >> > >I certainly agree there. > > >GT> My very first e-mail on this thread included a *technical* concern about >this...which boils down (again!) to the undisputed fact that bicasting may >affect TCP in the ways I stated before and in the circumstance that were >discussed in this thread. The argument has not been disputed; Instead >Hesham/Karim has pointed to the EIFEL work which I bet is good and it >actually confirms that there IS a problem with bicasting (otherwise why is >there a draft about fixing the problem??). My objection to this is that even >if Eifel becomes a standard RFC today it would not help! the question is how >long it would take to go into all the Internet connected Hosts...albeit long >time? Any word from Microsoft implementing it yet? So, IMO a spec that >suggest a mechanism that at the moment has unknown potential effects to the >Internet at large I think is not responsible behavior by the IETF, even if >it is only a MAY. Putting bicasting in a different draft would allow it to >become Information or Experimental RFC until EIFEL becomes available and we >get some implementation experience. > >I think it is unfair to say that the argument is not technical...we have >actually discussed this before in the DT and every time it kind of annoys me >when you guys say that. It seams that you think that my technical objection >is not important and I respect your opinion but that does not mean that >there is no *technical* argument. > >I hope the WG chairs make a decision on this...I think the arguments are >reasonably clear and there is no point discussing this further unless >*other* people want to voice opinions. > >Regards >George From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 25 13:38:28 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15188 for ; Wed, 25 Jul 2001 13:38:26 -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 KAA15024; Wed, 25 Jul 2001 10:39:18 -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 KAA25371; Wed, 25 Jul 2001 10:39:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PHc1U25033 for mobile-ip-dist; Wed, 25 Jul 2001 10:38:01 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PHbvY25026 for ; Wed, 25 Jul 2001 10:37:57 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA05066 for ; Wed, 25 Jul 2001 10:38:11 -0700 (PDT) Received: from meshpdc.meshnetworks.com ([205.245.27.196]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA22569 for ; Wed, 25 Jul 2001 10:38:10 -0700 (PDT) Received: by meshpdc.meshnetworks.com with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Jul 2001 13:38:09 -0400 Message-ID: <0DF9FBC42474A24CA50F7A27FB08E0484455EA@meshpdc.meshnetworks.com> From: Phillip Neumiller To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Analysis of Jitter in Bicasting Date: Wed, 25 Jul 2001 13:38:04 -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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: James, You just put in a jitter buffer. It adds a fixed amount of latency. The jitter is defined as the variance of delay. All you have to do is size the jitter buffer for this variance and you have solved this problem. Thanks, Phil > -----Original Message----- > From: James Kempf [mailto:James.Kempf@Sun.COM] > Sent: Wednesday, July 25, 2001 1:32 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: [mobile-ip] Analysis of Jitter in Bicasting > > > Hongyi's note about jitter and bicasting spurred a bit of pondering > about how to get a better idea of the problem, similiar to the > bounds on buffering in draft-kempf-beth-ipv6-01.txt. The following is > an analysis, not as mathematically based as the buffering bounds, but > still perhaps useful. It seems to me that jitter is one technical > problem that the proponents of bicasting need to address in order > to have a convincing solution. > > Consider the following sequence of packets from the CN: > > CN packet stream: x,x+1,x+2,x+3,x+4,x+5... > > where x is the sequence number when bicasting begins. > > There are two possible cases where jitter could cause duplication > or dropped packets: > > 1) A packet is delayed on the bicast link to the new AR due to network > congestion between the source of the bicast and the new AR: > > old L2 packet stream: x,x+1,x+2,x+3,x+4,x+5... > new AR packet stream: x,x+1,...,x+2,x+3,x+4,x+5... > > In this case, the MN gets a duplicate packet when it appears on the > new L2. For example, if the MN hands off at x+3, it gets a duplicate > x+4 packet. > > 2) A packet is delayed on the old L2 link due to deterioration in the > radio conditions approaching handoff: > > old L2 packet stream: x,x+1,...,x+2,x+3,x+4,x+5,... > new AR packet stream: x,x+1,x+2,x+3,x+4,x+5,... > > In this case, a packet is dropped. For example, if the MN hands off > at x+3, it will miss x+4. > > In the case of 1, the probability of a duplicate packet has nothing > whatsoever to do with the radio link. It is purely a matter of traffic > engineering in the wired network. So the probablility of a duplicate > packet can be reduced by properly engineering the wired network. In > addition, the probability is likely to increase with the topological > distance between the new AR and the source of the bicast (simply > because, the more network a packet has to traverse, the more likely > it is that a congestion event may cause delay). Since engineering > of the wired network is largely under the network operator's control, > this problem is fairly straightforward to solve, though it may > require measures such as overprovisioning. > > The same is not true of 2. Radio conditions at handover are > not entirely > controllable through network engineering. They change based on dynamic > factors such as what types of objects (like big trucks) sit > between the MN and > the radio AP, in addition to more static factors. So a more > likely source > of problems due to jitter is a dropped packet due to delay of a packet > on the radio link. > > Before drilling down on this problem, I'd like to consider > two different > kinds of bicasting that have been proposed, since I think they have > very different properties with regard to a solution. The differences > may not be clear in people's minds, though there have been illusions > to them in the email. They are: > > 1) Simultaneous bindings, in which an agent > (HA/RegReg/MAP, etc.) > back in the network is bicasting simultaneously to the old AR > and new AR (reference: > draft-elmalki-mobileip-bicasting-v6-00.txt). > > 2) Edge tunnels, in which the old AR is bicasting to the new AR > (references: draft-kempf-beth-ipv6-01.txt, > draft-ietf-mobileip-lowlatency-handoffs-ipv4-01.txt, > and implied > in draft-ietf-mobileip-fast-mipv6-01.txt if the old CoA is > used on the new AR). > > In 1), signalling from the MN establishes simultaneous bindings for > old and new CoA. In 2), the routers (or FAs for MIPv4) bicast without > the MN becoming involved. > > The delay of a packet on the radio link usually happens because radio > conditions deteriorate. Bit error rates around handover can escalate > to 10**-3 or 10**-2, something unheard of on wired networks. > At 10**-3, > one could expect a bit error on every Ethernet-sized (1500 byte) > packet. To counter this, most radio protocols have relatively small > L2 frame sizes, and perform retransmit on a frame basis. So a bit > error in a single radio frame doesn't require the entire packet to > drop. > > The net effect of increased bit error rate and retransmit is that > the MN begins to see a decrease in the IP data rate as radio > conditions > become worse during handover. If the rate near the center of the cell > is 9.6 kbps, maybe it drops to 5 kbps as handover approaches. Of > course, if the MN doesn't handover, it drops to 0 kbps and > the connection > is severed. > > If we assume that the wired network provides a data rate > considerably higher > (like 2-3 orders of magnitude) than the radio network, one way to > solve this problem is to clock the bicast data rate to the radio link > rate. So if the radio link slows down to 5 kbps, the bicast link going > out from the source does too. If this is done, the bicast source can > delay sending a packet out over the bicast stream until it is finished > sending on the radio link. This assures that the packet does not > get to the new AR (where it will be dropped if the MN hasn't > arrived yet) before it gets to the MN. Or, it can even *not* > send the packet > since the bicast source knows the MN has go it, and only send > packets when > the MN actually disappears due to L2 handover. > > In any event, with the simultaneous binding approach, the > HA/RegReg/MAP > agent is too far away from the radio link to be able to fine tune > bicasting in this way without additional help. One could > imagine further > protocol support for getting this information to the agent, but since > there would be a delay due to the transport time, it > probably wouldn't > help, as there could be hysteresis as the agent tried to catch up > to the varying quality of the radio link. > > With the edge tunnel approach, since the tunnel runs from the old > AR, the AR is in a position to obtain timely and accurate information > on the dynamically changing data rate over the radio link. Examples > here are the PDSN and GGSN for cdma2000 and wCDMA (resp.). For > WLAN protocols, the AR might not be directly connected to the radio > link, the radio link may rather be available via a radio AP > that acts as a transparent bridge. These cases are harder to > solve, since they > have the same problem as the simultaneous bindings approach, > namely the > information on radio link data rate is not available at the > AR. Again, protocol > support for transferring the L2 information from the AP to > the AR might > help, and the delay is likely to be less because the AP is on link > with the AR, but there is nevertheless the potential. > > So, in sum, the solution to jitter in bicasting is to tightly couple > bicasting with the performance of the radio link, so that the bicast > stream accurately reflects what the MN has received. This is not > as strong a coupling as the synchronization used in CDMA, but it > should work to reduce or eliminate packet drop for the most > common case. > In addition, the wired network must be properly provisioned to > avoid congestion and thus duplicate packets on the bicast link. > > Comments? Did I miss anything? > From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 25 13:44:07 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15737 for ; Wed, 25 Jul 2001 13:44:06 -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 KAA17688; Wed, 25 Jul 2001 10:44:58 -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 KAA26728; Wed, 25 Jul 2001 10:44:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PHgnL25109 for mobile-ip-dist; Wed, 25 Jul 2001 10:42:49 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PHgjY25102 for ; Wed, 25 Jul 2001 10:42:45 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA06023 for ; Wed, 25 Jul 2001 10:42:59 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA06519 for ; Wed, 25 Jul 2001 10:42:57 -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 KAA02119 for ; Wed, 25 Jul 2001 10:42:56 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6PHgtH08362 for ; Wed, 25 Jul 2001 10:42:55 -0700 X-mProtect: Wed, 25 Jul 2001 10:42:55 -0700 Nokia Silicon Valley Messaging Protection Received: from vijayd.iprg.nokia.com (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdi1bsix; Wed, 25 Jul 2001 10:42:54 PDT Message-ID: <3B5F051F.65ECBD0C@iprg.nokia.com> Date: Wed, 25 Jul 2001 10:42:55 -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: mobile-ip@sunroof.eng.sun.com Subject: Re: [Fwd: [mobile-ip] Mobile IPv6 clarifications] References: <200107241727.f6OHRlS08219@thunk.east.sun.com> <3B5DEF29.CE1C831D@iprg.nokia.com> <3B5EB91D.AA53720D@francetelecom.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 Jean-Michel COMBES wrote: > > JMC : why not attribute a different "Next Header" value (ie. not equal to > 60) to BU/BAck ? With this solution and "no piggybacking", IPsec will work > fine. Francis Dupont tried it at the San Diego IETF. but people in the IPng working group werent too happy. the draft was draft-dupont-destoptupd-00.txt and check out http://www.ietf.org/proceedings/00dec/toc.htm#P137_4468 for comments from folks in the IPng WG. vijay > > 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 From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 25 13:51:10 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16551 for ; Wed, 25 Jul 2001 13:51:09 -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 KAA20776; Wed, 25 Jul 2001 10:52:04 -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 KAA26689; Wed, 25 Jul 2001 10:51:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PHooc25208 for mobile-ip-dist; Wed, 25 Jul 2001 10:50:50 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PHokY25201 for ; Wed, 25 Jul 2001 10:50:46 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA13641 for ; Wed, 25 Jul 2001 10:51:00 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA11477 for ; Wed, 25 Jul 2001 10:50: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 KAA02826; Wed, 25 Jul 2001 10:49:38 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6PHnbP26564; Wed, 25 Jul 2001 10:49:37 -0700 X-mProtect: Wed, 25 Jul 2001 10:49:37 -0700 Nokia Silicon Valley Messaging Protection Received: from vijayd.iprg.nokia.com (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdsoCNQf; Wed, 25 Jul 2001 10:49:35 PDT Message-ID: <3B5F06B0.D3460EA3@iprg.nokia.com> Date: Wed, 25 Jul 2001 10:49:36 -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: mobile-ip@sunroof.eng.sun.com CC: Alexis , Phil Roberts , "Basavaraj Patil (NTC/Dallas)" , Abha Ahuja , Thomas Narten , Dave Johnson , Jeff Schiller , Marcus Leech , Pekka Nikander Subject: Re: [Fwd: [mobile-ip] Mobile IPv6 clarifications] References: <200107241727.f6OHRlS08219@thunk.east.sun.com> <3B5DEF29.CE1C831D@iprg.nokia.com> <15197.63094.198068.928185@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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Michael Thomas wrote: > > Ah, that's very different, and I agree it would be > a problem with IPsec selectors. I guess I have to > ask that _if_ that was the intention of the -13 > draft, why. I didn't read it that way, but it's > quite possible I didn't notice that subtlety. If > the intention was not wanting other DO's to have > to be protected, I guess I have to wonder why. I'm > starting to think that Bill's suggestion of just > setting a up coarser ID selector (ie, don't select > based off of IP protocol) may be the right tweak > here. i have already done this as an hack in my implementation. but specifying this would be nice. vijay > > Frankly, I think that IPsec/IKE needs a face lift > here, because this is all screwed up; MIP has the > dubious distinction of being first to be blown up > by this land mine left over from the v4 centric > world. > > Mike > > > at least this is what Jeff Schiller said in his presentation > > at the minneapolis IETF. > > > > if piggybacking a BU was the problem, we could have solved > > it long back. just disallow piggybacking. anyway its a 'MAY' > > in the current draft. you dont lose much by not piggybacking > > the BU. > > > > of course, the other problem is the lack of a global PKI. > > > > Bill Sommerfeld wrote: > > > > > If I receive an AH-protected packet containing a binding update and a > > > TCP SYN, a receiver cannot know for sure whether the sender intended > > > the AH protection to apply just to the binding update, or also to > > > subsequent packets that are part of the TCP connection. > > > > dont sent those two together, then. you dont HAVE to piggyback. > > > > vijay > > > > > While I thought this option had been beaten to death, if folks still > > > want to use IPsec to protect MN/CN traffic, here are two possible ways > > > to deal: > > > > > > 1) disallow piggybacking, and always send binding updates separately > > > from user traffic. > > > > > > 2) since you've already paid the cost of setting up the IPsec > > > security associations, you might as well just keep using them -- once > > > a binding is established, *all* traffic between the MN and the CN > > > should be protected the same way. > > > > > > Note that even with this issue resolved, you still have to deal with > > > the PKI/authentication/etc. issues involved with SA setup; if > > > anything, this is a much harder problem.. > > > > > > - Bill From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 25 13:55:06 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16797 for ; Wed, 25 Jul 2001 13:55:06 -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 LAA15563; Wed, 25 Jul 2001 11:55:59 -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 KAA27789; Wed, 25 Jul 2001 10:55:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PHsFl25269 for mobile-ip-dist; Wed, 25 Jul 2001 10:54:15 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PHsBY25258 for ; Wed, 25 Jul 2001 10:54: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 KAA08884 for ; Wed, 25 Jul 2001 10:54:25 -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 LAA14000 for ; Wed, 25 Jul 2001 11:54:23 -0600 (MDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f6PHsX327540 for ; Wed, 25 Jul 2001 10:54:33 -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 AAW09950; Wed, 25 Jul 2001 10:54:23 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA10782; Wed, 25 Jul 2001 10:54:21 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15199.1997.584415.689007@thomasm-u1.cisco.com> Date: Wed, 25 Jul 2001 10:54:21 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Analysis of Jitter in Bicasting In-Reply-To: <0DF9FBC42474A24CA50F7A27FB08E0484455EA@meshpdc.meshnetworks.com> References: <0DF9FBC42474A24CA50F7A27FB08E0484455EA@meshpdc.meshnetworks.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 Phillip Neumiller writes: > James, > > You just put in a jitter buffer. It adds a fixed amount of latency. > The jitter is defined as the variance of delay. All you have to do > is size the jitter buffer for this variance and you have solved this > problem. Indeed, I suspect that the end-to-end principal is our friend here. Real time traffic already uses jitter buffers, and good ones are adaptive to transient conditions. For this kind of traffic, you most definitely would *not* want L2-L3 smoothing jitter out for you or you might end up with unnecessary additive latency. I'm not sure that jitter concealment would be all that useful in other places though. TCP's should be fairly resilient to small amounts of jitter, which I would expect would be the case with localized handoff schemes such as FMIP (ie, adding 80ms to an average RTT of 80ms because of FMIP handoff, should get lost in the noise.) Mike > > Thanks, > > Phil > > > -----Original Message----- > > From: James Kempf [mailto:James.Kempf@Sun.COM] > > Sent: Wednesday, July 25, 2001 1:32 PM > > To: mobile-ip@sunroof.eng.sun.com > > Subject: [mobile-ip] Analysis of Jitter in Bicasting > > > > > > Hongyi's note about jitter and bicasting spurred a bit of pondering > > about how to get a better idea of the problem, similiar to the > > bounds on buffering in draft-kempf-beth-ipv6-01.txt. The following is > > an analysis, not as mathematically based as the buffering bounds, but > > still perhaps useful. It seems to me that jitter is one technical > > problem that the proponents of bicasting need to address in order > > to have a convincing solution. > > > > Consider the following sequence of packets from the CN: > > > > CN packet stream: x,x+1,x+2,x+3,x+4,x+5... > > > > where x is the sequence number when bicasting begins. > > > > There are two possible cases where jitter could cause duplication > > or dropped packets: > > > > 1) A packet is delayed on the bicast link to the new AR due to network > > congestion between the source of the bicast and the new AR: > > > > old L2 packet stream: x,x+1,x+2,x+3,x+4,x+5... > > new AR packet stream: x,x+1,...,x+2,x+3,x+4,x+5... > > > > In this case, the MN gets a duplicate packet when it appears on the > > new L2. For example, if the MN hands off at x+3, it gets a duplicate > > x+4 packet. > > > > 2) A packet is delayed on the old L2 link due to deterioration in the > > radio conditions approaching handoff: > > > > old L2 packet stream: x,x+1,...,x+2,x+3,x+4,x+5,... > > new AR packet stream: x,x+1,x+2,x+3,x+4,x+5,... > > > > In this case, a packet is dropped. For example, if the MN hands off > > at x+3, it will miss x+4. > > > > In the case of 1, the probability of a duplicate packet has nothing > > whatsoever to do with the radio link. It is purely a matter of traffic > > engineering in the wired network. So the probablility of a duplicate > > packet can be reduced by properly engineering the wired network. In > > addition, the probability is likely to increase with the topological > > distance between the new AR and the source of the bicast (simply > > because, the more network a packet has to traverse, the more likely > > it is that a congestion event may cause delay). Since engineering > > of the wired network is largely under the network operator's control, > > this problem is fairly straightforward to solve, though it may > > require measures such as overprovisioning. > > > > The same is not true of 2. Radio conditions at handover are > > not entirely > > controllable through network engineering. They change based on dynamic > > factors such as what types of objects (like big trucks) sit > > between the MN and > > the radio AP, in addition to more static factors. So a more > > likely source > > of problems due to jitter is a dropped packet due to delay of a packet > > on the radio link. > > > > Before drilling down on this problem, I'd like to consider > > two different > > kinds of bicasting that have been proposed, since I think they have > > very different properties with regard to a solution. The differences > > may not be clear in people's minds, though there have been illusions > > to them in the email. They are: > > > > 1) Simultaneous bindings, in which an agent > > (HA/RegReg/MAP, etc.) > > back in the network is bicasting simultaneously to the old AR > > and new AR (reference: > > draft-elmalki-mobileip-bicasting-v6-00.txt). > > > > 2) Edge tunnels, in which the old AR is bicasting to the new AR > > (references: draft-kempf-beth-ipv6-01.txt, > > draft-ietf-mobileip-lowlatency-handoffs-ipv4-01.txt, > > and implied > > in draft-ietf-mobileip-fast-mipv6-01.txt if the old CoA is > > used on the new AR). > > > > In 1), signalling from the MN establishes simultaneous bindings for > > old and new CoA. In 2), the routers (or FAs for MIPv4) bicast without > > the MN becoming involved. > > > > The delay of a packet on the radio link usually happens because radio > > conditions deteriorate. Bit error rates around handover can escalate > > to 10**-3 or 10**-2, something unheard of on wired networks. > > At 10**-3, > > one could expect a bit error on every Ethernet-sized (1500 byte) > > packet. To counter this, most radio protocols have relatively small > > L2 frame sizes, and perform retransmit on a frame basis. So a bit > > error in a single radio frame doesn't require the entire packet to > > drop. > > > > The net effect of increased bit error rate and retransmit is that > > the MN begins to see a decrease in the IP data rate as radio > > conditions > > become worse during handover. If the rate near the center of the cell > > is 9.6 kbps, maybe it drops to 5 kbps as handover approaches. Of > > course, if the MN doesn't handover, it drops to 0 kbps and > > the connection > > is severed. > > > > If we assume that the wired network provides a data rate > > considerably higher > > (like 2-3 orders of magnitude) than the radio network, one way to > > solve this problem is to clock the bicast data rate to the radio link > > rate. So if the radio link slows down to 5 kbps, the bicast link going > > out from the source does too. If this is done, the bicast source can > > delay sending a packet out over the bicast stream until it is finished > > sending on the radio link. This assures that the packet does not > > get to the new AR (where it will be dropped if the MN hasn't > > arrived yet) before it gets to the MN. Or, it can even *not* > > send the packet > > since the bicast source knows the MN has go it, and only send > > packets when > > the MN actually disappears due to L2 handover. > > > > In any event, with the simultaneous binding approach, the > > HA/RegReg/MAP > > agent is too far away from the radio link to be able to fine tune > > bicasting in this way without additional help. One could > > imagine further > > protocol support for getting this information to the agent, but since > > there would be a delay due to the transport time, it > > probably wouldn't > > help, as there could be hysteresis as the agent tried to catch up > > to the varying quality of the radio link. > > > > With the edge tunnel approach, since the tunnel runs from the old > > AR, the AR is in a position to obtain timely and accurate information > > on the dynamically changing data rate over the radio link. Examples > > here are the PDSN and GGSN for cdma2000 and wCDMA (resp.). For > > WLAN protocols, the AR might not be directly connected to the radio > > link, the radio link may rather be available via a radio AP > > that acts as a transparent bridge. These cases are harder to > > solve, since they > > have the same problem as the simultaneous bindings approach, > > namely the > > information on radio link data rate is not available at the > > AR. Again, protocol > > support for transferring the L2 information from the AP to > > the AR might > > help, and the delay is likely to be less because the AP is on link > > with the AR, but there is nevertheless the potential. > > > > So, in sum, the solution to jitter in bicasting is to tightly couple > > bicasting with the performance of the radio link, so that the bicast > > stream accurately reflects what the MN has received. This is not > > as strong a coupling as the synchronization used in CDMA, but it > > should work to reduce or eliminate packet drop for the most > > common case. > > In addition, the wired network must be properly provisioned to > > avoid congestion and thus duplicate packets on the bicast link. > > > > Comments? Did I miss anything? > > From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 25 14:06:02 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA17951 for ; Wed, 25 Jul 2001 14:06: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 MAA25408; Wed, 25 Jul 2001 12:06:49 -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 LAA00622; Wed, 25 Jul 2001 11:06:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PI56525403 for mobile-ip-dist; Wed, 25 Jul 2001 11:05:06 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PI52Y25396 for ; Wed, 25 Jul 2001 11:05: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 LAA17245 for ; Wed, 25 Jul 2001 11:05:16 -0700 (PDT) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA12257 for ; Wed, 25 Jul 2001 12:06:40 -0600 (MDT) Received: by megisto-sql1.megisto.com with Internet Mail Service (5.5.2650.21) id ; Wed, 25 Jul 2001 14:03:45 -0400 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Handover Smoothing - What to Do? Date: Wed, 25 Jul 2001 14:03:44 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) 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: > Well, I understand where you are coming from, as I would like > a complete > handover solution to be done soon too. But realistically, it takes as > long as it takes. If we can peel off the FMIP work and get IESG to > take a look at that, we can reduce the amount of time later when > we do reach concensus on smoothing. > > I'd like to hear from the WG chairs and ADs on this, I guess, since > it seems to me basically a procedural issue. Raj has already come > out for keeping smoothing separate for now, what do the rest of > you think? > > jak > I wouldn't call it a procedural issue but a need to make a decision. I (personally) would like to make a consensus call on both FMIPv4 and FMIPv6 right after London and I don't want to send up drafts one with and one without an option for smoothing. So our consensus calls will probably be something like 1) do we want smoothing in a separate draft and if so, 2) is FMIPv6 ready for last call and is FMIPv4 ready for last call after we remove the smoothing bits; and if not 3) is FMIPv4 read for last call and FMIPv6 ready for last call after we add the smoothing bits. Right now it seems that George at least is uncomfortable with making smoothing an essential part of the FMIP draft. Hesham at least is uncomfortable with progressing the FMIP draft without smoothing. Hesham's position excludes the middle ground of putting smoothing into a separate draft. As an aside it seems clear that smoothing is an optional feature in the FMIPv4 draft but I'm not sure whether the proposal is to make it optional when incorporated in FMIPv6. There does seem to be some consensus that if a smoothing technique is chosen it should be through bicasting or simultaneous binding rather than some kind of buffering. At the minimum we should have a discussion of why the tradeoff of accepting the possibility of duplicate packets weighs more heavily than accepting the possibility of lost packets and the results should be documented. George has also asserted (and speaking for myself personally I also agree with) that implementations in some environments at least can solve this without any kind of protocol support at layer 3. Does this seem to summarize everyone's position accurately? Does this answer your question enough, Jim? Of course, others contributing to the conversation COULD help, Phil From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 25 14:27:01 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA20098 for ; Wed, 25 Jul 2001 14:27:00 -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 LAA09668; Wed, 25 Jul 2001 11:27:53 -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 LAA06213; Wed, 25 Jul 2001 11:27:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PIQ2U25636 for mobile-ip-dist; Wed, 25 Jul 2001 11:26:02 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PIPxY25629 for ; Wed, 25 Jul 2001 11:25:59 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id LAA07553 for ; Wed, 25 Jul 2001 11:26:12 -0700 (PDT) Message-Id: <200107251826.LAA07553@heliopolis.eng.sun.com> Date: Wed, 25 Jul 2001 11:26:11 -0700 (PDT) From: James Kempf Subject: RE: [mobile-ip] Analysis of Jitter in Bicasting To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 5dea1Vv7mLbKjAskAdV3tg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 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: Hi Phil, I like it! You've managed to say in 4 lines what took me a page and a half. jak >From: Phillip Neumiller >To: "'mobile-ip@sunroof.eng.sun.com'" >Subject: RE: [mobile-ip] Analysis of Jitter in Bicasting >Date: Wed, 25 Jul 2001 13:38:04 -0400 > >James, > >You just put in a jitter buffer. It adds a fixed amount of latency. >The jitter is defined as the variance of delay. All you have to do >is size the jitter buffer for this variance and you have solved this >problem. > >Thanks, > >Phil > >> -----Original Message----- >> From: James Kempf [mailto:James.Kempf@Sun.COM] >> Sent: Wednesday, July 25, 2001 1:32 PM >> To: mobile-ip@sunroof.eng.sun.com >> Subject: [mobile-ip] Analysis of Jitter in Bicasting >> >> >> Hongyi's note about jitter and bicasting spurred a bit of pondering >> about how to get a better idea of the problem, similiar to the >> bounds on buffering in draft-kempf-beth-ipv6-01.txt. The following is >> an analysis, not as mathematically based as the buffering bounds, but >> still perhaps useful. It seems to me that jitter is one technical >> problem that the proponents of bicasting need to address in order >> to have a convincing solution. >> >> Consider the following sequence of packets from the CN: >> >> CN packet stream: x,x+1,x+2,x+3,x+4,x+5... >> >> where x is the sequence number when bicasting begins. >> >> There are two possible cases where jitter could cause duplication >> or dropped packets: >> >> 1) A packet is delayed on the bicast link to the new AR due to network >> congestion between the source of the bicast and the new AR: >> >> old L2 packet stream: x,x+1,x+2,x+3,x+4,x+5... >> new AR packet stream: x,x+1,...,x+2,x+3,x+4,x+5... >> >> In this case, the MN gets a duplicate packet when it appears on the >> new L2. For example, if the MN hands off at x+3, it gets a duplicate >> x+4 packet. >> >> 2) A packet is delayed on the old L2 link due to deterioration in the >> radio conditions approaching handoff: >> >> old L2 packet stream: x,x+1,...,x+2,x+3,x+4,x+5,... >> new AR packet stream: x,x+1,x+2,x+3,x+4,x+5,... >> >> In this case, a packet is dropped. For example, if the MN hands off >> at x+3, it will miss x+4. >> >> In the case of 1, the probability of a duplicate packet has nothing >> whatsoever to do with the radio link. It is purely a matter of traffic >> engineering in the wired network. So the probablility of a duplicate >> packet can be reduced by properly engineering the wired network. In >> addition, the probability is likely to increase with the topological >> distance between the new AR and the source of the bicast (simply >> because, the more network a packet has to traverse, the more likely >> it is that a congestion event may cause delay). Since engineering >> of the wired network is largely under the network operator's control, >> this problem is fairly straightforward to solve, though it may >> require measures such as overprovisioning. >> >> The same is not true of 2. Radio conditions at handover are >> not entirely >> controllable through network engineering. They change based on dynamic >> factors such as what types of objects (like big trucks) sit >> between the MN and >> the radio AP, in addition to more static factors. So a more >> likely source >> of problems due to jitter is a dropped packet due to delay of a packet >> on the radio link. >> >> Before drilling down on this problem, I'd like to consider >> two different >> kinds of bicasting that have been proposed, since I think they have >> very different properties with regard to a solution. The differences >> may not be clear in people's minds, though there have been illusions >> to them in the email. They are: >> >> 1) Simultaneous bindings, in which an agent >> (HA/RegReg/MAP, etc.) >> back in the network is bicasting simultaneously to the old AR >> and new AR (reference: >> draft-elmalki-mobileip-bicasting-v6-00.txt). >> >> 2) Edge tunnels, in which the old AR is bicasting to the new AR >> (references: draft-kempf-beth-ipv6-01.txt, >> draft-ietf-mobileip-lowlatency-handoffs-ipv4-01.txt, >> and implied >> in draft-ietf-mobileip-fast-mipv6-01.txt if the old CoA is >> used on the new AR). >> >> In 1), signalling from the MN establishes simultaneous bindings for >> old and new CoA. In 2), the routers (or FAs for MIPv4) bicast without >> the MN becoming involved. >> >> The delay of a packet on the radio link usually happens because radio >> conditions deteriorate. Bit error rates around handover can escalate >> to 10**-3 or 10**-2, something unheard of on wired networks. >> At 10**-3, >> one could expect a bit error on every Ethernet-sized (1500 byte) >> packet. To counter this, most radio protocols have relatively small >> L2 frame sizes, and perform retransmit on a frame basis. So a bit >> error in a single radio frame doesn't require the entire packet to >> drop. >> >> The net effect of increased bit error rate and retransmit is that >> the MN begins to see a decrease in the IP data rate as radio >> conditions >> become worse during handover. If the rate near the center of the cell >> is 9.6 kbps, maybe it drops to 5 kbps as handover approaches. Of >> course, if the MN doesn't handover, it drops to 0 kbps and >> the connection >> is severed. >> >> If we assume that the wired network provides a data rate >> considerably higher >> (like 2-3 orders of magnitude) than the radio network, one way to >> solve this problem is to clock the bicast data rate to the radio link >> rate. So if the radio link slows down to 5 kbps, the bicast link going >> out from the source does too. If this is done, the bicast source can >> delay sending a packet out over the bicast stream until it is finished >> sending on the radio link. This assures that the packet does not >> get to the new AR (where it will be dropped if the MN hasn't >> arrived yet) before it gets to the MN. Or, it can even *not* >> send the packet >> since the bicast source knows the MN has go it, and only send >> packets when >> the MN actually disappears due to L2 handover. >> >> In any event, with the simultaneous binding approach, the >> HA/RegReg/MAP >> agent is too far away from the radio link to be able to fine tune >> bicasting in this way without additional help. One could >> imagine further >> protocol support for getting this information to the agent, but since >> there would be a delay due to the transport time, it >> probably wouldn't >> help, as there could be hysteresis as the agent tried to catch up >> to the varying quality of the radio link. >> >> With the edge tunnel approach, since the tunnel runs from the old >> AR, the AR is in a position to obtain timely and accurate information >> on the dynamically changing data rate over the radio link. Examples >> here are the PDSN and GGSN for cdma2000 and wCDMA (resp.). For >> WLAN protocols, the AR might not be directly connected to the radio >> link, the radio link may rather be available via a radio AP >> that acts as a transparent bridge. These cases are harder to >> solve, since they >> have the same problem as the simultaneous bindings approach, >> namely the >> information on radio link data rate is not available at the >> AR. Again, protocol >> support for transferring the L2 information from the AP to >> the AR might >> help, and the delay is likely to be less because the AP is on link >> with the AR, but there is nevertheless the potential. >> >> So, in sum, the solution to jitter in bicasting is to tightly couple >> bicasting with the performance of the radio link, so that the bicast >> stream accurately reflects what the MN has received. This is not >> as strong a coupling as the synchronization used in CDMA, but it >> should work to reduce or eliminate packet drop for the most >> common case. >> In addition, the wired network must be properly provisioned to >> avoid congestion and thus duplicate packets on the bicast link. >> >> Comments? Did I miss anything? >> From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 25 14:31:28 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA20578 for ; Wed, 25 Jul 2001 14:31:27 -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 LAA11784; Wed, 25 Jul 2001 11:32: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 LAA07506; Wed, 25 Jul 2001 11:31:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PIUQV25694 for mobile-ip-dist; Wed, 25 Jul 2001 11:30:26 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PIUNY25687 for ; Wed, 25 Jul 2001 11:30:23 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id LAA07903 for ; Wed, 25 Jul 2001 11:30:35 -0700 (PDT) Message-Id: <200107251830.LAA07903@heliopolis.eng.sun.com> Date: Wed, 25 Jul 2001 11:30:35 -0700 (PDT) From: James Kempf Subject: RE: [mobile-ip] Handover Smoothing - What to Do? To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: BfCPgOmh+mcXfYDwCaJlxg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 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: Hi Phil, >There does seem to be some consensus that if a smoothing technique is chosen >it should be through bicasting or simultaneous binding rather than some kind >of >buffering. At the minimum we should have a discussion of why the tradeoff >of >accepting the possibility of duplicate packets weighs more heavily than >accepting >the possibility of lost packets and the results should be documented. > I have not heard much from advocates of buffering in the discussion so far, so I would have to agree. >George has also asserted (and speaking for myself personally I also agree >with) >that implementations in some environments at least can solve this without >any kind >of protocol support at layer 3. > I agree also. >Does this seem to summarize everyone's position accurately? Does this >answer your question >enough, Jim? > Yes, thanx. >Of course, others contributing to the conversation COULD help, Agree. jak From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 25 14:34:08 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA20829 for ; Wed, 25 Jul 2001 14:34:07 -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 LAA13205; Wed, 25 Jul 2001 11:34: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 LAA08400; Wed, 25 Jul 2001 11:34:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PIXUX25768 for mobile-ip-dist; Wed, 25 Jul 2001 11:33:30 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PIXQY25761 for ; Wed, 25 Jul 2001 11:33:27 -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 LAA08110 for ; Wed, 25 Jul 2001 11:33:39 -0700 (PDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA28529 for ; Wed, 25 Jul 2001 12:35:02 -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.11.0/8.11.0/WIREfire-1.3) with SMTP id f6PIXaN06124 for ; Wed, 25 Jul 2001 20:33:36 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed Jul 25 20:33:31 2001 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Jul 2001 20:27:26 +0200 Message-ID: <795A014AF92DD21182AF0008C7A404320C520496@esealnt117> From: "Karim El-Malki (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Handover Smoothing - What to Do? Date: Wed, 25 Jul 2001 20:33:28 +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: George, > GT> My very first e-mail on this thread included a > *technical* concern about > this...which boils down (again!) to the undisputed fact that > bicasting may > affect TCP in the ways I stated before and in the > circumstance that were > discussed in this thread. It's not undisputed actually. In one of my previous emails I pointed out that the circumstances considered in low latency do not involve multiple packet delivery. The MN does not receive from multiple FAs and we use a smoothing mechanism in a way such that it does not get multiple copies of packets. So I'd say that bicasting should not be linked to TCP effects, unless your system is implemented in a way that the MN does receive multiple copies of packets. I think I gave an example where, if you bicast and buffer at nFA for a period equal to the L2 handover time, then you won't get duplicates. > The argument has not been disputed; Instead > Hesham/Karim has pointed to the EIFEL work which I bet is good and it > actually confirms that there IS a problem with bicasting > (otherwise why is > there a draft about fixing the problem??). No! EIFEL was not done to eliminate bicasting. This has nothing to do with bicasting. In general there is no guarantee that an IP network will give you in-order packet delivery or a single copy of packets delivered to you. That's independent of bicasting. So if you want to run low latency with bicasting and have a MN which can be simultaneously communicate with multiple FAs, then EIFEL helps solve the TCP problem. >My objection to > this is that even > if Eifel becomes a standard RFC today it would not help! the > question is how > long it would take to go into all the Internet connected > Hosts...albeit long > time? Any word from Microsoft implementing it yet? So, IMO a spec that > suggest a mechanism that at the moment has unknown potential > effects to the > Internet at large I think is not responsible behavior by the > IETF, even if > it is only a MAY. Putting bicasting in a different draft > would allow it to > become Information or Experimental RFC until EIFEL becomes > available and we > get some implementation experience. Well, you seem to be convinced that bicasting means that the MN receives multiple copies of packets. I tried my best in explaining why that won't happen... Haven't seen a good explanation as to why multiple packet delivery to the MN MUST happen with bicasting, that's the fundamental point. Rgds /Karim From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 25 14:37:35 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA21295 for ; Wed, 25 Jul 2001 14:37:34 -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 MAA21680; Wed, 25 Jul 2001 12:38:24 -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 LAA09376; Wed, 25 Jul 2001 11:38:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PIajV25823 for mobile-ip-dist; Wed, 25 Jul 2001 11:36:46 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PIagY25816 for ; Wed, 25 Jul 2001 11:36:42 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id LAA08397 for ; Wed, 25 Jul 2001 11:36:55 -0700 (PDT) Message-Id: <200107251836.LAA08397@heliopolis.eng.sun.com> Date: Wed, 25 Jul 2001 11:36:54 -0700 (PDT) From: James Kempf Subject: RE: [mobile-ip] Analysis of Jitter in Bicasting To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: yff9Wh0UWI5qrlh1PK3WJw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 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: > Indeed, I suspect that the end-to-end principal is our friend > here. Real time traffic already uses jitter buffers, and good > ones are adaptive to transient conditions. For this kind of > traffic, you most definitely would *not* want L2-L3 smoothing > jitter out for you or you might end up with unnecessary additive > latency. I'm not sure that jitter concealment would be all that > useful in other places though. TCP's should be fairly resilient > to small amounts of jitter, which I would expect would be the > case with localized handoff schemes such as FMIP (ie, adding > 80ms to an average RTT of 80ms because of FMIP handoff, should > get lost in the noise.) > The other alternative is to actually not bicast at all, but to simply have old AR start tunnelling when it sees that L2 has stopped sending packets through old AR. If it can get this information. Much more bandwidth efficient anyway... jak From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 25 14:53:03 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22891 for ; Wed, 25 Jul 2001 14:53: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 MAA04132; Wed, 25 Jul 2001 12:53:57 -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 LAA14085; Wed, 25 Jul 2001 11:53:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PIpm226030 for mobile-ip-dist; Wed, 25 Jul 2001 11:51:48 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PIpiY26023 for ; Wed, 25 Jul 2001 11:51:44 -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 LAA13785 for ; Wed, 25 Jul 2001 11:51:52 -0700 (PDT) Received: from RRMAIL01.RADIOROUTER_NT ([63.103.94.23]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA09496 for ; Wed, 25 Jul 2001 12:53:15 -0600 (MDT) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Jul 2001 14:51:50 -0400 Message-ID: <8C92E23A3E87FB479988285F9E22BE460546C1@ftmail> From: George Tsirtsis To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Handover Smoothing - What to Do? Date: Wed, 25 Jul 2001 14:51:49 -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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: I think I have already replied to these questions...we do not seam to be connecting here...never mind we have both made our points...the group can decide. We can have a beer over it in London....or maybe many I do not think just one will be of any help :-) George -----Original Message----- From: Karim El-Malki (ERA) [mailto:Karim.El-Malki@era.ericsson.se] Sent: Wednesday, July 25, 2001 7:33 PM To: 'mobile-ip@sunroof.eng.sun.com' Subject: RE: [mobile-ip] Handover Smoothing - What to Do? George, > GT> My very first e-mail on this thread included a > *technical* concern about > this...which boils down (again!) to the undisputed fact that > bicasting may > affect TCP in the ways I stated before and in the > circumstance that were > discussed in this thread. It's not undisputed actually. In one of my previous emails I pointed out that the circumstances considered in low latency do not involve multiple packet delivery. The MN does not receive from multiple FAs and we use a smoothing mechanism in a way such that it does not get multiple copies of packets. So I'd say that bicasting should not be linked to TCP effects, unless your system is implemented in a way that the MN does receive multiple copies of packets. I think I gave an example where, if you bicast and buffer at nFA for a period equal to the L2 handover time, then you won't get duplicates. > The argument has not been disputed; Instead > Hesham/Karim has pointed to the EIFEL work which I bet is good and it > actually confirms that there IS a problem with bicasting > (otherwise why is > there a draft about fixing the problem??). No! EIFEL was not done to eliminate bicasting. This has nothing to do with bicasting. In general there is no guarantee that an IP network will give you in-order packet delivery or a single copy of packets delivered to you. That's independent of bicasting. So if you want to run low latency with bicasting and have a MN which can be simultaneously communicate with multiple FAs, then EIFEL helps solve the TCP problem. >My objection to > this is that even > if Eifel becomes a standard RFC today it would not help! the > question is how > long it would take to go into all the Internet connected > Hosts...albeit long > time? Any word from Microsoft implementing it yet? So, IMO a spec that > suggest a mechanism that at the moment has unknown potential > effects to the > Internet at large I think is not responsible behavior by the > IETF, even if > it is only a MAY. Putting bicasting in a different draft > would allow it to > become Information or Experimental RFC until EIFEL becomes > available and we > get some implementation experience. Well, you seem to be convinced that bicasting means that the MN receives multiple copies of packets. I tried my best in explaining why that won't happen... Haven't seen a good explanation as to why multiple packet delivery to the MN MUST happen with bicasting, that's the fundamental point. Rgds /Karim From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 25 14:56:06 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA23175 for ; Wed, 25 Jul 2001 14:56:05 -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 MAA06603; Wed, 25 Jul 2001 12:56:55 -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 LAA14873; Wed, 25 Jul 2001 11:56:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PItXd26084 for mobile-ip-dist; Wed, 25 Jul 2001 11:55:33 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PItUY26076 for ; Wed, 25 Jul 2001 11:55:30 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA14618 for ; Wed, 25 Jul 2001 11:55:42 -0700 (PDT) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA18977 for ; Wed, 25 Jul 2001 11:55:40 -0700 (PDT) Received: by megisto-sql1.megisto.com with Internet Mail Service (5.5.2650.21) id ; Wed, 25 Jul 2001 14:54:09 -0400 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Handover Smoothing - What to Do? Date: Wed, 25 Jul 2001 14:54:08 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) 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: > It's not undisputed actually. In one of my previous emails I > pointed out that the circumstances considered in low latency do > not involve multiple packet delivery. The MN does not receive > from multiple FAs and we use a smoothing mechanism in a way such > that it does not get multiple copies of packets. So I'd say that > bicasting should not be linked to TCP effects, unless your system > is implemented in a way that the MN does receive multiple copies > of packets. I think I gave an example where, if you bicast and > buffer at nFA for a period equal to the L2 handover time, then > you won't get duplicates. Can you tell me which email this is - I'd like to read it? You'll need it in the draft at a minimum. > Well, you seem to be convinced that bicasting means > that the MN receives multiple copies of packets. I tried my > best in explaining why that won't happen... > Haven't seen a good explanation as to why multiple packet delivery > to the MN MUST happen with bicasting, that's the fundamental point. Not must necessarily, but is sometimes possible. > > Rgds > /Karim > From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 25 14:57:15 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA23321 for ; Wed, 25 Jul 2001 14:57: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 MAA07861; Wed, 25 Jul 2001 12:58:07 -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 LAA15152; Wed, 25 Jul 2001 11:57:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PIuh926106 for mobile-ip-dist; Wed, 25 Jul 2001 11:56:43 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PIudY26099 for ; Wed, 25 Jul 2001 11:56:40 -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 LAA14326 for ; Wed, 25 Jul 2001 11:56:52 -0700 (PDT) Received: from RRMAIL01.RADIOROUTER_NT ([63.103.94.23]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA06525 for ; Wed, 25 Jul 2001 12:56:50 -0600 (MDT) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Jul 2001 14:56:50 -0400 Message-ID: <8C92E23A3E87FB479988285F9E22BE460546C2@ftmail> From: George Tsirtsis To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Analysis of Jitter in Bicasting Date: Wed, 25 Jul 2001 14:56:42 -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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: -----Original Message----- From: James Kempf [mailto:James.Kempf@Sun.COM] Sent: Wednesday, July 25, 2001 7:37 PM To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Analysis of Jitter in Bicasting > Indeed, I suspect that the end-to-end principal is our friend > here. Real time traffic already uses jitter buffers, and good > ones are adaptive to transient conditions. For this kind of > traffic, you most definitely would *not* want L2-L3 smoothing > jitter out for you or you might end up with unnecessary additive > latency. I'm not sure that jitter concealment would be all that > useful in other places though. TCP's should be fairly resilient > to small amounts of jitter, which I would expect would be the > case with localized handoff schemes such as FMIP (ie, adding > 80ms to an average RTT of 80ms because of FMIP handoff, should > get lost in the noise.) > The other alternative is to actually not bicast at all, but to simply have old AR start tunnelling when it sees that L2 has stopped sending packets through old AR. If it can get this information. Much more bandwidth efficient anyway... GT> yes! yes! and assuming the network is well dimentioned as you suggested earlier this should work fine. From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 25 15:01:46 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24037 for ; Wed, 25 Jul 2001 15:01:46 -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 NAA11588; Wed, 25 Jul 2001 13:02: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 MAA16130; Wed, 25 Jul 2001 12:02:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PJ1MI26222 for mobile-ip-dist; Wed, 25 Jul 2001 12:01:22 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PJ1JY26215 for ; Wed, 25 Jul 2001 12:01:19 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA15358 for ; Wed, 25 Jul 2001 12:01:31 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA22662 for ; Wed, 25 Jul 2001 12:01:30 -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 MAA11591 for ; Wed, 25 Jul 2001 12:01:30 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6PJ1TL27734 for ; Wed, 25 Jul 2001 12:01:29 -0700 X-mProtect: Wed, 25 Jul 2001 12:01:29 -0700 Nokia Silicon Valley Messaging Protection Received: from vijayd.iprg.nokia.com (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpd1ms1n7; Wed, 25 Jul 2001 12:01:26 PDT Message-ID: <3B5F1787.A37DF1D5@iprg.nokia.com> Date: Wed, 25 Jul 2001 12:01: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: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Analysis of Jitter in Bicasting References: <200107251836.LAA08397@heliopolis.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 James Kempf wrote: > > > Indeed, I suspect that the end-to-end principal is our friend > > here. Real time traffic already uses jitter buffers, and good > > ones are adaptive to transient conditions. For this kind of > > traffic, you most definitely would *not* want L2-L3 smoothing > > jitter out for you or you might end up with unnecessary additive > > latency. I'm not sure that jitter concealment would be all that > > useful in other places though. TCP's should be fairly resilient > > to small amounts of jitter, which I would expect would be the > > case with localized handoff schemes such as FMIP (ie, adding > > 80ms to an average RTT of 80ms because of FMIP handoff, should > > get lost in the noise.) > > > > The other alternative is to actually not bicast at all, but to > simply have old AR start tunnelling when it sees that L2 has > stopped sending packets through old AR. If it can get this > information. Much more bandwidth efficient anyway... with buffering on the new router to store the tunneled packets till the mobile node actually shows up. vijay > > jak From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 25 15:22:05 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA26261 for ; Wed, 25 Jul 2001 15:22:05 -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 NAA26463; Wed, 25 Jul 2001 13:22:57 -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 MAA20686; Wed, 25 Jul 2001 12:22:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PJKu826413 for mobile-ip-dist; Wed, 25 Jul 2001 12:20:56 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PJKrY26402 for ; Wed, 25 Jul 2001 12:20:53 -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 MAA20292 for ; Wed, 25 Jul 2001 12:21:05 -0700 (PDT) Received: from mailsys01.intnet.net (mailhost.wwc.com [198.252.32.15]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA26351 for ; Wed, 25 Jul 2001 13:22:31 -0600 (MDT) Received: from [206.112.104.239] ([206.112.104.239] verified) by mailsys01.intnet.net (CommuniGate Pro SMTP 3.4.8) with ESMTP id 12021986 for mobile-ip@sunroof.eng.sun.com; Wed, 25 Jul 2001 15:20:28 -0400 Mime-Version: 1.0 X-Sender: ahmrphd@pop3.attglobal.net Message-Id: In-Reply-To: <15199.1997.584415.689007@thomasm-u1.cisco.com> References: <0DF9FBC42474A24CA50F7A27FB08E0484455EA@meshpdc.meshnetworks.com> <15199.1997.584415.689007@thomasm-u1.cisco.com> Date: Wed, 25 Jul 2001 12:21:18 -0700 To: mobile-ip@sunroof.eng.sun.com From: Arthur Ross Subject: RE: [mobile-ip] Analysis of Jitter in Bicasting 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 10:54 -0700 07/25/2001, Michael Thomas wrote: > Indeed, I suspect that the end-to-end principal is our friend > here. Real time traffic already uses jitter buffers, and good > ones are adaptive to transient conditions. For this kind of > traffic, you most definitely would *not* want L2-L3 smoothing > jitter out for you or you might end up with unnecessary additive > latency. I'm not sure that jitter concealment would be all that > useful in other places though. TCP's should be fairly resilient > to small amounts of jitter, which I would expect would be the > case with localized handoff schemes such as FMIP (ie, adding > 80ms to an average RTT of 80ms because of FMIP handoff, should > get lost in the noise.) > I can also envision time-tagged traffic, which would open the possibility of what I would call "Transmit erasures", these being defined as failures of packets/frames to arrive in time. In such a case the starved transmitter(s) would send some kind of "No data in this frame" indication (or perhaps just send a deliberately mal-formed packet that receivers could be guaranteed to reject, or simply turn off the transmitter for that time slot). FYI - the robust air interfaces utilize the concept of receive erasures, this meaning received frames that have insufficient quality to be considered correct. The definition of "quality" typically includes a CRC, as well as other metrics, such as re-encoded symbol error rate. In speech service the vocoders are constructed so as to gracefully smooth over erasures. Erasure rates in the ballpark of 1% typically are not objectionable for speech; higher rates are increasingly deleterious. In the context of "smoothed handoff" and more traditional IP traffic, the transmit erasure would serve simply as a "don't use this one" indication. Only if all participants were erased would the entire frame be deemed unusable. -- ahmr From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 25 15:38:52 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA28065 for ; Wed, 25 Jul 2001 15:38: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 NAA08965; Wed, 25 Jul 2001 13:39:33 -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 MAA24821; Wed, 25 Jul 2001 12:39:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PJW9m26519 for mobile-ip-dist; Wed, 25 Jul 2001 12:32:09 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PJW6Y26512 for ; Wed, 25 Jul 2001 12:32:06 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA02524 for ; Wed, 25 Jul 2001 12:32:18 -0700 (PDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id MAA09692 for ; Wed, 25 Jul 2001 12:32:15 -0700 (PDT) Received: (qmail 5826 invoked by uid 500); 25 Jul 2001 19:21:14 -0000 Date: Wed, 25 Jul 2001 12:21:14 -0700 From: Pat Calhoun To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Handover Smoothing - What to Do? Message-ID: <20010725122114.P10225@charizard.diameter.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from PRoberts@MEGISTO.com on Wed, Jul 25, 2001 at 02:03:44PM -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: I unfortunately agree with most folks that disagree with each other. On one hand, the low latency draft without smoothing techniques is incomplete, but on the other hand, additional (and perhaps even better) techniques may be developed over time. So, one alternative is to add text to the fast drafts that without such a technique, the draft is incomplete. Then the WG could develop a series of smoothing techniques (perhaps each in separate drafts, but well identified). So, the fast draft does point to external work, and it does claim that by itself it really is incomplete, but on the other hand, it isn't tied to a specific mechanism, and allows for future extensibility. My 2 cents, PatC On Wed, Jul 25, 2001 at 02:03:44PM -0400, Phil Roberts wrote: > > Well, I understand where you are coming from, as I would like > > a complete > > handover solution to be done soon too. But realistically, it takes as > > long as it takes. If we can peel off the FMIP work and get IESG to > > take a look at that, we can reduce the amount of time later when > > we do reach concensus on smoothing. > > > > I'd like to hear from the WG chairs and ADs on this, I guess, since > > it seems to me basically a procedural issue. Raj has already come > > out for keeping smoothing separate for now, what do the rest of > > you think? > > > > jak > > > > I wouldn't call it a procedural issue but a need to make a decision. I > (personally) > would like to make a consensus call on both FMIPv4 and FMIPv6 right after > London and I don't want to send up drafts one with and one without an option > for smoothing. So our consensus calls will probably be something like 1) do > we want smoothing in a separate draft and if so, 2) is FMIPv6 ready for last > call and is FMIPv4 ready for last call after we remove the smoothing bits; > and > if not 3) is FMIPv4 read for last call and FMIPv6 ready for last call after > we add the smoothing bits. > > Right now it seems that George at least is uncomfortable with making > smoothing an essential part > of the FMIP draft. Hesham at least is uncomfortable with progressing the > FMIP draft without smoothing. Hesham's position excludes the middle ground > of putting smoothing into a separate draft. As an aside it seems clear that > smoothing is an optional feature in the FMIPv4 draft but I'm not sure > whether > the proposal is to make it optional when incorporated in FMIPv6. > > There does seem to be some consensus that if a smoothing technique is chosen > it should be through bicasting or simultaneous binding rather than some kind > of > buffering. At the minimum we should have a discussion of why the tradeoff > of > accepting the possibility of duplicate packets weighs more heavily than > accepting > the possibility of lost packets and the results should be documented. > > George has also asserted (and speaking for myself personally I also agree > with) > that implementations in some environments at least can solve this without > any kind > of protocol support at layer 3. > > Does this seem to summarize everyone's position accurately? Does this > answer your question > enough, Jim? > > Of course, others contributing to the conversation COULD help, > Phil > From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 25 15:39:59 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA28229 for ; Wed, 25 Jul 2001 15:39:58 -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 NAA09911; Wed, 25 Jul 2001 13:40:52 -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 MAA25239; Wed, 25 Jul 2001 12:40:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PJb3W26569 for mobile-ip-dist; Wed, 25 Jul 2001 12:37:03 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PJaxY26562 for ; Wed, 25 Jul 2001 12:37:00 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA22944 for ; Wed, 25 Jul 2001 12:36:33 -0700 (PDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA20521 for ; Wed, 25 Jul 2001 12:36:33 -0700 (PDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f6PJaVN14488 for ; Wed, 25 Jul 2001 21:36:31 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Wed Jul 25 21:36:31 2001 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Jul 2001 21:30:22 +0200 Message-ID: <795A014AF92DD21182AF0008C7A404320C520497@esealnt117> From: "Karim El-Malki (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Handover Smoothing - What to Do? Date: Wed, 25 Jul 2001 21:36:26 +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: > > It's not undisputed actually. In one of my previous emails I > > pointed out that the circumstances considered in low latency do > > not involve multiple packet delivery. The MN does not receive > > from multiple FAs and we use a smoothing mechanism in a way such > > that it does not get multiple copies of packets. So I'd say that > > bicasting should not be linked to TCP effects, unless your system > > is implemented in a way that the MN does receive multiple copies > > of packets. I think I gave an example where, if you bicast and > > buffer at nFA for a period equal to the L2 handover time, then > > you won't get duplicates. > > Can you tell me which email this is - I'd like to read it? You'll > need it in the draft at a minimum. My mail to George on the 24th July about bicasting and buffering at nFA. I think it's similar to the jitter buffer issue that Phil pointed out in reply to a mail from James. The bicasting draft (as the low latency draft) allows the nFA to drop or buffer packets for a MN which is not yet connected. So the buffering or dropping at nFA is specified, but I can add more of the reasoning. > > > Well, you seem to be convinced that bicasting means > > that the MN receives multiple copies of packets. I tried my > > best in explaining why that won't happen... > > Haven't seen a good explanation as to why multiple packet delivery > > to the MN MUST happen with bicasting, that's the fundamental point. > > Not must necessarily, but is sometimes possible. Agreed. So we aim to avoid duplication of packets. If we can achieve this as above then nothing more is needed. If that is not possible in other cases (e.g. multi-interfaced MNs are using FMIP+bicasting) then TCP solutions such as EIFEL should be applied. Both are addressed in the bicasting draft. From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 25 15:41:30 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA28518 for ; Wed, 25 Jul 2001 15:41:24 -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 MAA15328; Wed, 25 Jul 2001 12:42:03 -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 MAA25275; Wed, 25 Jul 2001 12:40:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PJaqg26560 for mobile-ip-dist; Wed, 25 Jul 2001 12:36:52 -0700 (PDT) Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PJaZY26553 for ; Wed, 25 Jul 2001 12:36:37 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA11360; Wed, 25 Jul 2001 15:36:42 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f6PJa6S27445; Wed, 25 Jul 2001 15:36:06 -0400 (EDT) Message-Id: <200107251936.f6PJa6S27445@thunk.east.sun.com> From: Bill Sommerfeld To: mobile-ip@sunroof.eng.sun.com cc: Alexis , Phil Roberts , "Basavaraj Patil (NTC/Dallas)" , Abha Ahuja , Thomas Narten , Dave Johnson , Jeff Schiller , Marcus Leech , Pekka Nikander Subject: Re: [Fwd: [mobile-ip] Mobile IPv6 clarifications] In-reply-to: Your message of "Wed, 25 Jul 2001 09:12:35 PDT." <15198.61427.638753.967320@thomasm-u1.cisco.com> Date: Wed, 25 Jul 2001 15:36:06 -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: > I think you two are actually in violent agreement, as I read Vijay's > comment as meaning that killing piggybacking in the spec if that > were necessary wouldn't be any huge loss. I didn't read his comment that way. Oh, by the way... Once you've thrown out piggybacking, why not also throw out the whole binding-update, home-address, etc., etc, option scheme and just go to a much simpler ipvN-in-ipvN tunneling scheme in conjunction with a tunnel setup/update protocol? Yes, the packets get slightly bigger, but header compression can deal with that over low bit-rate links. > However, your comment about mixed traffic bothers me quite a bit. Good, it was supposed to ;-) > A very ordinary mix of traffic for mobile nodes will probably be > SRTP (secure RTP) media probably over ROHC header compression, but > using IPsec for most other signaling. This is an extremely appealing > combination since the high bandwidth media is heavily optimized, but > the relatively low bandwidth signaling is fully protected. As always, you need someone to do a security analysis of the proposed combination before you can say with any confidence that a particular combination looks secure. You have to look for weaknesses not only in the protocols themselves, but also in exactly how they're stapled together. As a good example of a flaw of this form, early versions of the GSSAPI authentication scheme for IKE (draft-ietf-ipsec-isakmp-gss-auth-07.txt) allowed the GSSAPI tokens to be cut & pasted between IKE sessions, allowing for a man-in-the-middle attack. Note that I'm not volunteering to do the analysis for this protocol.. - Bill From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 25 15:46:45 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA29092 for ; Wed, 25 Jul 2001 15:46:40 -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 NAA14861; Wed, 25 Jul 2001 13:47:34 -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 MAA26807; Wed, 25 Jul 2001 12:47:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PJiik26802 for mobile-ip-dist; Wed, 25 Jul 2001 12:44:44 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PJieY26795 for ; Wed, 25 Jul 2001 12:44:41 -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 MAA05812 for ; Wed, 25 Jul 2001 12:44:53 -0700 (PDT) Received: from zcars0m9.ca.nortel.com ([47.129.242.157]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA12882 for ; Wed, 25 Jul 2001 13:44:51 -0600 (MDT) Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f6PJiU920033 for ; Wed, 25 Jul 2001 15:44:30 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.ca.nortel.com; Wed, 25 Jul 2001 15:44:43 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Jul 2001 15:44:45 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5E7F@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Analysis of Jitter in Bicasting Date: Wed, 25 Jul 2001 15:44:40 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C11542.3E4CA600" X-Orig: 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_01C11542.3E4CA600 Content-Type: text/plain; charset="iso-8859-1" As I mentioned in my previous email, tunnelling does not resolve the lost packet problem identified by James in his first email. I am not sure if it resolves the duplication problem either: one way to look at the tunnelling solution is that it is a (temporary) creating of a bifurcation point at the AR. This removes the delay bounds issue I attempted to describe previously (there are 0 hops between the AR and the bicast source), but does it remove the duplication issue? BTW: as we all know, jitter buffers turn variance into fixed delay (this is how they are used in streaming audio and video for example). The amount of jitter compensated for through buffering comes directly out of your end-to-end delay budget. This needs to be considered for two-way conversational traffic. Gary > -----Original Message----- > From: Arthur Ross [mailto:a.ross@ieee.org] > Sent: July 25, 2001 15:21 > To: mobile-ip@sunroof.eng.sun.com > Subject: RE: [mobile-ip] Analysis of Jitter in Bicasting > > > At 10:54 -0700 07/25/2001, Michael Thomas wrote: > > Indeed, I suspect that the end-to-end principal is our friend > > here. Real time traffic already uses jitter buffers, and good > > ones are adaptive to transient conditions. For this kind of > > traffic, you most definitely would *not* want L2-L3 smoothing > > jitter out for you or you might end up with unnecessary additive > > latency. I'm not sure that jitter concealment would be all that > > useful in other places though. TCP's should be fairly resilient > > to small amounts of jitter, which I would expect would be the > > case with localized handoff schemes such as FMIP (ie, adding > > 80ms to an average RTT of 80ms because of FMIP handoff, should > > get lost in the noise.) > > > I can also envision time-tagged traffic, which would open the > possibility of what I would call "Transmit erasures", these being > defined as failures of packets/frames to arrive in time. In such a > case the starved transmitter(s) would send some kind of "No data in > this frame" indication (or perhaps just send a deliberately > mal-formed packet that receivers could be guaranteed to reject, or > simply turn off the transmitter for that time slot). > > FYI - the robust air interfaces utilize the concept of receive > erasures, this meaning received frames that have insufficient quality > to be considered correct. The definition of "quality" typically > includes a CRC, as well as other metrics, such as re-encoded symbol > error rate. In speech service the vocoders are constructed so as to > gracefully smooth over erasures. Erasure rates in the ballpark of 1% > typically are not objectionable for speech; higher rates are > increasingly deleterious. > > In the context of "smoothed handoff" and more traditional IP traffic, > the transmit erasure would serve simply as a "don't use this one" > indication. Only if all participants were erased would the entire > frame be deemed unusable. > > -- ahmr > ------_=_NextPart_001_01C11542.3E4CA600 Content-Type: text/html; charset="iso-8859-1" RE: [mobile-ip] Analysis of Jitter in Bicasting

As I mentioned in my previous email, tunnelling does not resolve
the lost packet problem identified by James in his first email.

I am not sure if it resolves the duplication problem either: one
way to look at the tunnelling solution is that it is a (temporary)
creating of a bifurcation point at the AR. This removes the delay
bounds issue I attempted to describe previously (there are 0 hops
between the AR and the bicast source), but does it remove the
duplication issue?

BTW: as we all know, jitter buffers turn variance into fixed delay
(this is how they are used in streaming audio and video for example).
The amount of jitter compensated for through buffering comes directly
out of your end-to-end delay budget. This needs to be considered for
two-way conversational traffic.

Gary

> -----Original Message-----
> From: Arthur Ross [mailto:a.ross@ieee.org]
> Sent: July 25, 2001 15:21
> To: mobile-ip@sunroof.eng.sun.com
> Subject: RE: [mobile-ip] Analysis of Jitter in Bicasting
>
>
> At 10:54 -0700 07/25/2001, Michael Thomas wrote:
> >    Indeed, I suspect that the end-to-end principal is our friend
> >    here. Real time traffic already uses jitter buffers, and good
> >    ones are adaptive to transient conditions. For this kind of
> >    traffic, you most definitely would *not* want L2-L3 smoothing
> >    jitter out for you or you might end up with unnecessary additive
> >    latency. I'm not sure that jitter concealment would be all that
> >    useful in other places though. TCP's should be fairly resilient
> >    to small amounts of jitter, which I would expect would be the
> >    case with localized handoff schemes such as FMIP (ie, adding
> >    80ms to an average RTT of 80ms because of FMIP handoff, should
> >    get lost in the noise.)
> >
> I can also envision time-tagged traffic, which would open the
> possibility of what I would call "Transmit erasures", these being
> defined as failures of packets/frames to arrive in time. In such a
> case the starved transmitter(s) would send some kind of "No data in
> this frame" indication (or perhaps just send a deliberately
> mal-formed packet that receivers could be guaranteed to reject, or
> simply turn off the transmitter for that time slot).
>
> FYI - the robust air interfaces utilize the concept of receive
> erasures, this meaning received frames that have insufficient quality
> to be considered correct. The definition of "quality" typically
> includes a CRC, as well as other metrics, such as re-encoded symbol
> error rate. In speech service the vocoders are constructed so as to
> gracefully smooth over erasures. Erasure rates in the ballpark of 1%
> typically are not objectionable for speech; higher rates are
> increasingly deleterious.
>
> In the context of "smoothed handoff" and more traditional IP traffic,
> the transmit erasure would serve simply as a "don't use this one"
> indication. Only if all participants were erased would the entire
> frame be deemed unusable.
>
>     -- ahmr
>

------_=_NextPart_001_01C11542.3E4CA600-- From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 25 16:09:10 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA01947 for ; Wed, 25 Jul 2001 16:09:10 -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 KAA10212; Wed, 25 Jul 2001 10:07: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 IAA10750; Wed, 25 Jul 2001 08:56:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PFt5r22282 for mobile-ip-dist; Wed, 25 Jul 2001 08:55:05 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PFt1Y22275 for ; Wed, 25 Jul 2001 08:55:01 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA15190 for ; Wed, 25 Jul 2001 08:55:14 -0700 (PDT) Received: from netmail.alcatel.com (netmail.alcatel.com [128.251.168.50]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA25204 for ; Wed, 25 Jul 2001 08:55:13 -0700 (PDT) Received: from auds952.usa.alcatel.com (auds952.usa.alcatel.com [143.209.238.7]) by netmail.alcatel.com (8.9.1/8.9.1) with ESMTP id KAA25782 for ; Wed, 25 Jul 2001 10:55:13 -0500 (CDT) Received: from usa.alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f6PFtCk04678 for ; Wed, 25 Jul 2001 10:55:12 -0500 (CDT) Message-ID: <3B5EEC38.38332E4@usa.alcatel.com> Date: Wed, 25 Jul 2001 10:56:40 -0500 From: Behcet Sarikaya Organization: Alcatel USA X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Handover Smoothing - What to Do? References: <200107251541.IAA28726@heliopolis.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 Fast handovers are good, smooth and fast handovers are even better. I favor coming up preferrably a single draft which achieves this integrated into the LMM, and it seems that the leading draft for LMM is HMIP. This put into the fast track standardization should resolve Raj's concerns. Any thoughts on this? Regards, James Kempf wrote: > Hi Hesham, > > >> I think we agree that specifications of smoothing and fast handoff do not > need > >> to be linked, if only for practical considerations. > >> > > => I would like to understand your point here. What difference does it > > make if we put the smoothing techniques in the same draft > > (as the low latency draft does) or leave them out (as in the v6 draft) ? > > If we believe smoothing is essential as you said below then why keep it > > out of a draft which was designed specifically to reduce L3 losses and > > delays due to the MIP handover ? > > > > Like I said, practical considerations. The difference may be a year > delay in whether the base FMIP gets through the IESG to proposed standard. > I think there is wide agreement (dare I say rough concensus? :-) on FMIP, > but there appears to be no concensus on smoothing. > > > If I'm implementing this function in a product, don't I have to do the > smoothing > > anyway ? > > > > Agree 100%. But we've got to have a better understanding of > the issues before we can standardize. > > > Therefore, I think for prctical reasons we should actually have them in > the > > same draft. Otherwise the only difference would be more drafts, more > paper > > work and unncessary cycles consumed. > > > > Well, I understand where you are coming from, as I would like a complete > handover solution to be done soon too. But realistically, it takes as > long as it takes. If we can peel off the FMIP work and get IESG to > take a look at that, we can reduce the amount of time later when > we do reach concensus on smoothing. > > I'd like to hear from the WG chairs and ADs on this, I guess, since > it seems to me basically a procedural issue. Raj has already come > out for keeping smoothing separate for now, what do the rest of > you think? > > jak -- Behcet From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 25 16:31:42 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA04308 for ; Wed, 25 Jul 2001 16:31: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 OAA18519; Wed, 25 Jul 2001 14:32:36 -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 NAA05220; Wed, 25 Jul 2001 13:32:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PKUQN27083 for mobile-ip-dist; Wed, 25 Jul 2001 13:30:26 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PKUGY27076 for ; Wed, 25 Jul 2001 13:30:16 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id NAA14838 for ; Wed, 25 Jul 2001 13:30:24 -0700 (PDT) Message-Id: <200107252030.NAA14838@heliopolis.eng.sun.com> Date: Wed, 25 Jul 2001 13:30:23 -0700 (PDT) From: James Kempf Subject: Re: [mobile-ip] Analysis of Jitter in Bicasting To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: XUJ/wNqZKIK9C+NmCWfKDA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 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: >> > Indeed, I suspect that the end-to-end principal is our friend >> > here. Real time traffic already uses jitter buffers, and good >> > ones are adaptive to transient conditions. For this kind of >> > traffic, you most definitely would *not* want L2-L3 smoothing >> > jitter out for you or you might end up with unnecessary additive >> > latency. I'm not sure that jitter concealment would be all that >> > useful in other places though. TCP's should be fairly resilient >> > to small amounts of jitter, which I would expect would be the >> > case with localized handoff schemes such as FMIP (ie, adding >> > 80ms to an average RTT of 80ms because of FMIP handoff, should >> > get lost in the noise.) >> > >> >> The other alternative is to actually not bicast at all, but to >> simply have old AR start tunnelling when it sees that L2 has >> stopped sending packets through old AR. If it can get this >> information. Much more bandwidth efficient anyway... > >with buffering on the new router to store the tunneled packets >till the mobile node actually shows up. > ...*provided* the combined L2/L3 handover latency is less than 112.5 sec, given a 6 kbps incoming real time data stream (typical for VoIP) and an uplink data rate of 9.6 kbps (typical of existing 2G voice systems). If the latency is more, the buffering propagates into the user visible region and the user will notice an artifact in the conversation, so it makes sense to simply drop any incoming packets during handover. See Appendix B of draft-kempf-beth-ipv6-01.txt for how to calculate this number. If we are not talking about a real time stream, then, of course, it might make sense to buffer regardless of the handover latency. jak From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 25 16:47:04 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA05902 for ; Wed, 25 Jul 2001 16:47:03 -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 OAA01114; Wed, 25 Jul 2001 14:47: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 NAA09423; Wed, 25 Jul 2001 13:47:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PKkIl27219 for mobile-ip-dist; Wed, 25 Jul 2001 13:46:18 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PKkEY27212 for ; Wed, 25 Jul 2001 13:46:14 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA09068 for ; Wed, 25 Jul 2001 13:46:27 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA19283 for ; Wed, 25 Jul 2001 13:46: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 NAA22421 for ; Wed, 25 Jul 2001 13:46:25 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6PKkP408635 for ; Wed, 25 Jul 2001 13:46:25 -0700 X-mProtect: Wed, 25 Jul 2001 13:46:25 -0700 Nokia Silicon Valley Messaging Protection Received: from vijayd.iprg.nokia.com (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdDUaWkk; Wed, 25 Jul 2001 13:46:23 PDT Message-ID: <3B5F301F.5490C121@iprg.nokia.com> Date: Wed, 25 Jul 2001 13:46: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: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Analysis of Jitter in Bicasting References: <200107252030.NAA14838@heliopolis.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 James Kempf wrote: > > >> > Indeed, I suspect that the end-to-end principal is our friend > >> > here. Real time traffic already uses jitter buffers, and good > >> > ones are adaptive to transient conditions. For this kind of > >> > traffic, you most definitely would *not* want L2-L3 smoothing > >> > jitter out for you or you might end up with unnecessary additive > >> > latency. I'm not sure that jitter concealment would be all that > >> > useful in other places though. TCP's should be fairly resilient > >> > to small amounts of jitter, which I would expect would be the > >> > case with localized handoff schemes such as FMIP (ie, adding > >> > 80ms to an average RTT of 80ms because of FMIP handoff, should > >> > get lost in the noise.) > >> > > >> > >> The other alternative is to actually not bicast at all, but to > >> simply have old AR start tunnelling when it sees that L2 has > >> stopped sending packets through old AR. If it can get this > >> information. Much more bandwidth efficient anyway... > > > >with buffering on the new router to store the tunneled packets > >till the mobile node actually shows up. > > > > ..*provided* the combined L2/L3 handover latency is less than 112.5 sec, given > a 6 kbps incoming real time data stream (typical for VoIP) and > an uplink data rate of 9.6 kbps (typical of existing 2G voice systems). i guess you meant 112.5 ms. i need to buffer atleast one packet, the FBACK. otherwise it gets dropped and could potentially screw up fast handoffs. > If the latency is more, the buffering propagates into the user visible > region and the user will notice an artifact in the conversation, so > it makes sense to simply drop any incoming packets during handover. > See Appendix B of draft-kempf-beth-ipv6-01.txt for how to calculate > this number. > > If we are not talking about a real time stream, then, of course, it > might make sense to buffer regardless of the handover latency. set the buffer to a smaller size. drop the packets which came earlier. vijay > > jak From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 25 16:53:33 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA06845 for ; Wed, 25 Jul 2001 16:53:32 -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 NAA17186; Wed, 25 Jul 2001 13:54: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 NAA11189; Wed, 25 Jul 2001 13:53:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PKqkP27335 for mobile-ip-dist; Wed, 25 Jul 2001 13:52:46 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PKqhY27328 for ; Wed, 25 Jul 2001 13:52:43 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id NAA15951 for ; Wed, 25 Jul 2001 13:52:56 -0700 (PDT) Message-Id: <200107252052.NAA15951@heliopolis.eng.sun.com> Date: Wed, 25 Jul 2001 13:52:55 -0700 (PDT) From: James Kempf Subject: Re: [mobile-ip] Analysis of Jitter in Bicasting To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: z9ZBuUAzyosMz8l3XqS+Gw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 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: >...*provided* the combined L2/L3 handover latency is less than 112.5 sec, given ^^^ Sorry, that's 112.5 *ms*. jak >a 6 kbps incoming real time data stream (typical for VoIP) and >an uplink data rate of 9.6 kbps (typical of existing 2G voice systems). > > >If the latency is more, the buffering propagates into the user visible >region and the user will notice an artifact in the conversation, so >it makes sense to simply drop any incoming packets during handover. >See Appendix B of draft-kempf-beth-ipv6-01.txt for how to calculate >this number. > >If we are not talking about a real time stream, then, of course, it >might make sense to buffer regardless of the handover latency. > > jak > > From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 25 17:17:05 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA09356 for ; Wed, 25 Jul 2001 17:16:59 -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 GAA18255; Wed, 25 Jul 2001 06:15:22 -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 FAA11273; Wed, 25 Jul 2001 05:15:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PCE8112309 for mobile-ip-dist; Wed, 25 Jul 2001 05:14:08 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PCE4Y12302 for ; Wed, 25 Jul 2001 05:14:04 -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 FAA11320 for ; Wed, 25 Jul 2001 05:14:16 -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 GAA17531 for ; Wed, 25 Jul 2001 06:14:14 -0600 (MDT) Received: from fredrikj (sierra.local.ipunplugged.com [192.168.4.88]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with SMTP id OAA28908; Wed, 25 Jul 2001 14:15:52 +0200 From: "Fredrik Johansson" To: , Subject: [mobile-ip] RE: Last Call: Generalized NAI (GNAIE) Extension to Proposed Standard Date: Wed, 25 Jul 2001 14:15: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.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <200107201604.MAA14030@ietf.org> 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 In sectin 3.0, subtypes are defined. 1. Is there a reason to why the MN_NAI has been removed as a subtype? 2. If there is no MN_NAI subtype, the sentence "When a mobile node or home agent adds a GNAI extension to a registration message, the extension MUST appear prior to any authentication extensions." doesn't make sence. Why should a mobile node add a GNAI with a subtype of the FA or HA? I suggest that the MN_NAI subtype be added again. "Sub-Type This field describes the type of the entity which owns the NAI. The following subtypes are defined: 1 HA_NAI 2 FA_NAI When a mobile node or home agent adds a GNAI extension to a registration message, the extension MUST appear prior to any authentication extensions." /Fredrik >-----Original Message----- >From: scoya@cnri.reston.va.us [mailto:scoya@cnri.reston.va.us]On Behalf >Of The IESG >Sent: den 20 juli 2001 18:05 >To: IETF-Announce: >Cc: mobile-ip@sunroof.eng.sun.com >Subject: Last Call: Generalized NAI (GNAIE) Extension to Proposed >Standard > > > >The IESG has received a request from the IP Routing for Wireless/Mobile >Hosts Working Group to consider Generalized NAI (GNAIE) Extension > as a Proposed Standard. > >The IESG plans to make a decision in the next few weeks, and solicits >final comments on this action. Please send any comments to the >iesg@ietf.org or ietf@ietf.org mailing lists by August 17, 2001. > >Files can be obtained via >http://www.ietf.org/internet-drafts/draft-ietf-mobileip-gnaie-04.txt > > From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 25 17:26:44 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA10497 for ; Wed, 25 Jul 2001 17:26:43 -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 OAA02015; Wed, 25 Jul 2001 14:27:39 -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 OAA19273; Wed, 25 Jul 2001 14:27:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PLPuU27562 for mobile-ip-dist; Wed, 25 Jul 2001 14:25:56 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PLPrY27555 for ; Wed, 25 Jul 2001 14:25:53 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id OAA17931 for ; Wed, 25 Jul 2001 14:26:07 -0700 (PDT) Message-Id: <200107252126.OAA17931@heliopolis.eng.sun.com> Date: Wed, 25 Jul 2001 14:26:06 -0700 (PDT) From: James Kempf Subject: RE: [mobile-ip] Analysis of Jitter in Bicasting To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: LKE0AjWf465t8/jNtvI6mA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 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: Gary, >This problem are not strictly a problem with bicasting. If the MN doesn't >receive x+2 on the old L2 because of poor radio channel conditions, the >same problem occurs with both re-routed and tunnelled approaches - namely, >how does the handover solution know that x+2 has been lost, and how does >it reinsert x+2? > >There are methods that can be used to address this problem with bicast, that >I suspect >are simpler then the other approaches (but someone may have a better >approach). >It involves purposely off-setting the stream at new AR from old L2. The >offset >should be equal to the number of possible packet losses (hopefully, no more >then 1 packet). This introduces duplicates as a result (possibly with every >handover), but a duplicate is easier to recover from then a loss, >particularly >when the duplicates are received within one or two packet durations. > This is sort of what I had in mind, but there are problems with inserting a jitter buffer, as PhilN and MikeT have pointed out. > >Well, it takes more then over provisioning. You need to ensure >the same number of hops between the bicasting source (the traffic >bifurcation >point if you will), and you also need to provide some guaranteed bounds on >the delay at each hop after the bicasting source. *if* you want to ensure no >duplicates >at all at the receiver. This may seem like a definition of EF, but >consider that the constraint is much more severe then that of EF. With >EF the bound is on inter-packet delay and delay jitter for a single stream. >With bicasting, the bound is on the arrival delay of two copies of the >same packet that traverse different paths through N hops. The maximum >delay difference, I believe, is one packet duration, T. Thus, the delay >difference bound at each hop must roughly be T/N (the relationship is >not linear, but this gives a rough approximation). If the source of >the delay is from queuing, then this would imply that there can be >no other traffic following the same path. E.g. if a bicasted packet >arrives at an AR and is queued behind a packet that is being served >(note: served, not queued), from a different packet stream, then >it receives a delay of roughly T/2. > >One obvious approach to this delay problem is to have only one hop >after the bicasting source - the AR itself. This would seem to >impose serious constraints on the network engineering, and I believe >would pose serious handover problems between bicasting sources. > Good points. Network engineering solutions along the lines you mention are probably unrealistic. People want to have more choices in the way they configure their access networks, not less. > >You have covered a lot. I think the bottom line is that if you >want to use bicasting, and avoid all duplicates at the receiver, you >have to synchronize the traffic flows very carefully, which contradicts >the principle of a hop-by-hop IP forwarding network. > >The other idea is to consider the impact of duplicates, and look for >reasonable comprimise between delay/loss compensation and duplicate >removal over one to two packet durations. > IP really isn't designed for isochronous types of situations, with these kinds of tight timing constraints (though it does suprisingly well if you are willing to allow L2 to take care of the synchronization for you). I think that the option of switching on an edge tunnel to new AR after the MN disappears probably would work better than bicasting, if you can fine tune things. If you can't, then you are left with having to either bicast or buffer or neither to smooth, none of which are particularly good. jak From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 25 17:33:05 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA11156 for ; Wed, 25 Jul 2001 17:33:04 -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 NAA09167; Wed, 25 Jul 2001 13:39:51 -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 MAA24896; Wed, 25 Jul 2001 12:39:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PJWrS26540 for mobile-ip-dist; Wed, 25 Jul 2001 12:32:53 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PJWnY26533 for ; Wed, 25 Jul 2001 12:32:49 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA23328 for ; Wed, 25 Jul 2001 12:33:02 -0700 (PDT) Received: from zcars0m9.ca.nortel.com ([47.129.242.157]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA09948 for ; Wed, 25 Jul 2001 12:32:42 -0700 (PDT) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f6PJWK918471 for ; Wed, 25 Jul 2001 15:32:20 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Wed, 25 Jul 2001 15:32:32 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Jul 2001 15:32:35 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5E7E@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Analysis of Jitter in Bicasting Date: Wed, 25 Jul 2001 15:32:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C11540.8B25E010" X-Orig: 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_01C11540.8B25E010 Content-Type: text/plain; charset="iso-8859-1" James: Good description. Some comments/questions inserted. Gary > -----Original Message----- > From: James Kempf [mailto:James.Kempf@Sun.COM] > Sent: July 25, 2001 13:32 > To: mobile-ip@sunroof.eng.sun.com > Subject: [mobile-ip] Analysis of Jitter in Bicasting > > > Hongyi's note about jitter and bicasting spurred a bit of pondering > about how to get a better idea of the problem, similiar to the > bounds on buffering in draft-kempf-beth-ipv6-01.txt. The following is > an analysis, not as mathematically based as the buffering bounds, but > still perhaps useful. It seems to me that jitter is one technical > problem that the proponents of bicasting need to address in order > to have a convincing solution. There are working solutions based upon bicast/mutlicast that have been used for decades. Most use base station (access point) synchronization and duplicate removal at the base station. There are tradeoffs involved. Indeed, if you look at CDMA as a frame based subnetwork, diversity is essentially the same as bicasting/mutlicasting (and you probably are aware of the complexities involved). CDMA subnets certainly do not look like an IP routed network (by "CDMA subnets" I am, of course, referring to the cellular version of CDMA). > > Consider the following sequence of packets from the CN: > > CN packet stream: x,x+1,x+2,x+3,x+4,x+5... > > where x is the sequence number when bicasting begins. > > There are two possible cases where jitter could cause duplication > or dropped packets: > > 1) A packet is delayed on the bicast link to the new AR due to network > congestion between the source of the bicast and the new AR: > > old L2 packet stream: x,x+1,x+2,x+3,x+4,x+5... > new AR packet stream: x,x+1,...,x+2,x+3,x+4,x+5... > > In this case, the MN gets a duplicate packet when it appears on the > new L2. For example, if the MN hands off at x+3, it gets a duplicate > x+4 packet. > > 2) A packet is delayed on the old L2 link due to deterioration in the > radio conditions approaching handoff: > > old L2 packet stream: x,x+1,...,x+2,x+3,x+4,x+5,... > new AR packet stream: x,x+1,x+2,x+3,x+4,x+5,... > > In this case, a packet is dropped. For example, if the MN hands off > at x+3, it will miss x+4. This problem are not strictly a problem with bicasting. If the MN doesn't receive x+2 on the old L2 because of poor radio channel conditions, the same problem occurs with both re-routed and tunnelled approaches - namely, how does the handover solution know that x+2 has been lost, and how does it reinsert x+2? There are methods that can be used to address this problem with bicast, that I suspect are simpler then the other approaches (but someone may have a better approach). It involves purposely off-setting the stream at new AR from old L2. The offset should be equal to the number of possible packet losses (hopefully, no more then 1 packet). This introduces duplicates as a result (possibly with every handover), but a duplicate is easier to recover from then a loss, particularly when the duplicates are received within one or two packet durations. > > In the case of 1, the probability of a duplicate packet has nothing > whatsoever to do with the radio link. It is purely a matter of traffic > engineering in the wired network. So the probability of a duplicate > packet can be reduced by properly engineering the wired network. In > addition, the probability is likely to increase with the topological > distance between the new AR and the source of the bicast (simply > because, the more network a packet has to traverse, the more likely > it is that a congestion event may cause delay). Since engineering > of the wired network is largely under the network operator's control, > this problem is fairly straightforward to solve, though it may > require measures such as over provisioning. Well, it takes more then over provisioning. You need to ensure the same number of hops between the bicasting source (the traffic bifurcation point if you will), and you also need to provide some guaranteed bounds on the delay at each hop after the bicasting source. *if* you want to ensure no duplicates at all at the receiver. This may seem like a definition of EF, but consider that the constraint is much more severe then that of EF. With EF the bound is on inter-packet delay and delay jitter for a single stream. With bicasting, the bound is on the arrival delay of two copies of the same packet that traverse different paths through N hops. The maximum delay difference, I believe, is one packet duration, T. Thus, the delay difference bound at each hop must roughly be T/N (the relationship is not linear, but this gives a rough approximation). If the source of the delay is from queuing, then this would imply that there can be no other traffic following the same path. E.g. if a bicasted packet arrives at an AR and is queued behind a packet that is being served (note: served, not queued), from a different packet stream, then it receives a delay of roughly T/2. One obvious approach to this delay problem is to have only one hop after the bicasting source - the AR itself. This would seem to impose serious constraints on the network engineering, and I believe would pose serious handover problems between bicasting sources. > > The same is not true of 2. Radio conditions at handover are > not entirely > controllable through network engineering. They change based on dynamic > factors such as what types of objects (like big trucks) sit > between the MN and > the radio AP, in addition to more static factors. So a more > likely source > of problems due to jitter is a dropped packet due to delay of a packet > on the radio link. > > Before drilling down on this problem, I'd like to consider > two different > kinds of bicasting that have been proposed, since I think they have > very different properties with regard to a solution. The differences > may not be clear in people's minds, though there have been illusions > to them in the email. They are: > > 1) Simultaneous bindings, in which an agent > (HA/RegReg/MAP, etc.) > back in the network is bicasting simultaneously to the old AR > and new AR (reference: > draft-elmalki-mobileip-bicasting-v6-00.txt). > > 2) Edge tunnels, in which the old AR is bicasting to the new AR > (references: draft-kempf-beth-ipv6-01.txt, > draft-ietf-mobileip-lowlatency-handoffs-ipv4-01.txt, > and implied > in draft-ietf-mobileip-fast-mipv6-01.txt if the old CoA is > used on the new AR). > > In 1), signalling from the MN establishes simultaneous bindings for > old and new CoA. In 2), the routers (or FAs for MIPv4) bicast without > the MN becoming involved. > > The delay of a packet on the radio link usually happens because radio > conditions deteriorate. Bit error rates around handover can escalate > to 10**-3 or 10**-2, something unheard of on wired networks. > At 10**-3, > one could expect a bit error on every Ethernet-sized (1500 byte) > packet. To counter this, most radio protocols have relatively small > L2 frame sizes, and perform retransmit on a frame basis. So a bit > error in a single radio frame doesn't require the entire packet to > drop. > > The net effect of increased bit error rate and retransmit is that > the MN begins to see a decrease in the IP data rate as radio > conditions > become worse during handover. If the rate near the center of the cell > is 9.6 kbps, maybe it drops to 5 kbps as handover approaches. Of > course, if the MN doesn't handover, it drops to 0 kbps and > the connection > is severed. > > If we assume that the wired network provides a data rate > considerably higher > (like 2-3 orders of magnitude) than the radio network, one way to > solve this problem is to clock the bicast data rate to the radio link > rate. So if the radio link slows down to 5 kbps, the bicast link going > out from the source does too. If this is done, the bicast source can > delay sending a packet out over the bicast stream until it is finished > sending on the radio link. This assures that the packet does not > get to the new AR (where it will be dropped if the MN hasn't > arrived yet) before it gets to the MN. Or, it can even *not* > send the packet > since the bicast source knows the MN has go it, and only send > packets when > the MN actually disappears due to L2 handover. > > In any event, with the simultaneous binding approach, the > HA/RegReg/MAP > agent is too far away from the radio link to be able to fine tune > bicasting in this way without additional help. One could > imagine further > protocol support for getting this information to the agent, but since > there would be a delay due to the transport time, it > probably wouldn't > help, as there could be hysteresis as the agent tried to catch up > to the varying quality of the radio link. > > With the edge tunnel approach, since the tunnel runs from the old > AR, the AR is in a position to obtain timely and accurate information > on the dynamically changing data rate over the radio link. Examples > here are the PDSN and GGSN for cdma2000 and wCDMA (resp.). For > WLAN protocols, the AR might not be directly connected to the radio > link, the radio link may rather be available via a radio AP > that acts as a transparent bridge. These cases are harder to > solve, since they > have the same problem as the simultaneous bindings approach, > namely the > information on radio link data rate is not available at the > AR. Again, protocol > support for transferring the L2 information from the AP to > the AR might > help, and the delay is likely to be less because the AP is on link > with the AR, but there is nevertheless the potential. > > So, in sum, the solution to jitter in bicasting is to tightly couple > bicasting with the performance of the radio link, so that the bicast > stream accurately reflects what the MN has received. This is not > as strong a coupling as the synchronization used in CDMA, but it > should work to reduce or eliminate packet drop for the most > common case. > In addition, the wired network must be properly provisioned to > avoid congestion and thus duplicate packets on the bicast link. > > Comments? Did I miss anything? You have covered a lot. I think the bottom line is that if you want to use bicasting, and avoid all duplicates at the receiver, you have to synchronize the traffic flows very carefully, which contradicts the principle of a hop-by-hop IP forwarding network. The other idea is to consider the impact of duplicates, and look for reasonable comprimise between delay/loss compensation and duplicate removal over one to two packet durations. Cheers, Gary > > ------_=_NextPart_001_01C11540.8B25E010 Content-Type: text/html; charset="iso-8859-1" RE: [mobile-ip] Analysis of Jitter in Bicasting

James:

   Good description. Some comments/questions inserted.

Gary

> -----Original Message-----
> From: James Kempf [mailto:James.Kempf@Sun.COM]
> Sent: July 25, 2001 13:32
> To: mobile-ip@sunroof.eng.sun.com
> Subject: [mobile-ip] Analysis of Jitter in Bicasting
>
>
> Hongyi's note about jitter and bicasting spurred a bit of pondering
> about how to get a better idea of the problem, similiar to the
> bounds on buffering in draft-kempf-beth-ipv6-01.txt. The following is
> an analysis, not as mathematically based as the buffering bounds, but
> still perhaps useful. It seems to me that jitter is one technical
> problem that the proponents of bicasting need to address in order
> to have a convincing solution.

There are working solutions based upon bicast/mutlicast that have been
used for decades. Most use base station (access point) synchronization
and duplicate removal at the base station. There are tradeoffs involved.

Indeed, if you look at CDMA as a frame based subnetwork, diversity is
essentially the same as bicasting/mutlicasting (and you probably are
aware of the complexities involved). CDMA subnets certainly do not look
like an IP routed network (by "CDMA subnets" I am, of course, referring
to the cellular version of CDMA).

>
> Consider the following sequence of packets from the CN:
>
>       CN packet stream: x,x+1,x+2,x+3,x+4,x+5...
>      
> where x is the sequence number when bicasting begins.
>
> There are two possible cases where jitter could cause duplication
> or dropped packets:
>
> 1) A packet is delayed on the bicast link to the new AR due to network
> congestion between the source of the bicast and the new AR:
>
>       old L2 packet stream: x,x+1,x+2,x+3,x+4,x+5...
>       new AR packet stream: x,x+1,...,x+2,x+3,x+4,x+5...
>      
> In this case, the MN gets a duplicate packet when it appears on the
> new L2. For example, if the MN hands off at x+3, it gets a duplicate
> x+4 packet.
>
> 2) A packet is delayed on the old L2 link due to deterioration in the
> radio conditions approaching handoff:
>
>       old L2 packet stream: x,x+1,...,x+2,x+3,x+4,x+5,...
>       new AR packet stream: x,x+1,x+2,x+3,x+4,x+5,...
>      
> In this case, a packet is dropped. For example, if the MN hands off
> at x+3, it will miss x+4.

This problem are not strictly a problem with bicasting. If the MN doesn't
receive x+2 on the old L2 because of poor radio channel conditions, the
same problem occurs with both re-routed and tunnelled approaches - namely,
how does the handover solution know that x+2 has been lost, and how does
it reinsert x+2?

There are methods that can be used to address this problem with bicast, that I suspect
are simpler then the other approaches (but someone may have a better approach).
It involves purposely off-setting the stream at new AR from old L2. The offset
should be equal to the number of possible packet losses (hopefully, no more
then 1 packet). This introduces duplicates as a result (possibly with every
handover), but a duplicate is easier to recover from then a loss, particularly
when the duplicates are received within one or two packet durations.

>
> In the case of 1, the probability of a duplicate packet has nothing
> whatsoever to do with the radio link. It is purely a matter of traffic
> engineering in the wired network. So the probability of a duplicate
> packet can be reduced by properly engineering the wired network. In
> addition, the probability is likely to increase with the topological
> distance between the new AR and the source of the bicast (simply
> because, the more network a packet has to traverse, the more likely
> it is that a congestion event may cause delay). Since engineering
> of the wired network is largely under the network operator's control,
> this problem is fairly straightforward to solve, though it may
> require measures such as over provisioning.

Well, it takes more then over provisioning. You need to ensure
the same number of hops between the bicasting source (the traffic bifurcation
point if you will), and you also need to provide some guaranteed bounds on
the delay at each hop after the bicasting source. *if* you want to ensure no duplicates
at all at the receiver. This may seem like a definition of EF, but
consider that the constraint is much more severe then that of EF. With
EF the bound is on inter-packet delay and delay jitter for a single stream.
With bicasting, the bound is on the arrival delay of two copies of the
same packet that traverse different paths through N hops. The maximum
delay difference, I believe, is one packet duration, T. Thus, the delay
difference bound at each hop must roughly be T/N (the relationship is
not linear, but this gives a rough approximation). If the source of
the delay is from queuing, then this would imply that there can be
no other traffic following the same path. E.g. if a bicasted packet
arrives at an AR and is queued behind a packet that is being served
(note: served, not queued), from a different packet stream, then
it receives a delay of roughly T/2.

One obvious approach to this delay problem is to have only one hop
after the bicasting source - the AR itself. This would seem to
impose serious constraints on the network engineering, and I believe
would pose serious handover problems between bicasting sources.


>
> The same is not true of 2. Radio conditions at handover are
> not entirely
> controllable through network engineering. They change based on dynamic
> factors such as what types of objects (like big trucks) sit
> between the MN and
> the radio AP, in addition to more static factors. So a more
> likely source
> of problems due to jitter is a dropped packet due to delay of a packet
> on the radio link.
>
> Before drilling down on this problem, I'd like to consider
> two different
> kinds of bicasting that have been proposed, since I think they have
> very different properties with regard to a solution. The differences
> may not be clear in people's minds, though there have been illusions
> to them in the email. They are:
>
>       1) Simultaneous bindings, in which an agent
> (HA/RegReg/MAP, etc.)
>       back in the network is bicasting simultaneously to the old AR
>       and new AR (reference:
> draft-elmalki-mobileip-bicasting-v6-00.txt).
>      
>       2) Edge tunnels, in which the old AR is bicasting to the new AR
>       (references: draft-kempf-beth-ipv6-01.txt,
>        draft-ietf-mobileip-lowlatency-handoffs-ipv4-01.txt, 
> and implied
>        in draft-ietf-mobileip-fast-mipv6-01.txt if the old CoA is
>        used on the new AR).
>       
> In 1), signalling from the MN establishes simultaneous bindings for
> old and new CoA. In 2), the routers (or FAs for MIPv4) bicast without
> the MN becoming involved.
>
> The delay of a packet on the radio link usually happens because radio
> conditions deteriorate. Bit error rates around handover can escalate
> to 10**-3 or 10**-2, something unheard of on wired networks.
> At 10**-3,
> one could expect a bit error on every Ethernet-sized (1500 byte)
> packet. To counter this, most radio protocols have relatively small
> L2 frame sizes, and perform retransmit on a frame basis. So a bit
> error in a single radio frame doesn't require the entire packet to
> drop.
>
> The net effect of increased bit error rate and retransmit is that
> the MN begins to see a decrease in the IP data rate as radio
> conditions
> become worse during handover. If the rate near the center of the cell
> is 9.6 kbps, maybe it drops to 5 kbps as handover approaches. Of
> course, if the MN doesn't handover, it drops to 0 kbps and
> the connection
> is severed.
>
> If we assume that the wired network provides a data rate
> considerably higher
> (like 2-3 orders of magnitude) than the radio network, one way to
> solve this problem is to clock the bicast data rate to the radio link
> rate. So if the radio link slows down to 5 kbps, the bicast link going
> out from the source does too. If this is done, the bicast source can
> delay sending a packet out over the bicast stream until it is finished
> sending on the radio link. This assures that the packet does not
> get to the new AR (where it will be dropped if the MN hasn't
> arrived yet) before it gets to the MN. Or, it can even *not*
> send the packet
> since the bicast source knows the MN has go it, and only send
> packets when
> the MN actually disappears due to L2 handover.
>
> In any event, with the simultaneous binding approach, the
> HA/RegReg/MAP
> agent is too far away from the radio link to be able to fine tune
> bicasting in this way without additional help. One could
> imagine further
> protocol support for getting this information to the agent, but since
> there would be a delay due to  the transport time, it
> probably wouldn't
> help, as there could be hysteresis as the agent tried to catch up
> to the varying quality of the radio link.
>
> With the edge tunnel approach, since the tunnel runs from the old
> AR, the AR is in a position to obtain timely and accurate information
> on the dynamically changing data rate over the radio link. Examples
> here are the PDSN and GGSN for cdma2000 and wCDMA (resp.). For
> WLAN protocols, the AR might not be directly connected to the radio
> link, the radio link may rather be available via a radio AP
> that acts as a transparent bridge. These cases are harder to
> solve, since they
> have the same problem as the simultaneous bindings approach,
> namely the
> information on radio link data rate is not available at the
> AR. Again, protocol
> support for transferring the L2 information from the AP to
> the AR might
> help, and the delay is likely to be less because the AP is on link
> with the AR, but there is nevertheless the potential.
>
> So, in sum, the solution to jitter in bicasting is to tightly couple
> bicasting with the performance of the radio link, so that the bicast
> stream accurately reflects what the MN has received. This is not
> as strong a coupling as the synchronization used in CDMA, but it
> should work to reduce or eliminate packet drop for the most
> common case.
> In addition, the wired network must be properly provisioned to
> avoid congestion and thus duplicate packets on the bicast link.
>
> Comments? Did I miss anything?

You have covered a lot. I  think the bottom line is that if you
want to use bicasting, and avoid all duplicates at the receiver, you
have to synchronize the traffic flows very carefully, which contradicts
the principle of a hop-by-hop IP forwarding network.

The other idea is to consider the impact of duplicates, and look for
reasonable comprimise between delay/loss compensation and duplicate
removal over one to two packet durations.

Cheers,
Gary

>
>

------_=_NextPart_001_01C11540.8B25E010-- From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 25 17:48:53 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA12531 for ; Wed, 25 Jul 2001 17:48:52 -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 OAA10821; Wed, 25 Jul 2001 14:49: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 OAA24199; Wed, 25 Jul 2001 14:49:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PLlgV27698 for mobile-ip-dist; Wed, 25 Jul 2001 14:47:42 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PLldY27691 for ; Wed, 25 Jul 2001 14:47:39 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA23904 for ; Wed, 25 Jul 2001 14:47:53 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA20576 for ; Wed, 25 Jul 2001 14:47:52 -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 OAA01190 for ; Wed, 25 Jul 2001 14:47:52 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6PLlqE11558 for ; Wed, 25 Jul 2001 14:47:52 -0700 X-mProtect: Wed, 25 Jul 2001 14:47:52 -0700 Nokia Silicon Valley Messaging Protection Received: from vijayd.iprg.nokia.com (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdtTXQu0; Wed, 25 Jul 2001 14:47:50 PDT Message-ID: <3B5F3E85.5AC0B7D1@iprg.nokia.com> Date: Wed, 25 Jul 2001 14:47:49 -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: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Analysis of Jitter in Bicasting References: <200107252110.OAA17136@heliopolis.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 James Kempf wrote: > >i need to buffer atleast one packet, the FBACK. otherwise it gets > >dropped > >and could potentially screw up fast handoffs. > > > > Um, so what happens to the real time packets while the FBACK is getting > buffered? And how do you know that the FBACK will arrive and should > be buffered exactly during L2 handover? It could arrive before, it > could arrive after. What about the rest (minimum 4 at my count) > packets involved in FMIP handover before the MN gets to start > doing DAD (over the air), etc., on the new AR before it can > start getting its real time traffic? i lost you. it doesnt matter when the FBack arrives at the newAR, the newAR has to buffer it till the MN shows up. the newAR doesnt know if the MN got the FBack while it was still attached to the oldAR. vijay > If you are going to buffer, you need to buffer during the expected > duration of the L2 + L3 handover, regardless of what the traffic is. > If you look in Appendix A of draft-kempf-beth-ipv6-01.txt, you'll see a > calcuated minimum duration for handover using FMIPv6 of 133 ms for > L3 handover *only* @ 9.6 kbps uplink speed. Add another > 100 ms (a wild guess, I have not yet been able to find anyone who > can give me figures for wCDMA) for L2 handover and you are already > almost double the 112.5 ms time for the user to notice. In addition, > the scenarios in Appendix A do not assume that the MN completes > valid new CoA aquisition on the new AR, they assume that the MN > uses its old CoA and the old AR is tunnelling, which is the > fallback scenario. If you include completion of new CoA aquisition, > you'll add yet more time. > > Meantime, the user is waiting... > > jak From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 25 18:16:56 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14764 for ; Wed, 25 Jul 2001 18:16:56 -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 PAA21813; Wed, 25 Jul 2001 15:17: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 PAA10506; Wed, 25 Jul 2001 15:17:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PMF9S27831 for mobile-ip-dist; Wed, 25 Jul 2001 15:15:10 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PMF6Y27824 for ; Wed, 25 Jul 2001 15:15:06 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id PAA20351 for ; Wed, 25 Jul 2001 15:15:20 -0700 (PDT) Message-Id: <200107252215.PAA20351@heliopolis.eng.sun.com> Date: Wed, 25 Jul 2001 15:15:20 -0700 (PDT) From: James Kempf Subject: Re: [mobile-ip] Analysis of Jitter in Bicasting To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: UU5EdZYyvW2rZX4Ruy7w0g== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 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, >> >> Um, so what happens to the real time packets while the FBACK is getting >> buffered? And how do you know that the FBACK will arrive and should >> be buffered exactly during L2 handover? It could arrive before, it >> could arrive after. What about the rest (minimum 4 at my count) >> packets involved in FMIP handover before the MN gets to start >> doing DAD (over the air), etc., on the new AR before it can >> start getting its real time traffic? > >i lost you. it doesnt matter when the FBack arrives at the newAR, >the newAR has to buffer it till the MN shows up. the newAR doesnt >know if the MN got the FBack while it was still attached to the >oldAR. > What I'm saying is that if there is more than a 300 ms gap in a real time voice stream, the user notices a click. If the gap propagates forward, so that there is more than a 300 ms delay in the real time traffic, then the conversation begins to sound like half duplex. The number I gave of 112.5 ms is the maximum amount time on a 9.6 kbps uplink that buffering can be done before the 300 ms bound is exceeded. For the scenarios calculated in Appendix A of draft-kempf-beth-ipv6-01.txt, which I think are about the minimum traffic for an FMIPv6 handover (somebody please correct me if I am wrong), the minimum L3 handover time is 133 ms. This already exceeds the buffering bound. The FBACK isn't strictly necessary for the MN to start getting real time traffic right away after handover (and, frankly, that is really all that counts if you want the user not to notice). The FBACK is only necessary to complete new CoA aquisition. The MN can get its real time traffic through a tunnel from the old AR using its old CoA then finish new CoA aquisition whenever. That is what draft-kempf-beth-ipv6-01.txt advocates, and it is envisioned in draft-ietf-mobileip-fast-mipv6-01.txt as a corner case. So if you want to buffer and you've got real time traffic, your choices are: 1) Use FMIPv6 handover and crank the uplink data rate up until you can download the buffer fast enough over the air from the new AR to not have the latency propogate. 2) Use BETH handover if the L2 handover time is less than 112.5 ms (for a 9.6 kbps downlink data rate). Otherwise, if L2 handover is too large for 2) or you can't crank the data rate, you are better off dropping the packets. jak From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 25 18:22:55 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA15387 for ; Wed, 25 Jul 2001 18:22:53 -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 PAA24345; Wed, 25 Jul 2001 15:23: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 PAA11942; Wed, 25 Jul 2001 15:23:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PMMT827900 for mobile-ip-dist; Wed, 25 Jul 2001 15:22:29 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PMMPY27893 for ; Wed, 25 Jul 2001 15:22:25 -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 PAA18130 for ; Wed, 25 Jul 2001 15:22:39 -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 QAA06593 for ; Wed, 25 Jul 2001 16:22: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 PAA04664 for ; Wed, 25 Jul 2001 15:22:37 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6PMMaA26709 for ; Wed, 25 Jul 2001 15:22:36 -0700 X-mProtect: Wed, 25 Jul 2001 15:22:36 -0700 Nokia Silicon Valley Messaging Protection Received: from tpagtzis.iprg.nokia.com (205.226.2.115, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdJPyf1I; Wed, 25 Jul 2001 15:22:33 PDT Message-ID: <3B5F46A9.F146BD0A@iprg.nokia.com> Date: Wed, 25 Jul 2001 15:22:33 -0700 From: Theo Pagtzis Organization: UCL/NOKIA X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.1-STABLE i386) X-Accept-Language: el, en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Analysis of Jitter in Bicasting References: <200107252215.PAA20351@heliopolis.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 A slight correction/question, Mobility support for IPv6: The minRTadvInterval is set to be 0.05 sec. So far I knew it was 0.5 sec. Is that a mistake or has it been decided to allow RT adverts every 50 msec? Cheers Theo UCL/Mobile Systems James Kempf wrote: > Vijay, > > >> > >> Um, so what happens to the real time packets while the FBACK is getting > >> buffered? And how do you know that the FBACK will arrive and should > >> be buffered exactly during L2 handover? It could arrive before, it > >> could arrive after. What about the rest (minimum 4 at my count) > >> packets involved in FMIP handover before the MN gets to start > >> doing DAD (over the air), etc., on the new AR before it can > >> start getting its real time traffic? > > > >i lost you. it doesnt matter when the FBack arrives at the newAR, > >the newAR has to buffer it till the MN shows up. the newAR doesnt > >know if the MN got the FBack while it was still attached to the > >oldAR. > > > > What I'm saying is that if there is more than a 300 ms gap in > a real time voice stream, the user notices a click. If the gap > propagates forward, so that there is more than a 300 ms delay > in the real time traffic, then the conversation begins to > sound like half duplex. > > The number I gave of 112.5 ms is the maximum amount time on a 9.6 kbps > uplink that buffering can be done before the 300 ms bound is exceeded. > For the scenarios calculated in Appendix A of draft-kempf-beth-ipv6-01.txt, > which I think are about the minimum traffic for an FMIPv6 handover > (somebody please correct me if I am wrong), the minimum L3 handover time is 133 > ms. This already exceeds the buffering bound. > > The FBACK isn't strictly necessary for the MN to start getting > real time traffic right away after handover (and, frankly, that > is really all that counts if you want the user not to notice). The > FBACK is only necessary to complete new CoA aquisition. The MN > can get its real time traffic through a tunnel from the old AR > using its old CoA then finish new CoA aquisition whenever. That is what > draft-kempf-beth-ipv6-01.txt advocates, and it is envisioned in > draft-ietf-mobileip-fast-mipv6-01.txt as a corner case. > > So if you want to buffer and you've got real time traffic, your choices are: > > 1) Use FMIPv6 handover and crank the uplink data rate up until you can download > the buffer fast enough over the air from the new AR to not have the latency > propogate. > > 2) Use BETH handover if the L2 handover time is less than 112.5 ms (for > a 9.6 kbps downlink data rate). > > Otherwise, if L2 handover is too large for 2) or you can't crank the > data rate, you are better off dropping the packets. > > jak From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 25 18:28:38 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA15911 for ; Wed, 25 Jul 2001 18:28:37 -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 PAA26406; Wed, 25 Jul 2001 15:29:29 -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 PAA13165; Wed, 25 Jul 2001 15:29:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PMRqt27965 for mobile-ip-dist; Wed, 25 Jul 2001 15:27:52 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PMRmY27958 for ; Wed, 25 Jul 2001 15:27:48 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id PAA20908 for ; Wed, 25 Jul 2001 15:28:01 -0700 (PDT) Message-Id: <200107252228.PAA20908@heliopolis.eng.sun.com> Date: Wed, 25 Jul 2001 15:28:00 -0700 (PDT) From: James Kempf Subject: Re: [mobile-ip] Analysis of Jitter in Bicasting To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: YugMIkIWVda/kw/y8dGZIw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 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: Hi Theo, > > Mobility support for IPv6: The minRTadvInterval is set to be 0.05 sec. So far I >knew it was 0.5 sec. Is that a mistake or has it been decided to allow RT adverts >every 50 msec? > I doubt it. Even 500 ms is alot unless you can send it over one of the common signalling channels. jak From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 25 18:45:43 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA17781 for ; Wed, 25 Jul 2001 18:45:42 -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 PAA03098; Wed, 25 Jul 2001 15:46:39 -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 PAA16667; Wed, 25 Jul 2001 15:46:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PMj3h28193 for mobile-ip-dist; Wed, 25 Jul 2001 15:45:03 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PMixY28184 for ; Wed, 25 Jul 2001 15:44:59 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA23070 for ; Wed, 25 Jul 2001 15:45:12 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA13963 for ; Wed, 25 Jul 2001 15:45:12 -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 PAA06596 for ; Wed, 25 Jul 2001 15:45:11 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6PMjB717036 for ; Wed, 25 Jul 2001 15:45:11 -0700 X-mProtect: Wed, 25 Jul 2001 15:45:11 -0700 Nokia Silicon Valley Messaging Protection Received: from tpagtzis.iprg.nokia.com (205.226.2.115, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdxrQHXU; Wed, 25 Jul 2001 15:45:09 PDT Message-ID: <3B5F4BF5.73569D33@iprg.nokia.com> Date: Wed, 25 Jul 2001 15:45:09 -0700 From: Theo Pagtzis Organization: UCL/NOKIA X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.1-STABLE i386) X-Accept-Language: el, en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Analysis of Jitter in Bicasting References: <200107252228.PAA20908@heliopolis.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 Hi Jak, That's what I thought..perhaps this could be corrected then in current ver. (14)? Theo James Kempf wrote: > Hi Theo, > > > > > Mobility support for IPv6: The minRTadvInterval is set to be 0.05 sec. So > far I > >knew it was 0.5 sec. Is that a mistake or has it been decided to allow RT > adverts > >every 50 msec? > > > > I doubt it. Even 500 ms is alot unless you can send it over one > of the common signalling channels. > > jak From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 25 19:00:58 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA19377 for ; Wed, 25 Jul 2001 19:00:57 -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 QAA08444; Wed, 25 Jul 2001 16:01: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 QAA26927; Wed, 25 Jul 2001 16:01:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PMxU028419 for mobile-ip-dist; Wed, 25 Jul 2001 15:59:30 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PMxRY28412 for ; Wed, 25 Jul 2001 15:59:27 -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 PAA10981 for ; Wed, 25 Jul 2001 15:59:39 -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 RAA13944 for ; Wed, 25 Jul 2001 17:01: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 PAA07850 for ; Wed, 25 Jul 2001 15:59:37 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6PMxbU17568 for ; Wed, 25 Jul 2001 15:59:37 -0700 X-mProtect: Wed, 25 Jul 2001 15:59:37 -0700 Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpd4VKNI1; Wed, 25 Jul 2001 15:59:35 PDT Message-ID: <3B5F4F57.1927AA19@iprg.nokia.com> Date: Wed, 25 Jul 2001 15:59: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: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Handover Smoothing - What to Do? References: <8C92E23A3E87FB479988285F9E22BE460546A1@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 Hello folks, I would like to add that there are issues surrounding header compression as well. Note that the context resides on the old-AR. What type of packet does it bicast ? compressed or uncompressed packet ? If it is uncompressed, it is not useful without the new-AR having the compression context. On the other hand, if the new-AR has to possess the context *simultaneously*, this adds a new dimension to header compression: Many-to-One header compression! If the old-AR sends compressed packets to the new-AR, how does the latter handle them ? Also, since the MN is not bicasting in the uplink, the uplink context is current only on the old-AR even if the new-AR has the context. So, there is a synchronization issue as well. Regards, -Rajeev George Tsirtsis wrote: > -----Original Message----- > From: Karim El-Malki (ERA) [mailto:Karim.El-Malki@era.ericsson.se] > Sent: Tuesday, July 24, 2001 10:53 AM > To: 'mobile-ip@sunroof.eng.sun.com'; James.Kempf@sun.com > Subject: RE: [mobile-ip] Handover Smoothing - What to Do? > > Hello Raj and James > > ... > > >I would recommend removing it and focusing on smoothing > > of handoffs in a separate I-D. Handoff smoothing can also be achieved > > by buffering. So why recommend only bicasting as the mechanism for the > > desired effect? I do not believe there has been any real consensus of > > going one way vs the other. > > > > There has been consensus among the design team members and up to now > we have not received negative comments on the low latency draft nor during > the IETF presentations. I would be happy to consider buffering as an > alternative and eventually add it into the draft if the authors/WG want > this, > but all the methods must satisfy the requirement of eliminating the period > of > service disruption due to L3 handoff independently of the L2 > characteristics. > Without this IMO the draft would not serve its purpose. > > GT> This was discussed in (I think) much greater length in the FMIPv6 design > team and enough doubts were raised to exclude bicasting from the FMIPv6 spec > and encourage its proponents to publish the idea as a separate document, > which they did...well done :). The main argument against bicasting was > regarding its possible effects on TCP. Bicasting would duplicate TCP ACKS > (along with everything else) and as we know 3 dupacks result in TCP > shrinking its window...dupacks occur naturally by TCP as a result of the > network loosing or reordering packets and the chance of 3 dupacks in a row > is not very high. We thought that bicasting may increase the chance of 3 > dupacks and thus impact TCP performance. > > > Note that there has been work towards eliminating this well known problem > and Karim can point the list to this work since I do not remember that draft > name. Nevertheless, the FMIPv6 team decided that bicasting has experimental > nature and the TCP fix was at the time a draft at v00...early days => not > enough practical experiance or understanding of what a possiby wide spread > use of bicasting do to TCP. For all the above we thought that bicasting > should be discussed as a separate item and the FMIPv6 spec should not be > dependant on it. The fact that the FMIPv4 team did not take the same > decision always concerned me a bit... > > IMO smoothing (bicasting and/or buffering) should be separate specs from the > FMIPv4/v6 not only because of the uncertainty regarding bicasting but also > because (again IMO) smooth handoffs may be achieved at the implementation > level and without protocol support. That is not to say that protocol work > may not help and should not be done...but only to indicate that "smooth > handoff" work should be separate from the FMIP work. In fact, smooth > handoffs could be viewed as optional extensions to the FMIP specs. > > Thanks > George From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 25 19:10:38 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA19993 for ; Wed, 25 Jul 2001 19:10:37 -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 QAA12016; Wed, 25 Jul 2001 16:11:27 -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 QAA29190; Wed, 25 Jul 2001 16:11:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PN9ds28492 for mobile-ip-dist; Wed, 25 Jul 2001 16:09:39 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PN9aY28485 for ; Wed, 25 Jul 2001 16:09:36 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id QAA23277 for ; Wed, 25 Jul 2001 16:09:49 -0700 (PDT) Message-Id: <200107252309.QAA23277@heliopolis.eng.sun.com> Date: Wed, 25 Jul 2001 16:09:48 -0700 (PDT) From: James Kempf Subject: Re: [mobile-ip] Handover Smoothing - What to Do? To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: dx+FGREhUPFU2Zih+DX7DA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 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: Rajeev, >I would like to add that there are issues surrounding header compression as >well. Note that the context resides on the old-AR. What type of packet does it >bicast ? compressed or uncompressed packet ? If it is uncompressed, it is not >useful without the new-AR having the compression context. See draft-kenward-seamoby-ct-rohc-reqs-00.txt for how to get that header compression state to the new AR. >On the other hand, >if the new-AR has to possess the context *simultaneously*, this adds a new >dimension to header compression: Many-to-One header compression! I don't follow. If the old AR gets the trigger for context transfer soon enough, it can send the header compression state to the new AR. New AR installs it, compresses incoming bicast packet headers. > If the old-AR >sends compressed packets to the new-AR, how does the latter handle them ? There has been some talk about handling this, but nobody has come out with a coherent scheme yet. >Also, since the MN is not bicasting in the uplink, the uplink context is >current only on the old-AR even if the new-AR has the context. So, there is a >synchronization issue as well. > I don't follow. What does the MN not bicasting have to do with it? The MN sends packets either on the old L2 or through new AR on the new L2. If on the latter, MN must either have a valid CoA for the new subnet or new AR must tunnel to old AR. jak From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 25 19:18:53 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA20607 for ; Wed, 25 Jul 2001 19:18:51 -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 QAA14916; Wed, 25 Jul 2001 16:19:28 -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 QAA00888; Wed, 25 Jul 2001 16:19:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PNHpl28575 for mobile-ip-dist; Wed, 25 Jul 2001 16:17:52 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PNHmY28568 for ; Wed, 25 Jul 2001 16:17:48 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA00562 for ; Wed, 25 Jul 2001 16:18:01 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA03707 for ; Wed, 25 Jul 2001 16:18:00 -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 QAA10244 for ; Wed, 25 Jul 2001 16:17:58 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6PNHve01639 for ; Wed, 25 Jul 2001 16:17:57 -0700 X-mProtect: Wed, 25 Jul 2001 16:17:57 -0700 Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdT6rsIY; Wed, 25 Jul 2001 16:17:55 PDT Message-ID: <3B5F53A3.B25B51CD@iprg.nokia.com> Date: Wed, 25 Jul 2001 16:17:55 -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: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Handover Smoothing - What to Do? 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 Phil, Phil Roberts wrote: [snip] > > I wouldn't call it a procedural issue but a need to make a decision. I > (personally) > would like to make a consensus call on both FMIPv4 and FMIPv6 right after > London and I don't want to send up drafts one with and one without an option > for smoothing. So our consensus calls will probably be something like 1) do > we want smoothing in a separate draft and if so, 2) is FMIPv6 ready for last > call and is FMIPv4 ready for last call after we remove the smoothing bits; > and > if not 3) is FMIPv4 read for last call and FMIPv6 ready for last call after > we add the smoothing bits. > > Right now it seems that George at least is uncomfortable with making > smoothing an essential part > of the FMIP draft. Hesham at least is uncomfortable with progressing the > FMIP draft without smoothing. Hesham's position excludes the middle ground > of putting smoothing into a separate draft. As an aside it seems clear that > smoothing is an optional feature in the FMIPv4 draft but I'm not sure > whether > the proposal is to make it optional when incorporated in FMIPv6. > > There does seem to be some consensus that if a smoothing technique is chosen > it should be through bicasting or simultaneous binding rather than some kind > of > buffering. At the minimum we should have a discussion of why the tradeoff > of > accepting the possibility of duplicate packets weighs more heavily than > accepting > the possibility of lost packets and the results should be documented. > I would like to mention the issue surrounding header compression and bicasting. I posted a separate e-mail on this topic BTW. The problem is what type of a packet does the old-AR bicast ? If it is uncompressed, then the new-AR needs compression context to forward the compressed packet to the MN. Unfortunately, this means support for Many-to-One mode of header compression (the two ARs to the MN) which to my knowledge has not been defined. Thanks [rohc]! If the old-AR bicasts a compressed packet to the new-AR, how does the new-AR forward that packet ? In the uplink, only the old-AR would have the up-to-date context. This introduces synchronization issues even when the new-AR may concurrently possess the header compression state. So, it is perhaps premature to state that there is consensus. I think bicasting must not be coupled to FMIPv6. It could ofcourse be a separate draft. My two cents.. -Rajeev > > George has also asserted (and speaking for myself personally I also agree > with) > that implementations in some environments at least can solve this without > any kind > of protocol support at layer 3. > > Does this seem to summarize everyone's position accurately? Does this > answer your question > enough, Jim? > > Of course, others contributing to the conversation COULD help, > Phil > From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 25 19:33:19 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA21636 for ; Wed, 25 Jul 2001 19:33:19 -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 QAA20053; Wed, 25 Jul 2001 16:34: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 QAA04167; Wed, 25 Jul 2001 16:33:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PNWSg28729 for mobile-ip-dist; Wed, 25 Jul 2001 16:32:28 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PNWOY28722 for ; Wed, 25 Jul 2001 16:32:24 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA03958 for ; Wed, 25 Jul 2001 16:32:37 -0700 (PDT) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA09702 for ; Wed, 25 Jul 2001 16:32:36 -0700 (PDT) Received: by megisto-sql1.megisto.com with Internet Mail Service (5.5.2650.21) id ; Wed, 25 Jul 2001 19:31:06 -0400 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Handover Smoothing - What to Do? Date: Wed, 25 Jul 2001 19:31:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) 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: > Also, for the scenarios we consider in low-latency, the MN will not > get multiple copies of packets. The "second" copy gets > discarded by the > non-connected FA (e.g. nFA) and an ICMP error is not transmitted. > Alternatively that second copy may be buffered. When the MN > connects to > nFA it no longer receives from oFA. That's what the draft > specifies and > I think that should be quite typical for a single-interfaced MN. > So that's why we went for this solution and allowed bicasting. Thanks for the pointer to this. I'm glad it is specified as a MAY. I'm a little puzzled about why you think what you've described solves your problem and doesn't introduce the possibility of multiple copies of a packet being delivered. How would you implement the two FAs? They are both receiving packets without any knowledge of what the other has received, or has forwarded to the MN. Might you not have a situation like this? At a single point in time the MN is no longer reachable from the oFA and is not yet reachable on the nFA. At that point in time a packet arrives at both oFA and nFA and they discard the packet. The MN attaches to the nFA but the packet is gone. (That's in case A you describe). Or like this? At a single point in time a packet arrives at the oFA and is sent to the MN and at the same time arrives at the nFA and gets buffered. The MN disconnects and then reconnects at the nFA and gets a second copy of the packet. (That's in case B you describe). Or like this? The same packet arrives at oFA and is transmitted to the MN which then moves to the nFA and gets the same packet which was delayed on its way to the nFA. Or like this? The MN disconnects from the oFA the packet arrives and is dropped, then the MN comes back to the oFA because of radio conditions and the packet has been lost. It seems like there is some coordination needed between the oFA and the nFA to overcome these problems, perhaps a temporary tunnel? But in that case bicasting from an HA or a hierarchical FA wouldn't be adding much to it, would it. At any rate one would think that issues like this need some exploration and explanation somewhere. Phil > Regards > /Karim > From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 25 19:35:53 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA21793 for ; Wed, 25 Jul 2001 19:35:52 -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 RAA21111; Wed, 25 Jul 2001 17:36: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 QAA04572; Wed, 25 Jul 2001 16:36:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PNYxo28783 for mobile-ip-dist; Wed, 25 Jul 2001 16:34:59 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PNYuY28776 for ; Wed, 25 Jul 2001 16:34:56 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA27106 for ; Wed, 25 Jul 2001 16:35:09 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA10626 for ; Wed, 25 Jul 2001 16:35: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 QAA11717 for ; Wed, 25 Jul 2001 16:35:07 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6PNZ6r08839 for ; Wed, 25 Jul 2001 16:35:06 -0700 X-mProtect: Wed, 25 Jul 2001 16:35:06 -0700 Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdfOEU8q; Wed, 25 Jul 2001 16:35:05 PDT Message-ID: <3B5F57A9.82CEE3D4@iprg.nokia.com> Date: Wed, 25 Jul 2001 16:35:05 -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: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Handover Smoothing - What to Do? References: <200107252309.QAA23277@heliopolis.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 Hello James, James Kempf wrote: > Rajeev, > > >I would like to add that there are issues surrounding header compression as > >well. Note that the context resides on the old-AR. What type of packet does it > >bicast ? compressed or uncompressed packet ? If it is uncompressed, it is not > >useful without the new-AR having the compression context. > > See draft-kenward-seamoby-ct-rohc-reqs-00.txt for how to get that > header compression state to the new AR. > Thanks. I will take a look.You might also want to look at draft-koodli-seamoby-hc-relocate-01.txt :-) > > >On the other hand, > >if the new-AR has to possess the context *simultaneously*, this adds a new > >dimension to header compression: Many-to-One header compression! > > I don't follow. If the old AR gets the trigger for context transfer > soon enough, it can send the header compression state to the new > AR. New AR installs it, compresses incoming bicast packet headers. > First, what is this soon enough ? Second, you need special route entry to make sure that a packet addressed to old-IP address of the MN is properly forwarded. Third, the some fields do not necessarily remain constant due to processing at new-AR. What happens to the Hop Limit and perhaps the Traffic Class field ? If they change, how does the MN's compression engine know about this ? > > > If the old-AR > >sends compressed packets to the new-AR, how does the latter handle them ? > > There has been some talk about handling this, but nobody has > come out with a coherent scheme yet. I also have an idea. Not sure where to specify it. Or is it needed to be specified at all.. > > >Also, since the MN is not bicasting in the uplink, the uplink context is > >current only on the old-AR even if the new-AR has the context. So, there is a > >synchronization issue as well. > > > > I don't follow. What does the MN not bicasting have to do with it? The > MN sends packets either on the old L2 or through new AR on the new > L2. If on the latter, MN must either have a valid CoA for the new > subnet or new AR must tunnel to old AR. > If there is a context at both the ARs, the uplink context is current only on the old-AR to which the MN is connected. The MN does not transmit packets to both the ARs (uplink bicasting) correct ? Hope this helps. Anyway, my point is there are (important, hairy) issues to consider when combining bicasting with compression. I don't want unwanted complexity in implementing header compression due to bicasting (even if you can specify how to do it)! If you really want bicasting, propose it as a separate draft. Regards, -Rajeev > > jak From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 25 19:52:19 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA22667 for ; Wed, 25 Jul 2001 19:52: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 QAA26264; Wed, 25 Jul 2001 16:53: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 QAA20594; Wed, 25 Jul 2001 16:53:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PNppB28958 for mobile-ip-dist; Wed, 25 Jul 2001 16:51:51 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PNplY28951 for ; Wed, 25 Jul 2001 16:51:47 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA21989 for ; Wed, 25 Jul 2001 16:52:00 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA17713 for ; Wed, 25 Jul 2001 16:51:59 -0700 (PDT) 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 f6PNq1g10399 for ; Wed, 25 Jul 2001 16:52:01 -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 AAW21247; Wed, 25 Jul 2001 16:51:54 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA10828; Wed, 25 Jul 2001 16:51:54 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15199.23450.70449.789544@thomasm-u1.cisco.com> Date: Wed, 25 Jul 2001 16:51:54 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Handover Smoothing - What to Do? In-Reply-To: <3B5F4F57.1927AA19@iprg.nokia.com> References: <8C92E23A3E87FB479988285F9E22BE460546A1@ftmail> <3B5F4F57.1927AA19@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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Rajeev Koodli writes: > Hello folks, > > I would like to add that there are issues surrounding header compression as > well. Note that the context resides on the old-AR. What type of packet does it > bicast ? compressed or uncompressed packet ? If it is uncompressed, it is not > useful without the new-AR having the compression context. On the other hand, > if the new-AR has to possess the context *simultaneously*, this adds a new > dimension to header compression: Many-to-One header compression! If the old-AR > sends compressed packets to the new-AR, how does the latter handle them ? > Also, since the MN is not bicasting in the uplink, the uplink context is > current only on the old-AR even if the new-AR has the context. So, there is a > synchronization issue as well. As a follow up to my previous comment, I believe that regardless of whether you allow for bicasting or not, context transfer of header compression state should be viewed as a fork operation rather than a move operation. This allows for race conditions where MN still sees old-AR packets in the movement window to be processed correctly. When it eventually gets to new-AR, new packets to MN will just look like there were a drop or two which the new context should be able to recover from. Mike From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 25 21:00:04 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA27047 for ; Wed, 25 Jul 2001 21:00:04 -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 OAA24963; Wed, 25 Jul 2001 14:11: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 OAA15550; Wed, 25 Jul 2001 14:11:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PLA7o27447 for mobile-ip-dist; Wed, 25 Jul 2001 14:10:07 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PLA4Y27440 for ; Wed, 25 Jul 2001 14:10:04 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id OAA17136 for ; Wed, 25 Jul 2001 14:10:18 -0700 (PDT) Message-Id: <200107252110.OAA17136@heliopolis.eng.sun.com> Date: Wed, 25 Jul 2001 14:10:17 -0700 (PDT) From: James Kempf Subject: Re: [mobile-ip] Analysis of Jitter in Bicasting To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: KPisPmtz6E1UvuddluvTnw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 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, >> ..*provided* the combined L2/L3 handover latency is less than 112.5 sec, given >> a 6 kbps incoming real time data stream (typical for VoIP) and >> an uplink data rate of 9.6 kbps (typical of existing 2G voice systems). > >i guess you meant 112.5 ms. > Right, sorry. >i need to buffer atleast one packet, the FBACK. otherwise it gets >dropped >and could potentially screw up fast handoffs. > Um, so what happens to the real time packets while the FBACK is getting buffered? And how do you know that the FBACK will arrive and should be buffered exactly during L2 handover? It could arrive before, it could arrive after. What about the rest (minimum 4 at my count) packets involved in FMIP handover before the MN gets to start doing DAD (over the air), etc., on the new AR before it can start getting its real time traffic? If you are going to buffer, you need to buffer during the expected duration of the L2 + L3 handover, regardless of what the traffic is. If you look in Appendix A of draft-kempf-beth-ipv6-01.txt, you'll see a calcuated minimum duration for handover using FMIPv6 of 133 ms for L3 handover *only* @ 9.6 kbps uplink speed. Add another 100 ms (a wild guess, I have not yet been able to find anyone who can give me figures for wCDMA) for L2 handover and you are already almost double the 112.5 ms time for the user to notice. In addition, the scenarios in Appendix A do not assume that the MN completes valid new CoA aquisition on the new AR, they assume that the MN uses its old CoA and the old AR is tunnelling, which is the fallback scenario. If you include completion of new CoA aquisition, you'll add yet more time. Meantime, the user is waiting... jak From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 25 21:00:59 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA27115 for ; Wed, 25 Jul 2001 21:00:58 -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 NAA13825; Wed, 25 Jul 2001 13:47: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 NAA09297; Wed, 25 Jul 2001 13:47:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PKjcb27210 for mobile-ip-dist; Wed, 25 Jul 2001 13:45:38 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PKjYY27203 for ; Wed, 25 Jul 2001 13:45:34 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id NAA15580 for ; Wed, 25 Jul 2001 13:45:48 -0700 (PDT) Message-Id: <200107252045.NAA15580@heliopolis.eng.sun.com> Date: Wed, 25 Jul 2001 13:45:47 -0700 (PDT) From: James Kempf Subject: Re: [mobile-ip] Handover Smoothing - What to Do? To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: vCkIJ0hQuKxeIbTxP0QyVA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 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: Pat, I agree. jak >Date: Wed, 25 Jul 2001 12:21:14 -0700 >From: Pat Calhoun >To: mobile-ip@sunroof.eng.sun.com >Subject: Re: [mobile-ip] Handover Smoothing - What to Do? >Content-Disposition: inline >User-Agent: Mutt/1.2.5i > >I unfortunately agree with most folks that disagree with each other. On >one hand, the low latency draft without smoothing techniques is incomplete, >but on the other hand, additional (and perhaps even better) techniques may >be developed over time. > >So, one alternative is to add text to the fast drafts that without such a >technique, the draft is incomplete. Then the WG could develop a series of >smoothing techniques (perhaps each in separate drafts, but well identified). > >So, the fast draft does point to external work, and it does claim that by >itself it really is incomplete, but on the other hand, it isn't tied to >a specific mechanism, and allows for future extensibility. > >My 2 cents, > >PatC >On Wed, Jul 25, 2001 at 02:03:44PM -0400, Phil Roberts wrote: >> > Well, I understand where you are coming from, as I would like >> > a complete >> > handover solution to be done soon too. But realistically, it takes as >> > long as it takes. If we can peel off the FMIP work and get IESG to >> > take a look at that, we can reduce the amount of time later when >> > we do reach concensus on smoothing. >> > >> > I'd like to hear from the WG chairs and ADs on this, I guess, since >> > it seems to me basically a procedural issue. Raj has already come >> > out for keeping smoothing separate for now, what do the rest of >> > you think? >> > >> > jak >> > >> >> I wouldn't call it a procedural issue but a need to make a decision. I >> (personally) >> would like to make a consensus call on both FMIPv4 and FMIPv6 right after >> London and I don't want to send up drafts one with and one without an option >> for smoothing. So our consensus calls will probably be something like 1) do >> we want smoothing in a separate draft and if so, 2) is FMIPv6 ready for last >> call and is FMIPv4 ready for last call after we remove the smoothing bits; >> and >> if not 3) is FMIPv4 read for last call and FMIPv6 ready for last call after >> we add the smoothing bits. >> >> Right now it seems that George at least is uncomfortable with making >> smoothing an essential part >> of the FMIP draft. Hesham at least is uncomfortable with progressing the >> FMIP draft without smoothing. Hesham's position excludes the middle ground >> of putting smoothing into a separate draft. As an aside it seems clear that >> smoothing is an optional feature in the FMIPv4 draft but I'm not sure >> whether >> the proposal is to make it optional when incorporated in FMIPv6. >> >> There does seem to be some consensus that if a smoothing technique is chosen >> it should be through bicasting or simultaneous binding rather than some kind >> of >> buffering. At the minimum we should have a discussion of why the tradeoff >> of >> accepting the possibility of duplicate packets weighs more heavily than >> accepting >> the possibility of lost packets and the results should be documented. >> >> George has also asserted (and speaking for myself personally I also agree >> with) >> that implementations in some environments at least can solve this without >> any kind >> of protocol support at layer 3. >> >> Does this seem to summarize everyone's position accurately? Does this >> answer your question >> enough, Jim? >> >> Of course, others contributing to the conversation COULD help, >> Phil >> From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 25 22:15:03 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA02935 for ; Wed, 25 Jul 2001 22:15:01 -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 QAA20156; Wed, 25 Jul 2001 16:34:29 -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 QAA04184; Wed, 25 Jul 2001 16:34:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PNWNs28720 for mobile-ip-dist; Wed, 25 Jul 2001 16:32:23 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PNWKY28713 for ; Wed, 25 Jul 2001 16:32: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 QAA26603 for ; Wed, 25 Jul 2001 16:32:32 -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 RAA28137 for ; Wed, 25 Jul 2001 17:33:58 -0600 (MDT) 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 f6PNWhT29385 for ; Wed, 25 Jul 2001 16:32:43 -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 AAW20733; Wed, 25 Jul 2001 16:32:29 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA10823; Wed, 25 Jul 2001 16:32:28 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15199.22284.692193.943197@thomasm-u1.cisco.com> Date: Wed, 25 Jul 2001 16:32:28 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Handover Smoothing - What to Do? In-Reply-To: <200107252309.QAA23277@heliopolis.eng.sun.com> References: <200107252309.QAA23277@heliopolis.eng.sun.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 James Kempf writes: > >On the other hand, > >if the new-AR has to possess the context *simultaneously*, this adds a new > >dimension to header compression: Many-to-One header compression! > > I don't follow. If the old AR gets the trigger for context transfer > soon enough, it can send the header compression state to the new > AR. New AR installs it, compresses incoming bicast packet headers. The problem is that you have one ROHC context with two packet sources, AR1 and AR2. Sounds like the ROHC context needs to be forked (cloned) on MN too, and the MN needs to pay attention to the i/f it came in on for real (which already does, I assume). Mike From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 26 10:48:24 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA14217 for ; Thu, 26 Jul 2001 10:48:23 -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 IAA26030; Thu, 26 Jul 2001 08:49:14 -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 HAA02635; Thu, 26 Jul 2001 07:47:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6QEkwM01862 for mobile-ip-dist; Thu, 26 Jul 2001 07:46:58 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6QEktY01853 for ; Thu, 26 Jul 2001 07:46:55 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA17119 for ; Thu, 26 Jul 2001 07:47:08 -0700 (PDT) Received: from zcars0m9.ca.nortel.com ([47.129.242.157]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA06923 for ; Thu, 26 Jul 2001 07:47:07 -0700 (PDT) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f6QEkk916800 for ; Thu, 26 Jul 2001 10:46:46 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Thu, 26 Jul 2001 10:46:56 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Jul 2001 10:47:00 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5E8D@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Handover Smoothing - What to Do? Date: Thu, 26 Jul 2001 10:47:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C115E1.D4C68750" X-Orig: 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_01C115E1.D4C68750 Content-Type: text/plain; charset="iso-8859-1" Rajeev: Is one answer that the old AR could send uncompressed packets to the new AR, and the new AR would then compress the packets or not, depending on whether it had the context (there is a an case to be made here for proactive ct ;^}). Depending on what was actually sent over the air, this could create a tricky problem to solve at the MN, as it may need to process the two streams before it could even attempt duplicate removal, and this would require two compression state machines, buffers, etc., etc. Not nice. One way of looking at this scenario is that the IP stream is being handed over in a smooth/fast/seamless manner, but two over the air links have to be used in a make before break scenario to accomplish this. Gary > -----Original Message----- > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > Sent: July 25, 2001 19:00 > To: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Handover Smoothing - What to Do? > > > Hello folks, > > I would like to add that there are issues surrounding header > compression as > well. Note that the context resides on the old-AR. What type > of packet does it > bicast ? compressed or uncompressed packet ? If it is > uncompressed, it is not > useful without the new-AR having the compression context. On > the other hand, > if the new-AR has to possess the context *simultaneously*, > this adds a new > dimension to header compression: Many-to-One header > compression! If the old-AR > sends compressed packets to the new-AR, how does the latter > handle them ? > Also, since the MN is not bicasting in the uplink, the uplink > context is > current only on the old-AR even if the new-AR has the > context. So, there is a > synchronization issue as well. > > Regards, > > -Rajeev > > > George Tsirtsis wrote: > > > -----Original Message----- > > From: Karim El-Malki (ERA) [mailto:Karim.El-Malki@era.ericsson.se] > > Sent: Tuesday, July 24, 2001 10:53 AM > > To: 'mobile-ip@sunroof.eng.sun.com'; James.Kempf@sun.com > > Subject: RE: [mobile-ip] Handover Smoothing - What to Do? > > > > Hello Raj and James > > > > ... > > > > >I would recommend removing it and focusing on smoothing > > > of handoffs in a separate I-D. Handoff smoothing can also > be achieved > > > by buffering. So why recommend only bicasting as the > mechanism for the > > > desired effect? I do not believe there has been any real > consensus of > > > going one way vs the other. > > > > > > > There has been consensus among the design team members and up to now > > we have not received negative comments on the low latency > draft nor during > > the IETF presentations. I would be happy to consider buffering as an > > alternative and eventually add it into the draft if the > authors/WG want > > this, > > but all the methods must satisfy the requirement of > eliminating the period > > of > > service disruption due to L3 handoff independently of the L2 > > characteristics. > > Without this IMO the draft would not serve its purpose. > > > > GT> This was discussed in (I think) much greater length in > the FMIPv6 design > > team and enough doubts were raised to exclude bicasting > from the FMIPv6 spec > > and encourage its proponents to publish the idea as a > separate document, > > which they did...well done :). The main argument against > bicasting was > > regarding its possible effects on TCP. Bicasting would > duplicate TCP ACKS > > (along with everything else) and as we know 3 dupacks result in TCP > > shrinking its window...dupacks occur naturally by TCP as a > result of the > > network loosing or reordering packets and the chance of 3 > dupacks in a row > > is not very high. We thought that bicasting may increase > the chance of 3 > > dupacks and thus impact TCP performance. > > > > > > > Note that there has been work towards eliminating this well > known problem > > and Karim can point the list to this work since I do not > remember that draft > > name. Nevertheless, the FMIPv6 team decided that bicasting > has experimental > > nature and the TCP fix was at the time a draft at > v00...early days => not > > enough practical experiance or understanding of what a > possiby wide spread > > use of bicasting do to TCP. For all the above we thought > that bicasting > > should be discussed as a separate item and the FMIPv6 spec > should not be > > dependant on it. The fact that the FMIPv4 team did not take the same > > decision always concerned me a bit... > > > > IMO smoothing (bicasting and/or buffering) should be > separate specs from the > > FMIPv4/v6 not only because of the uncertainty regarding > bicasting but also > > because (again IMO) smooth handoffs may be achieved at the > implementation > > level and without protocol support. That is not to say that > protocol work > > may not help and should not be done...but only to indicate > that "smooth > > handoff" work should be separate from the FMIP work. In fact, smooth > > handoffs could be viewed as optional extensions to the FMIP specs. > > > > Thanks > > George > > ------_=_NextPart_001_01C115E1.D4C68750 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Handover Smoothing - What to Do?

Rajeev:

  Is one answer that the old AR could send = uncompressed packets
to the new AR, and the new AR would then compress = the packets or
not, depending on whether it had the context (there = is a an case
to be made here for proactive ct ;^}). Depending on = what was actually
sent over the air, this could create a tricky = problem to solve
at the MN, as it may need to process the two streams = before it could
even attempt duplicate removal, and this would = require two compression
state machines, buffers, etc., etc. Not nice.

  One way of looking at this scenario is that = the IP stream is being
handed over in a smooth/fast/seamless manner, but = two over the air
links have to be used in a make before break = scenario to accomplish this.

Gary

> -----Original Message-----
> From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com]<= /FONT>
> Sent: July 25, 2001 19:00
> To: mobile-ip@sunroof.eng.sun.com
> Subject: Re: [mobile-ip] Handover Smoothing - = What to Do?
>
>
> Hello folks,
>
> I would like to add that there are issues = surrounding header
> compression as
> well. Note that the context resides on the = old-AR. What type
> of packet does it
> bicast ? compressed or uncompressed packet ? If = it is
> uncompressed, it is not
> useful without the new-AR having the = compression context.  On
> the other hand,
> if the new-AR has to possess the context = *simultaneously*,
> this adds a new
> dimension to header compression: Many-to-One = header
> compression! If the old-AR
> sends compressed packets to the new-AR, how = does the latter
> handle them ?
> Also, since the MN is not bicasting in the = uplink, the uplink
> context is
> current only on the old-AR even if the new-AR = has the
> context. So, there is a
> synchronization issue as well.
>
> Regards,
>
> -Rajeev
>
>
> George Tsirtsis wrote:
>
> > -----Original Message-----
> > From: Karim El-Malki (ERA) [mailto:Karim.El-Malki@era= .ericsson.se]
> > Sent: Tuesday, July 24, 2001 10:53 = AM
> > To: 'mobile-ip@sunroof.eng.sun.com'; = James.Kempf@sun.com
> > Subject: RE: [mobile-ip] Handover = Smoothing - What to Do?
> >
> > Hello Raj and James
> >
> > ...
> >
> > >I would recommend removing it and = focusing on smoothing
> > > of handoffs in a separate I-D. = Handoff smoothing can also
> be achieved
> > > by buffering. So why recommend only = bicasting as the
> mechanism for the
> > > desired effect? I do not believe = there has been any real
> consensus of
> > > going one way vs the other.
> > >
> >
> > There has been consensus among the design = team members and up to now
> > we have not received negative comments on = the low latency
> draft nor during
> > the IETF presentations. I would be happy = to consider buffering as an
> > alternative and eventually add it into the = draft if the
> authors/WG want
> > this,
> > but all the methods must satisfy the = requirement of
> eliminating the period
> > of
> > service disruption due to L3 handoff = independently of the L2
> > characteristics.
> > Without this IMO the draft would not serve = its purpose.
> >
> > GT> This was discussed in (I think) = much greater length in
> the FMIPv6 design
> > team and enough doubts were raised to = exclude bicasting
> from the FMIPv6 spec
> > and encourage its proponents to publish = the idea as a
> separate document,
> > which they did...well done :). The main = argument against
> bicasting was
> > regarding its possible  effects on = TCP. Bicasting would
> duplicate TCP ACKS
> > (along with everything else) and as we = know 3 dupacks result in TCP
> > shrinking its window...dupacks occur = naturally by TCP as a
> result of the
> > network loosing or reordering packets and = the chance of 3
> dupacks in a row
> > is not very high. We thought that = bicasting may increase
> the chance of 3
> > dupacks and thus impact TCP = performance.
> >
> >
>
> > Note that there has been work towards = eliminating this well
> known problem
> > and Karim can point the list to this work = since I do not
> remember that draft
> > name. Nevertheless, the FMIPv6 team = decided that bicasting
> has experimental
> > nature and the TCP fix was at the time a = draft at
> v00...early days =3D> not
> > enough practical experiance or = understanding of what a
> possiby wide spread
> > use of bicasting do to TCP. For all the = above we thought
> that bicasting
> > should be discussed as a separate item and = the FMIPv6 spec
> should not be
> > dependant on it. The fact that the FMIPv4 = team did not take the same
> > decision always concerned me a = bit...
> >
> > IMO smoothing (bicasting and/or buffering) = should be
> separate specs from the
> > FMIPv4/v6 not only because of the = uncertainty regarding
> bicasting but also
> > because (again IMO) smooth handoffs may be = achieved at the
> implementation
> > level and without protocol support. That = is not to say that
> protocol work
> > may not help and should not be done...but = only to indicate
> that "smooth
> > handoff" work should be separate from = the FMIP work. In fact, smooth
> > handoffs could be viewed as optional = extensions to the FMIP specs.
> >
> > Thanks
> > George
>
>

------_=_NextPart_001_01C115E1.D4C68750-- From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 26 11:32:50 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA18146 for ; Thu, 26 Jul 2001 11:32:50 -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 JAA03264; Thu, 26 Jul 2001 09:33: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 IAA04640; Thu, 26 Jul 2001 08:33:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6QFWav02451 for mobile-ip-dist; Thu, 26 Jul 2001 08:32:36 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6QFWWY02444 for ; Thu, 26 Jul 2001 08:32:32 -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 IAA04431 for ; Thu, 26 Jul 2001 08:32:46 -0700 (PDT) Received: from EXCHANGE01.domain.ecutel.com ([65.201.154.134]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA02269 for ; Thu, 26 Jul 2001 09:32:44 -0600 (MDT) content-class: urn:content-classes:message Subject: [mobile-ip] Relation between IPv6 and MIP MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Date: Thu, 26 Jul 2001 11:32:44 -0400 Message-ID: Thread-Topic: [mobile-ip] Handover Smoothing - What to Do? Thread-Index: AcEV4azzPSmgr7X6Q9WUKm413niu1AACiYLQ From: "Qiang Zhang" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f6QFWXY02445 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, I've always thought that MIP is an addon protocol for IPv6, so it is a SHOULD not a MUST implementation, is this correct? If MIP is optional, then a node doesn't have to maintain all binding signaling, but REALLY has to support home address option, is this an valid requirement imposed from MIP? Please clarify, thank you From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 26 13:19:52 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA22072 for ; Thu, 26 Jul 2001 13:19:51 -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 KAA08918; Thu, 26 Jul 2001 10:20: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 KAA01706; Thu, 26 Jul 2001 10:19:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6QHIDs03271 for mobile-ip-dist; Thu, 26 Jul 2001 10:18:13 -0700 (PDT) Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6QHIBY03264 for ; Thu, 26 Jul 2001 10:18: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 NAA15881 for ; Thu, 26 Jul 2001 13:18:25 -0400 (EDT) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id NAA26669 for mobile-ip@sunroof.eng.sun.com; Thu, 26 Jul 2001 13:18:50 -0400 (EDT) Received: from jurassic.eng.sun.com (jurassic [129.146.81.144] (may be forged)) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6Q7XEY00083 for ; Thu, 26 Jul 2001 00:33:14 -0700 (PDT) Received: from teknoturk (dsl197-130.Eng.Sun.COM [129.146.197.130]) by jurassic.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with SMTP id f6Q7XPS915729 for ; Thu, 26 Jul 2001 00:33:25 -0700 (PDT) From: "Alper" To: Subject: RE: [mobile-ip] Analysis of Jitter in Bicasting Date: Thu, 26 Jul 2001 00:23:26 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <8C92E23A3E87FB479988285F9E22BE460546C2@ftmail> Importance: Normal 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: Content-Transfer-Encoding: 7bit > Indeed, I suspect that the end-to-end principal is our friend > here. Real time traffic already uses jitter buffers, and good > ones are adaptive to transient conditions. For this kind of > traffic, you most definitely would *not* want L2-L3 smoothing > jitter out for you or you might end up with unnecessary additive > latency. I'm not sure that jitter concealment would be all that > useful in other places though. TCP's should be fairly resilient > to small amounts of jitter, which I would expect would be the > case with localized handoff schemes such as FMIP (ie, adding > 80ms to an average RTT of 80ms because of FMIP handoff, should > get lost in the noise.) > The other alternative is to actually not bicast at all, but to simply have old AR start tunnelling when it sees that L2 has stopped sending packets through old AR. If it can get this information. Much more bandwidth efficient anyway... GT> yes! yes! and assuming the network is well dimentioned as you suggested earlier this should work fine. aey> exactly. if your L2 can tell you when a MN attaches or detaches, you don't need to use bi-casting. This not only saves the network bandwidth and prevent possible packet duplication, but also saves processing power on the AR. With bicasting, AR needs to duplicate packets and send both copies. alper From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 26 13:19:52 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA22075 for ; Thu, 26 Jul 2001 13:19:51 -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 LAA06029; Thu, 26 Jul 2001 11:20: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 KAA01975; Thu, 26 Jul 2001 10:20:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6QHJDT03289 for mobile-ip-dist; Thu, 26 Jul 2001 10:19:13 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6QHJ9Y03282 for ; Thu, 26 Jul 2001 10:19:09 -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 KAA26251 for ; Thu, 26 Jul 2001 10:19:23 -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 LAA04742 for ; Thu, 26 Jul 2001 11:19: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 KAA29763 for ; Thu, 26 Jul 2001 10:19:22 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6QHJL921440 for ; Thu, 26 Jul 2001 10:19:21 -0700 X-mProtect: Thu, 26 Jul 2001 10:19:21 -0700 Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdrJYcju; Thu, 26 Jul 2001 10:19:18 PDT Message-ID: <3B605116.BB4CE38B@iprg.nokia.com> Date: Thu, 26 Jul 2001 10:19:18 -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: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Handover Smoothing - What to Do? References: <9FBD322B7824D511B36900508BF93C9C9F5E8D@zcard031.ca.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 Gary, Gary Kenward wrote: > > > Rajeev: > > Is one answer that the old AR could send uncompressed packets > to the new AR, and the new AR would then compress the packets or > not, depending on whether it had the context (there is a an case > to be made here for proactive ct ;^}). This is exactly what said below! If the new-AR transmits uncompressed packet, that's not good for spectral efficiency. In order to transmit compressed packets, it needs context. However, that is not the same as the context present at old-AR and hence the MN needs to have the ability to sync up with both the contexts. This Many-to-One HC is complicated. The case for moving the context is relatively easier (where you have a single, active context on the network side). > Depending on what was actually > sent over the air, this could create a tricky problem to solve > at the MN, as it may need to process the two streams before it could > even attempt duplicate removal, and this would require two compression > > state machines, buffers, etc., etc. Not nice. > Agreed. > > One way of looking at this scenario is that the IP stream is being > handed over in a smooth/fast/seamless manner, but two over the air > links have to be used in a make before break scenario to accomplish > this. > Sounds unnecessary, especially for implementing FMIPv6. Bicasting must not be part of FMIPv6. Regards, -Rajeev > > Gary > > > -----Original Message----- > > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > > Sent: July 25, 2001 19:00 > > To: mobile-ip@sunroof.eng.sun.com > > Subject: Re: [mobile-ip] Handover Smoothing - What to Do? > > > > > > Hello folks, > > > > I would like to add that there are issues surrounding header > > compression as > > well. Note that the context resides on the old-AR. What type > > of packet does it > > bicast ? compressed or uncompressed packet ? If it is > > uncompressed, it is not > > useful without the new-AR having the compression context. On > > the other hand, > > if the new-AR has to possess the context *simultaneously*, > > this adds a new > > dimension to header compression: Many-to-One header > > compression! If the old-AR > > sends compressed packets to the new-AR, how does the latter > > handle them ? > > Also, since the MN is not bicasting in the uplink, the uplink > > context is > > current only on the old-AR even if the new-AR has the > > context. So, there is a > > synchronization issue as well. > > > > Regards, > > > > -Rajeev > > > > > > George Tsirtsis wrote: > > > > > -----Original Message----- > > > From: Karim El-Malki (ERA) [mailto:Karim.El-Malki@era.ericsson.se] > > > > Sent: Tuesday, July 24, 2001 10:53 AM > > > To: 'mobile-ip@sunroof.eng.sun.com'; James.Kempf@sun.com > > > Subject: RE: [mobile-ip] Handover Smoothing - What to Do? > > > > > > Hello Raj and James > > > > > > ... > > > > > > >I would recommend removing it and focusing on smoothing > > > > of handoffs in a separate I-D. Handoff smoothing can also > > be achieved > > > > by buffering. So why recommend only bicasting as the > > mechanism for the > > > > desired effect? I do not believe there has been any real > > consensus of > > > > going one way vs the other. > > > > > > > > > > There has been consensus among the design team members and up to > now > > > we have not received negative comments on the low latency > > draft nor during > > > the IETF presentations. I would be happy to consider buffering as > an > > > alternative and eventually add it into the draft if the > > authors/WG want > > > this, > > > but all the methods must satisfy the requirement of > > eliminating the period > > > of > > > service disruption due to L3 handoff independently of the L2 > > > characteristics. > > > Without this IMO the draft would not serve its purpose. > > > > > > GT> This was discussed in (I think) much greater length in > > the FMIPv6 design > > > team and enough doubts were raised to exclude bicasting > > from the FMIPv6 spec > > > and encourage its proponents to publish the idea as a > > separate document, > > > which they did...well done :). The main argument against > > bicasting was > > > regarding its possible effects on TCP. Bicasting would > > duplicate TCP ACKS > > > (along with everything else) and as we know 3 dupacks result in > TCP > > > shrinking its window...dupacks occur naturally by TCP as a > > result of the > > > network loosing or reordering packets and the chance of 3 > > dupacks in a row > > > is not very high. We thought that bicasting may increase > > the chance of 3 > > > dupacks and thus impact TCP performance. > > > > > > > > > > > Note that there has been work towards eliminating this well > > known problem > > > and Karim can point the list to this work since I do not > > remember that draft > > > name. Nevertheless, the FMIPv6 team decided that bicasting > > has experimental > > > nature and the TCP fix was at the time a draft at > > v00...early days => not > > > enough practical experiance or understanding of what a > > possiby wide spread > > > use of bicasting do to TCP. For all the above we thought > > that bicasting > > > should be discussed as a separate item and the FMIPv6 spec > > should not be > > > dependant on it. The fact that the FMIPv4 team did not take the > same > > > decision always concerned me a bit... > > > > > > IMO smoothing (bicasting and/or buffering) should be > > separate specs from the > > > FMIPv4/v6 not only because of the uncertainty regarding > > bicasting but also > > > because (again IMO) smooth handoffs may be achieved at the > > implementation > > > level and without protocol support. That is not to say that > > protocol work > > > may not help and should not be done...but only to indicate > > that "smooth > > > handoff" work should be separate from the FMIP work. In fact, > smooth > > > handoffs could be viewed as optional extensions to the FMIP specs. > > > > > > > Thanks > > > George > > > > From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 26 13:23:12 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA22401 for ; Thu, 26 Jul 2001 13:23:11 -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 LAA08240; Thu, 26 Jul 2001 11:23:12 -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 KAA02690; Thu, 26 Jul 2001 10:23:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6QHLtY03411 for mobile-ip-dist; Thu, 26 Jul 2001 10:21:55 -0700 (PDT) Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6QHLqY03404 for ; Thu, 26 Jul 2001 10:21:52 -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 NAA16683 for ; Thu, 26 Jul 2001 13:22:06 -0400 (EDT) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id NAA26734 for mobile-ip@sunroof.eng.sun.com; Thu, 26 Jul 2001 13:22:31 -0400 (EDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6QCaYY01155 for ; Thu, 26 Jul 2001 05:36:34 -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 FAA04249 for ; Thu, 26 Jul 2001 05:36: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 GAA00858 for ; Thu, 26 Jul 2001 06:36:45 -0600 (MDT) Received: from fredrikj (sierra.local.ipunplugged.com [192.168.4.88]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with SMTP id OAA15844; Thu, 26 Jul 2001 14:38:27 +0200 From: "Fredrik Johansson" To: Cc: Subject: RE: [mobile-ip] RE: Last Call: Generalized NAI (GNAIE) Extension to Proposed Standard Date: Thu, 26 Jul 2001 14:38:16 +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.4133.2400 Importance: Normal In-Reply-To: <20010725073933.B10225@charizard.diameter.org> 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 Ok, sounds good to me. Can't believe that I didn't think of the mobile sending the previous FA nai. Just for my own curiosity, what are the rules to obsolete a rfc by another? e.g. to obsolete rfc 2794 and use the GNAI for all nai extensions? /Fredrik >-----Original Message----- >From: owner-mobile-ip@sunroof.eng.sun.com >[mailto:owner-mobile-ip@sunroof.eng.sun.com]On Behalf Of Pat Calhoun >Sent: den 25 juli 2001 16:40 >To: mobile-ip@sunroof.eng.sun.com >Cc: iesg@ietf.org >Subject: Re: [mobile-ip] RE: Last Call: Generalized NAI (GNAIE) >Extension to Proposed Standard > > >It was removed because it conflicted with the MN NAI defined in RFC 2794. >So, instead of introducing multiple ways to encode the same thing, and >end up with possible interoperability problems, we decided to eliminate >the subtype. Perhaps one day a mobile will have a different type of >identity to add (e.g. old foreign agent's NAI), so the sentence is still >valid. > >PatC > >On Wed, Jul 25, 2001 at 02:15:41PM +0200, Fredrik Johansson wrote: >> In sectin 3.0, subtypes are defined. >> >> 1. Is there a reason to why the MN_NAI has been removed as a subtype? >> 2. If there is no MN_NAI subtype, the sentence >> "When a mobile node or home agent adds a GNAI extension to a >> registration message, the extension MUST appear prior to any >> authentication extensions." >> doesn't make sence. Why should a mobile node add a GNAI with a subtype of >> the FA or HA? >> >> I suggest that the MN_NAI subtype be added again. >> >> "Sub-Type >> >> This field describes the type of the entity which owns the NAI. >> The following subtypes are defined: >> >> 1 HA_NAI >> 2 FA_NAI >> >> When a mobile node or home agent adds a GNAI extension to a >> registration message, the extension MUST appear prior to any >> authentication extensions." >> >> /Fredrik >> >> >-----Original Message----- >> >From: scoya@cnri.reston.va.us [mailto:scoya@cnri.reston.va.us]On Behalf >> >Of The IESG >> >Sent: den 20 juli 2001 18:05 >> >To: IETF-Announce: >> >Cc: mobile-ip@sunroof.eng.sun.com >> >Subject: Last Call: Generalized NAI (GNAIE) Extension to Proposed >> >Standard >> > >> > >> > >> >The IESG has received a request from the IP Routing for Wireless/Mobile >> >Hosts Working Group to consider Generalized NAI (GNAIE) Extension >> > as a Proposed Standard. >> > >> >The IESG plans to make a decision in the next few weeks, and solicits >> >final comments on this action. Please send any comments to the >> >iesg@ietf.org or ietf@ietf.org mailing lists by August 17, 2001. >> > >> >Files can be obtained via >> >http://www.ietf.org/internet-drafts/draft-ietf-mobileip-gnaie-04.txt >> > >> > >> From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 26 13:28:49 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA22861 for ; Thu, 26 Jul 2001 13:28:48 -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 KAA13232; Thu, 26 Jul 2001 10:28: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 KAA03550; Thu, 26 Jul 2001 10:26:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6QHPeF03503 for mobile-ip-dist; Thu, 26 Jul 2001 10:25:40 -0700 (PDT) Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6QHPcY03496 for ; Thu, 26 Jul 2001 10:25:38 -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 NAA17445 for ; Thu, 26 Jul 2001 13:25:52 -0400 (EDT) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id NAA26802 for mobile-ip@sunroof.eng.sun.com; Thu, 26 Jul 2001 13:26:17 -0400 (EDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6QEfkY01754 for ; Thu, 26 Jul 2001 07:41:46 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA24363 for ; Thu, 26 Jul 2001 07:41:59 -0700 (PDT) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA09394 for ; Thu, 26 Jul 2001 07:41:57 -0700 (PDT) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate2.mot.com (motgate2 2.1) with ESMTP id HAA05183 for ; Thu, 26 Jul 2001 07:41:46 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id HAA25971 for ; Thu, 26 Jul 2001 07:41:46 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2653.19) id <3XDBZCPA>; Thu, 26 Jul 2001 09:41:45 -0500 Message-ID: From: Singh Ajoy-ASINGH1 To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Handover Smoothing - What to Do? Date: Thu, 26 Jul 2001 09:41:45 -0500 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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hello Rajeev: Please see my inline reply. regards, ajoy I would like to mention the issue surrounding header compression and bicasting. I posted a separate e-mail on this topic BTW. The problem is what type of a packet does the old-AR bicast ? If it is uncompressed, then the new-AR needs compression context to forward the compressed packet to the MN. Unfortunately, this means support for Many-to-One mode of header compression (the two ARs to the MN) which to my knowledge has not been defined. Thanks [rohc]! If the old-AR bicasts a compressed packet to the new-AR, how does the new-AR forward that packet ? ajoy: I do not understand why new AR can not forward compressed packet to MN. If new AR can maintain a mapping of tunnel id versus MN id, it can forward the compressed packet to MN. If you use GRE tunnel between newAR and oldAR, you can use key field of GRE to identify the flow. Access router does not always need to look at destination IP address to forward the packet. Please look at RFC 2890 for GRE info. For example, when some node acts as L2TP LAC, the access router does not look at the destination IP address of IP header to forward the packet to the dialup client. In the uplink, only the old-AR would have the up-to-date context. This introduces synchronization issues even when the new-AR may concurrently possess the header compression state. So, it is perhaps premature to state that there is consensus. I think bicasting must not be coupled to FMIPv6. It could ofcourse be a separate draft. My two cents.. -----Original Message----- From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] Sent: Wednesday, July 25, 2001 6:18 PM To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Handover Smoothing - What to Do? Hello Phil, Phil Roberts wrote: [snip] > > I wouldn't call it a procedural issue but a need to make a decision. I > (personally) > would like to make a consensus call on both FMIPv4 and FMIPv6 right after > London and I don't want to send up drafts one with and one without an option > for smoothing. So our consensus calls will probably be something like 1) do > we want smoothing in a separate draft and if so, 2) is FMIPv6 ready for last > call and is FMIPv4 ready for last call after we remove the smoothing bits; > and > if not 3) is FMIPv4 read for last call and FMIPv6 ready for last call after > we add the smoothing bits. > > Right now it seems that George at least is uncomfortable with making > smoothing an essential part > of the FMIP draft. Hesham at least is uncomfortable with progressing the > FMIP draft without smoothing. Hesham's position excludes the middle ground > of putting smoothing into a separate draft. As an aside it seems clear that > smoothing is an optional feature in the FMIPv4 draft but I'm not sure > whether > the proposal is to make it optional when incorporated in FMIPv6. > > There does seem to be some consensus that if a smoothing technique is chosen > it should be through bicasting or simultaneous binding rather than some kind > of > buffering. At the minimum we should have a discussion of why the tradeoff > of > accepting the possibility of duplicate packets weighs more heavily than > accepting > the possibility of lost packets and the results should be documented. > I would like to mention the issue surrounding header compression and bicasting. I posted a separate e-mail on this topic BTW. The problem is what type of a packet does the old-AR bicast ? If it is uncompressed, then the new-AR needs compression context to forward the compressed packet to the MN. Unfortunately, this means support for Many-to-One mode of header compression (the two ARs to the MN) which to my knowledge has not been defined. Thanks [rohc]! If the old-AR bicasts a compressed packet to the new-AR, how does the new-AR forward that packet ? In the uplink, only the old-AR would have the up-to-date context. This introduces synchronization issues even when the new-AR may concurrently possess the header compression state. So, it is perhaps premature to state that there is consensus. I think bicasting must not be coupled to FMIPv6. It could ofcourse be a separate draft. My two cents.. -Rajeev > > George has also asserted (and speaking for myself personally I also agree > with) > that implementations in some environments at least can solve this without > any kind > of protocol support at layer 3. > > Does this seem to summarize everyone's position accurately? Does this > answer your question > enough, Jim? > > Of course, others contributing to the conversation COULD help, > Phil > From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 26 13:31:01 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA23141 for ; Thu, 26 Jul 2001 13:31:00 -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 KAA14910; Thu, 26 Jul 2001 10:31: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 KAA04085; Thu, 26 Jul 2001 10:28:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6QHRZq03541 for mobile-ip-dist; Thu, 26 Jul 2001 10:27:35 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6QHRVY03531 for ; Thu, 26 Jul 2001 10:27:32 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA28273 for ; Thu, 26 Jul 2001 10:27:44 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA14623 for ; Thu, 26 Jul 2001 10:27:42 -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 KAA00851 for ; Thu, 26 Jul 2001 10:27:41 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6QHRfJ15906 for ; Thu, 26 Jul 2001 10:27:41 -0700 X-mProtect: Thu, 26 Jul 2001 10:27:41 -0700 Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdreFZqI; Thu, 26 Jul 2001 10:27:39 PDT Message-ID: <3B60530B.D144908E@iprg.nokia.com> Date: Thu, 26 Jul 2001 10:27:39 -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: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Handover Smoothing - What to Do? References: <9FBD322B7824D511B36900508BF93C9C9F5E8E@zcard031.ca.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 Gary Kenward wrote: > > > Rajeev: > > Reading this email from you, I now understand better what you > meant by "many-to-one" mode. My first response was talking about > doing "many-to-one" above or after ROHC. I believe you are referring > to performing the combining of the two streams within ROHC - a > very powerful idea, given that the information from the two separate > streams could be used to improve robustness. However, the complexities > > of this approach do scare me, and I would think that the algorithm > would need much more research. > > In the meantime, combining (or selecting) above ROHC would work, > at the expense of running two independent ROHC decompressors at the MN > > (and probably two ROHC compressors for the traffic from MN to old and > new AR respectively). > I also alluded to the last paragraph in my previous e-mail. The MN needs two separate contexts for bicasting to work in downlink. In the uplink however, the MN is not doing bicasting (ok, except in soft handover, which may or may not be visible to IP). So, your last comment is not valid. That is, only the context at the old-AR is current. Reiterating my point, this must not be part of FMIPv6. Time permitting, I will work on a separate draft for smoothing and HC and outline these issues in detail. -Rajeev > > Comments? > > Gary > > > -----Original Message----- > > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > > Sent: July 25, 2001 19:18 > > To: mobile-ip@sunroof.eng.sun.com > > Subject: Re: [mobile-ip] Handover Smoothing - What to Do? > > > > > > Hello Phil, > > > > > > Phil Roberts wrote: > > [snip] > > > > > > > > I wouldn't call it a procedural issue but a need to make a > > decision. I > > > (personally) > > > would like to make a consensus call on both FMIPv4 and > > FMIPv6 right after > > > London and I don't want to send up drafts one with and one > > without an option > > > for smoothing. So our consensus calls will probably be > > something like 1) do > > > we want smoothing in a separate draft and if so, 2) is > > FMIPv6 ready for last > > > call and is FMIPv4 ready for last call after we remove the > > smoothing bits; > > > and > > > if not 3) is FMIPv4 read for last call and FMIPv6 ready for > > last call after > > > we add the smoothing bits. > > > > > > Right now it seems that George at least is uncomfortable with > making > > > smoothing an essential part > > > of the FMIP draft. Hesham at least is uncomfortable with > > progressing the > > > FMIP draft without smoothing. Hesham's position excludes > > the middle ground > > > of putting smoothing into a separate draft. As an aside it > > seems clear that > > > smoothing is an optional feature in the FMIPv4 draft but > > I'm not sure > > > whether > > > the proposal is to make it optional when incorporated in FMIPv6. > > > > > > There does seem to be some consensus that if a smoothing > > technique is chosen > > > it should be through bicasting or simultaneous binding > > rather than some kind > > > of > > > buffering. At the minimum we should have a discussion of > > why the tradeoff > > > of > > > accepting the possibility of duplicate packets weighs more > > heavily than > > > accepting > > > the possibility of lost packets and the results should be > > documented. > > > > > > > I would like to mention the issue surrounding header > > compression and bicasting. > > I posted a separate e-mail on this topic BTW. The problem is > > what type of a > > packet does the old-AR bicast ? If it is uncompressed, then > > the new-AR needs > > compression context to forward the compressed packet to the > > MN. Unfortunately, > > this means support for Many-to-One mode of header compression > > (the two ARs to > > the MN) which to my knowledge has not been defined. Thanks > > [rohc]! If the > > old-AR bicasts a compressed packet to the new-AR, how does > > the new-AR forward > > that packet ? > > In the uplink, only the old-AR would have the up-to-date context. > This > > introduces synchronization issues even when the new-AR may > > concurrently possess > > the header compression state. > > > > So, it is perhaps premature to state that there is consensus. > > I think bicasting > > must not be coupled to FMIPv6. It could ofcourse be a separate > draft. > > > > My two cents.. > > > > -Rajeev > > > > > > > > > > George has also asserted (and speaking for myself > > personally I also agree > > > with) > > > that implementations in some environments at least can > > solve this without > > > any kind > > > of protocol support at layer 3. > > > > > > Does this seem to summarize everyone's position accurately? > > Does this > > > answer your question > > > enough, Jim? > > > > > > Of course, others contributing to the conversation COULD help, > > > Phil > > > > > > > From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 26 13:35:33 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA24093 for ; Thu, 26 Jul 2001 13:35:33 -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 LAA18716; Thu, 26 Jul 2001 11:35:36 -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 KAA05666; Thu, 26 Jul 2001 10:35:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6QHY7a03727 for mobile-ip-dist; Thu, 26 Jul 2001 10:34:07 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6QHY4Y03720 for ; Thu, 26 Jul 2001 10:34:04 -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 KAA29810 for ; Thu, 26 Jul 2001 10:34:18 -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 LAA14860 for ; Thu, 26 Jul 2001 11:35:42 -0600 (MDT) 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 f6QHYGg22348 for ; Thu, 26 Jul 2001 10:34:16 -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 AAW33486; Thu, 26 Jul 2001 10:34:12 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA11110; Thu, 26 Jul 2001 10:34:12 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15200.21652.515917.627551@thomasm-u1.cisco.com> Date: Thu, 26 Jul 2001 10:34:12 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Analysis of Jitter in Bicasting In-Reply-To: <9FBD322B7824D511B36900508BF93C9C9F5E7E@zcard031.ca.nortel.com> References: <9FBD322B7824D511B36900508BF93C9C9F5E7E@zcard031.ca.nortel.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 Gary Kenward writes: > > From: James Kempf [mailto:James.Kempf@Sun.COM] > > In the case of 1, the probability of a duplicate packet has nothing > > whatsoever to do with the radio link. It is purely a matter of traffic > > engineering in the wired network. So the probability of a duplicate > > packet can be reduced by properly engineering the wired network. In > > addition, the probability is likely to increase with the topological > > distance between the new AR and the source of the bicast (simply > > because, the more network a packet has to traverse, the more likely > > it is that a congestion event may cause delay). Since engineering > > of the wired network is largely under the network operator's control, > > this problem is fairly straightforward to solve, though it may > > require measures such as over provisioning. > > Well, it takes more then over provisioning. You need to ensure > the same number of hops between the bicasting source (the traffic > bifurcation > point if you will), and you also need to provide some guaranteed bounds on > the delay at each hop after the bicasting source. *if* you want to ensure no > duplicates > at all at the receiver. This may seem like a definition of EF, but > consider that the constraint is much more severe then that of EF. With > EF the bound is on inter-packet delay and delay jitter for a single stream. > With bicasting, the bound is on the arrival delay of two copies of the > same packet that traverse different paths through N hops. The maximum > delay difference, I believe, is one packet duration, T. Thus, the delay > difference bound at each hop must roughly be T/N (the relationship is > not linear, but this gives a rough approximation). If the source of > the delay is from queuing, then this would imply that there can be > no other traffic following the same path. E.g. if a bicasted packet > arrives at an AR and is queued behind a packet that is being served > (note: served, not queued), from a different packet stream, then > it receives a delay of roughly T/2. I am very, very confused by all of this. Bicasting at the IP layer would merely result in duplicates which the transport/application layer would need to deal with. In fact, it already needs to deal with dups because IP packets are fairly regularly duplicated anyway. While it may require some specific tweaks to TCP (which I assume EIFEL attempts to provide), I see no reason why one would want to shield the receiver from this in the network, nor do I see any reason why it requires a difference in the per hop behavior in the tunneled traffic to AR new, or any consideration of number of hops, etc. The beauty of the end to end principal is that the receiver just adapts *regardless* of where the source of the jitter/loss/duplication/etc came from. Trying to deal with jitter hop-by-hop is akin to the general X.25 approach to transport which is if nothing else against the general IP philosphy of end to end transport. More pragmatically, dealing with jitter in the network will almost certainly yield a worse end to end delay as a single jitter buffer on the receiver. Mike From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 26 13:41:42 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA25021 for ; Thu, 26 Jul 2001 13:41: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 LAA24110; Thu, 26 Jul 2001 11:42: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 KAA07204; Thu, 26 Jul 2001 10:41:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6QHeDi03804 for mobile-ip-dist; Thu, 26 Jul 2001 10:40:13 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6QHeAY03797 for ; Thu, 26 Jul 2001 10:40:10 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA06879 for ; Thu, 26 Jul 2001 10:40:24 -0700 (PDT) Received: from RRMAIL01.RADIOROUTER_NT ([63.103.94.23]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA17218 for ; Thu, 26 Jul 2001 10:39:41 -0700 (PDT) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Jul 2001 13:35:10 -0400 Message-ID: <8C92E23A3E87FB479988285F9E22BE460546C9@ftmail> From: George Tsirtsis To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Handover Smoothing - What to Do? Date: Thu, 26 Jul 2001 13:35:08 -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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: -----Original Message----- From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] Sent: Thursday, July 26, 2001 6:28 PM To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Handover Smoothing - What to Do? ... Reiterating my point, this must not be part of FMIPv6. Time permitting, I will work on a separate draft for smoothing and HC and outline these issues in detail. GT> Rajeev, just to make sure I understand, do you think that bicasting should be part of FMIPv4 instead or you just do not care about it so match? Are the concerns you have IPv6 specific in any way? George From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 26 13:41:45 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA25037 for ; Thu, 26 Jul 2001 13:41:43 -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 LAA24087; Thu, 26 Jul 2001 11:42:01 -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 KAA07210; Thu, 26 Jul 2001 10:41:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6QHeRt03813 for mobile-ip-dist; Thu, 26 Jul 2001 10:40:27 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6QHeNY03806 for ; Thu, 26 Jul 2001 10:40:23 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA23977 for ; Thu, 26 Jul 2001 10:40:37 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA20116 for ; Thu, 26 Jul 2001 10:40:35 -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 KAA02172 for ; Thu, 26 Jul 2001 10:40:32 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6QHeWk17293 for ; Thu, 26 Jul 2001 10:40:32 -0700 X-mProtect: Thu, 26 Jul 2001 10:40:32 -0700 Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdPJxcxI; Thu, 26 Jul 2001 10:40:30 PDT Message-ID: <3B60560E.EA53B2F@iprg.nokia.com> Date: Thu, 26 Jul 2001 10:40:31 -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: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Handover Smoothing - What to Do? References: <200107261616.JAA22200@heliopolis.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 James, Could you be more specific ? I mentioned that the new-AR *could* do it if it got the context (e.g., via CT). But that's not it. It means dual contexts at the MN for downlink. And, synchronization issue for uplink contexts (since the MN is communicating with old-AR). Again, here is the point: these are the issues surrounding how to get bicasting to work with FMIPv6. This MUST NOT be part of FMIPv6. More generally, FMIPv6 must not depend on a particular smoothing technique. I hope you understand and agree as well! Regards, -Rajeev James Kempf wrote: > Right, having the new AR compress was what I had in mind. > > jak > > >Gary Kenward writes: > > > Rajeev: > > > > > > Is one answer that the old AR could send uncompressed packets > > > to the new AR, and the new AR would then compress the packets or > > > not, depending on whether it had the context (there is a an case > > > to be made here for proactive ct ;^}). Depending on what was actually > > > sent over the air, this could create a tricky problem to solve > > > at the MN, as it may need to process the two streams before it could > > > even attempt duplicate removal, and this would require two compression > > > state machines, buffers, etc., etc. Not nice. > > > > It may not be nice, but I believe it comes with the > > territory. The alternative is to miss packets during > > the transition that you might have otherwise been > > able to recover. For mobile initiated > > break-before-make scenarios, you obviously > > don't want to allow any otherwise valid packets > > to be dropped making the situation worse. > > > > Mike From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 26 13:49:58 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA26151 for ; Thu, 26 Jul 2001 13:49:57 -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 LAA01072; Thu, 26 Jul 2001 11:50: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 KAA09179; Thu, 26 Jul 2001 10:49:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6QHmlM03943 for mobile-ip-dist; Thu, 26 Jul 2001 10:48:47 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6QHmiY03936 for ; Thu, 26 Jul 2001 10:48:44 -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 KAA03330 for ; Thu, 26 Jul 2001 10:48:59 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA29938 for ; Thu, 26 Jul 2001 11:48:57 -0600 (MDT) 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 f6QHnBT20063 for ; Thu, 26 Jul 2001 10:49:11 -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 AAW34003; Thu, 26 Jul 2001 10:48:56 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA11115; Thu, 26 Jul 2001 10:48:56 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15200.22536.392256.3317@thomasm-u1.cisco.com> Date: Thu, 26 Jul 2001 10:48:56 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Handover Smoothing - What to Do? In-Reply-To: <3B60560E.EA53B2F@iprg.nokia.com> References: <200107261616.JAA22200@heliopolis.eng.sun.com> <3B60560E.EA53B2F@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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Rajeev Koodli writes: > James, > > Could you be more specific ? I mentioned that the new-AR *could* do it if it > got the context (e.g., via CT). But that's not it. It means dual contexts at > the MN for downlink. And, synchronization issue for uplink contexts (since > the MN is communicating with old-AR). > > Again, here is the point: these are the issues surrounding how to get > bicasting to work with FMIPv6. This MUST NOT be part of FMIPv6. More > generally, FMIPv6 must not depend on a particular smoothing technique. Well, I guess I'm glad to hear that you finally come around to agreeing that buffering shouldn't be a part of the FMIP draft either. Mike From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 26 13:55:26 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA26672 for ; Thu, 26 Jul 2001 13:55:25 -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 JAA26546; Thu, 26 Jul 2001 09:25: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 IAA12372; Thu, 26 Jul 2001 08:25:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6QFO1E02323 for mobile-ip-dist; Thu, 26 Jul 2001 08:24:01 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6QFNwY02316 for ; Thu, 26 Jul 2001 08:23:58 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA22830 for ; Thu, 26 Jul 2001 08:24:11 -0700 (PDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA24853 for ; Thu, 26 Jul 2001 08:24:10 -0700 (PDT) Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f6QFO9O01938 for ; Thu, 26 Jul 2001 17:24:09 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Thu Jul 26 17:24:06 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Jul 2001 17:24:06 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008B63@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] Some facts and motivations for bicasting Date: Thu, 26 Jul 2001 17:23:58 +0200 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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi, In order to help with the discussion and have some understanding for the motivation behind bicasting before we make a call on whether it should or should not be in the FMIPv6 draft, I'd like to put down a summary of the motivations here so people can consider these reasons. All of these were mentioned by Karim and others and you can find them also in the bicasting draft. - The FMIPv6 draft introduces the concept of anticipation. A MN gets to know about the anticipated AR (nAR) before it actually moves there. The MN sends an F-BU to direct its traffic to the nAR. - In the scenario above, it is not possible for the MN to know exactly when it will detach from the current AR. Some questions here: 1. Forwarding from oAR: When does the oAR start forwarding traffic ? As soon as it receives the BU ? If so what if the MN is still attached to it ? what if the handover fails and the MN remains attached to the current AR ? If the oAR forwards immediately to the nAR delays are introduced even if the packets are buffered at the nAR. If it waits then how long does it wait for ? Assuming that the oAR will know when the MN detaches is not acceptable. This is an L2-specific feature and is not applicable to many cases. 2. What if the MN moves to the nAR and then moves back (ping pong) ? There is no solution in the current draft for this. Bicasting solves the above two cases. Bicasting does NOT mean that the MN receives all packets twice. More info is in the draft. Concerns regarding bicasting: - TCP concerns: This is solved by Eifel. Eifel was NOT developed for bicasting but it does solve the problem. Since the request (in the case where the MN sends the BU) comes from the MN, the MN can decide whether it can request or not based on its own design decisions. - Header compression and context transfer: Bicasting has nothing to do with these issues. IF CT is needed for header compression it will be done in the right WG. There is no difference here whether you bicast or unicast. As a side note, Ralf Schmitz from NEC labs presented some test results for bicasting and TCP in IPCN conference in Paris last May. He showed that TCP performance has improved when using bicasting. Unfortunately I don't have a soft copy, but you can buy the papers if you're really interested :) http://www.upperside.fr/ipcn01/ipcn01pro.htm Finally, simultaneous bindings have been in 2002 for years now and are currently in the FMIPv4 draft. I fail to see why v6 should be any different. Regards, Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 26 13:56:58 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA26831 for ; Thu, 26 Jul 2001 13:56: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 JAA26898; Thu, 26 Jul 2001 09:26: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 IAA12460; Thu, 26 Jul 2001 08:25:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6QFOju02336 for mobile-ip-dist; Thu, 26 Jul 2001 08:24:45 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6QFOeY02328 for ; Thu, 26 Jul 2001 08:24:40 -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 IAA23022 for ; Thu, 26 Jul 2001 08:24:53 -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 JAA25632 for ; Thu, 26 Jul 2001 09:24:52 -0600 (MDT) 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 f6QFOpg08232; Thu, 26 Jul 2001 08:24:51 -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 AAW30261; Thu, 26 Jul 2001 08:24:50 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA11105; Thu, 26 Jul 2001 08:24:49 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15200.13889.764583.40195@thomasm-u1.cisco.com> Date: Thu, 26 Jul 2001 08:24:49 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Cc: Alexis , Phil Roberts , "Basavaraj Patil (NTC/Dallas)" , Abha Ahuja , Thomas Narten , Dave Johnson , Jeff Schiller , Marcus Leech , Pekka Nikander Subject: Re: [Fwd: [mobile-ip] Mobile IPv6 clarifications] In-Reply-To: <3B5F06B0.D3460EA3@iprg.nokia.com> References: <200107241727.f6OHRlS08219@thunk.east.sun.com> <3B5DEF29.CE1C831D@iprg.nokia.com> <15197.63094.198068.928185@thomasm-u1.cisco.com> <3B5F06B0.D3460EA3@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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Vijay Devarapalli writes: > Michael Thomas wrote: > > > > Ah, that's very different, and I agree it would be > > a problem with IPsec selectors. I guess I have to > > ask that _if_ that was the intention of the -13 > > draft, why. I didn't read it that way, but it's > > quite possible I didn't notice that subtlety. If > > the intention was not wanting other DO's to have > > to be protected, I guess I have to wonder why. I'm > > starting to think that Bill's suggestion of just > > setting a up coarser ID selector (ie, don't select > > based off of IP protocol) may be the right tweak > > here. > > i have already done this as an hack in my implementation. > but specifying this would be nice. Er, I think what Bill (and I) suggested didn't require a hack to IPsec at all. Ie, just set up an ID selector which doesn't filter off of the IP protocol (ie, is wildcarded.) This means that you wouldn't be able to put TCP traffic on one SPI, UDP on another, etc, but it would work without hacks. Maybe revisting Francois' UDP proposal isn't such a bad idea... Mike > > vijay > > > > > Frankly, I think that IPsec/IKE needs a face lift > > here, because this is all screwed up; MIP has the > > dubious distinction of being first to be blown up > > by this land mine left over from the v4 centric > > world. > > > > Mike > > > > > at least this is what Jeff Schiller said in his presentation > > > at the minneapolis IETF. > > > > > > if piggybacking a BU was the problem, we could have solved > > > it long back. just disallow piggybacking. anyway its a 'MAY' > > > in the current draft. you dont lose much by not piggybacking > > > the BU. > > > > > > of course, the other problem is the lack of a global PKI. > > > > > > Bill Sommerfeld wrote: > > > > > > > If I receive an AH-protected packet containing a binding update and a > > > > TCP SYN, a receiver cannot know for sure whether the sender intended > > > > the AH protection to apply just to the binding update, or also to > > > > subsequent packets that are part of the TCP connection. > > > > > > dont sent those two together, then. you dont HAVE to piggyback. > > > > > > vijay > > > > > > > While I thought this option had been beaten to death, if folks still > > > > want to use IPsec to protect MN/CN traffic, here are two possible ways > > > > to deal: > > > > > > > > 1) disallow piggybacking, and always send binding updates separately > > > > from user traffic. > > > > > > > > 2) since you've already paid the cost of setting up the IPsec > > > > security associations, you might as well just keep using them -- once > > > > a binding is established, *all* traffic between the MN and the CN > > > > should be protected the same way. > > > > > > > > Note that even with this issue resolved, you still have to deal with > > > > the PKI/authentication/etc. issues involved with SA setup; if > > > > anything, this is a much harder problem.. > > > > > > > > - Bill From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 26 13:57:45 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA26968 for ; Thu, 26 Jul 2001 13:57:44 -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 IAA22348; Thu, 26 Jul 2001 08:45: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 HAA16795; Thu, 26 Jul 2001 07:45:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6QEiG601805 for mobile-ip-dist; Thu, 26 Jul 2001 07:44:16 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6QEiDY01798 for ; Thu, 26 Jul 2001 07:44:13 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA24937 for ; Thu, 26 Jul 2001 07:44:26 -0700 (PDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA10582 for ; Thu, 26 Jul 2001 07:44:24 -0700 (PDT) Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f6QEiNO15580 for ; Thu, 26 Jul 2001 16:44:23 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Thu Jul 26 16:44:23 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Jul 2001 16:44:23 +0200 Message-ID: <795A014AF92DD21182AF0008C7A404320C52049C@esealnt117> From: "Karim El-Malki (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Handover Smoothing - What to Do? Date: Thu, 26 Jul 2001 16:44: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: > They are both receiving packets without any knowledge of what > the other > has received, or has forwarded to the MN. Might you not have > a situation > like this? I agree that there should not be the need for nFA to know what oFA has transmitted. What I'm saying is that if you bicast and (if needed) have an appropriate (jitter) buffer size at nFA then it should be possible to avoid duplicates. More below. > > At a single point in time the MN is no longer reachable from > the oFA and is > not yet reachable on the nFA. At that point in time a packet > arrives at > both > oFA and nFA and they discard the packet. The MN attaches to > the nFA but the > packet is gone. (That's in case A you describe). I would think that this is an effect of L2 (i.e. L2 handoff time) and we are mostly aiming to minimise/eliminate effects due to L3. Also what I was pointing to is that a buffer is probably needed if the handoff time from oFA to nFA is not negligible (your next case and this case). That's why packet dropping is a MAY. So this case wouldn't happen, unless of course it's not TCP and you don't care about dropping some packets. In fact low latency handoffs are probably most useful for real-time services (e.g. Voice on UDP) in which case, if there's an period of L2 disconnection during handoff, the packets should be dropped. > > Or like this? > > At a single point in time a packet arrives at the oFA and is > sent to the MN > and > at the same time arrives at the nFA and gets buffered. The > MN disconnects > and then reconnects at the nFA and gets a second copy of the packet. > (That's > in case B you describe). The buffer size should be set such that you don't get duplicates. By the time MN connects to nFA, the second copy of the packet should be dropped out of the FIFO queue/buffer and the next one should be ready for sending to MN. Of course this calculation depends on the l2 handoff characteristics and possibly the wired connectivity between the bicasting point and oFA/nFA. > > Or like this? > The same packet arrives at oFA and is transmitted to the MN > which then moves > to the > nFA and gets the same packet which was delayed on its way to the nFA. That would again need to be handled by a jitter-smoothing buffer at nFA. > > Or like this? > The MN disconnects from the oFA the packet arrives and is > dropped, then the > MN comes > back to the oFA because of radio conditions and the packet > has been lost. We could devise some temporary oFA buffer for this, but the L2 handoff failure is pretty serious so I think that it is too much to expect smooth handoffs in this case. If we can maintain L3 connectivity then I think that should be good enough. > > It seems like there is some coordination needed between the > oFA and the nFA > to > overcome these problems, perhaps a temporary tunnel? But in that case > bicasting from > an HA or a hierarchical FA wouldn't be adding much to it, > would it. Well, I think that having a local central HA would help. Say that oFA and nFA are at an equal distance from the GFA which is the aggregation router between the two. That could alleviate jitter on the fixed network, as has been already mentioned by James. Also, if oFA and nFA happen to be connected to each other through the GFA router, then bicasting at the GFA would be more efficient. >At any > rate > one would think that issues like this need some exploration > and explanation > somewhere. OK. Up to now there has been a lot of emphasis on TCP. Although I agree that it would be useful to give more detail of how bicasting + buffering works with TCP, we are also not considering the fact that a major driver for having faster handoffs at L3 was to support real-time services (over UDP). I would think that the issues above are not applicable to this case? If this is so then we should not apply these issues to bicasting/buffering in general and make that clear too. Rgds /Karim From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 26 13:57:53 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA26986 for ; Thu, 26 Jul 2001 13:57:52 -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 KAA27527; Thu, 26 Jul 2001 10:58: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 KAA11436; Thu, 26 Jul 2001 10:57:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6QHuSO04022 for mobile-ip-dist; Thu, 26 Jul 2001 10:56:28 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6QHuOY04015 for ; Thu, 26 Jul 2001 10:56:24 -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 KAA27508 for ; Thu, 26 Jul 2001 10:56:39 -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 LAA26353 for ; Thu, 26 Jul 2001 11:57: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 KAA03777 for ; Thu, 26 Jul 2001 10:54:37 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6QHsaT24767 for ; Thu, 26 Jul 2001 10:54:36 -0700 X-mProtect: Thu, 26 Jul 2001 10:54:36 -0700 Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdoYwnkW; Thu, 26 Jul 2001 10:54:32 PDT Message-ID: <3B605958.60198216@iprg.nokia.com> Date: Thu, 26 Jul 2001 10:54:32 -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: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Handover Smoothing - What to Do? References: <8C92E23A3E87FB479988285F9E22BE460546C9@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, George Tsirtsis wrote: > -----Original Message----- > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > Sent: Thursday, July 26, 2001 6:28 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Handover Smoothing - What to Do? > > ... > Reiterating my point, this must not be part of FMIPv6. Time permitting, > I will work on a separate draft for smoothing and HC and outline these > issues in detail. > > GT> Rajeev, just to make sure I understand, do you think that bicasting > should be part of FMIPv4 instead or you just do not care about it so match? > Are the concerns you have IPv6 specific in any way? > Rajeev: My personal opinion (without having participated in the design team discussion!) is that any fast handover protocol must be able to work without having to rely on a particular smoothing technique. This is especially important when practical experience is absent. We are working on FMIPv6 implementation and we hope to be able to shed some light (on smoothing) in due course of time. Hope this helps. Regards, -Rajeev > > George From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 26 13:58:11 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA27029 for ; Thu, 26 Jul 2001 13:58:10 -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 HAA10413; Thu, 26 Jul 2001 07:46: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 GAA08390; Thu, 26 Jul 2001 06:46:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6QDilT01419 for mobile-ip-dist; Thu, 26 Jul 2001 06:44:47 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6QDihY01412 for ; Thu, 26 Jul 2001 06:44:43 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA08197 for ; Thu, 26 Jul 2001 06:44:58 -0700 (PDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA11935 for ; Thu, 26 Jul 2001 06:44:58 -0700 (PDT) Received: from mira-sjc5-9.cisco.com (mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f6QDj7328106 for ; Thu, 26 Jul 2001 06:45:07 -0700 (PDT) Received: from MRAMALHO-W2K1.cisco.com (sjc-vpn-257.cisco.com [10.21.65.1]) by mira-sjc5-9.cisco.com (Mirapoint) with ESMTP id AAP31511; Thu, 26 Jul 2001 06:44:56 -0700 (PDT) Message-Id: <4.3.2.7.2.20010726091810.00b69768@mira-sjc5-9.cisco.com> X-Sender: mramalho@mira-sjc5-9.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 26 Jul 2001 09:43:57 -0400 To: mobile-ip@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com From: "Michael A. Ramalho" Subject: Re: [mobile-ip] Analysis of Jitter in Bicasting In-Reply-To: <200107252215.PAA20351@heliopolis.eng.sun.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: Comments in line .. Michael Ramalho At 03:15 PM 7/25/2001 -0700, James Kempf wrote: >Vijay, > > >> > >> Um, so what happens to the real time packets while the FBACK is getting > >> buffered? And how do you know that the FBACK will arrive and should > >> be buffered exactly during L2 handover? It could arrive before, it > >> could arrive after. What about the rest (minimum 4 at my count) > >> packets involved in FMIP handover before the MN gets to start > >> doing DAD (over the air), etc., on the new AR before it can > >> start getting its real time traffic? > > > >i lost you. it doesnt matter when the FBack arrives at the newAR, > >the newAR has to buffer it till the MN shows up. the newAR doesnt > >know if the MN got the FBack while it was still attached to the > >oldAR. > > > >What I'm saying is that if there is more than a 300 ms gap in >a real time voice stream, the user notices a click. If the gap >propagates forward, so that there is more than a 300 ms delay >in the real time traffic, then the conversation begins to >sound like half duplex. Jim, I noticed this 300 ms assumption in your draft. However, you will probably notice a pop/click long before 300 ms (assuming there is coded voice/music coming toward you during this time). This depends on the error concealment algorithms in the codec for lost/delayed packets. For example, depending on if you were in the middle of a long voiced vowel - which is more forgiving - or short duration/energy fricative or plosive - like a "b" or "p" - which becomes completely lost in the lost packet. Thus sixty ms of loss in the middle of a vowel can be easily concealed (six G.729 frames - usually three packets worth), whereas the same time loss during a low energy fricative is completely lost. Then you say ... what did you say? ... unless you have good word interpolation skills. The bottom line is that if the jitter buffer gets a packet after its playback time ... it is lost for the purposes of meaningful playback (I think Phil tried to bring this point out a few days ago). Having good heuristics for the buffer management in this environment is very important (Mike Thomas brought out this point a few days ago as well). The "worse case" 300 ms ITU number was an end-to-end number for delay budgeting - not an "additive jitter before delays become noticeable" number. In that sense, you misrepresented its meaning. After 300 ms of one way delay ... interactive communications becomes almost impossible (becomes increasingly toward a half-duplex conversation). A satellite connection has a minimum of 512 ms round trip delay - which is half-duplex for me. Fortunately ... most of the coding is non-speech (e.g., silence/background noise) and most of the "remaining real speech" is voiced ... so we have some statistics working for us during handoff additive delays. Lets just get the handoff/tunnels up as fast as we can .... Michael Ramalho >The number I gave of 112.5 ms is the maximum amount time on a 9.6 kbps >uplink that buffering can be done before the 300 ms bound is exceeded. >For the scenarios calculated in Appendix A of draft-kempf-beth-ipv6-01.txt, >which I think are about the minimum traffic for an FMIPv6 handover >(somebody please correct me if I am wrong), the minimum L3 handover time >is 133 >ms. This already exceeds the buffering bound. > >The FBACK isn't strictly necessary for the MN to start getting >real time traffic right away after handover (and, frankly, that >is really all that counts if you want the user not to notice). The >FBACK is only necessary to complete new CoA aquisition. The MN >can get its real time traffic through a tunnel from the old AR >using its old CoA then finish new CoA aquisition whenever. That is what >draft-kempf-beth-ipv6-01.txt advocates, and it is envisioned in >draft-ietf-mobileip-fast-mipv6-01.txt as a corner case. > >So if you want to buffer and you've got real time traffic, your choices are: > > 1) Use FMIPv6 handover and crank the uplink data rate up until you can > download > the buffer fast enough over the air from the new AR to not have the latency > propogate. > > 2) Use BETH handover if the L2 handover time is less than 112.5 ms (for > a 9.6 kbps downlink data rate). > >Otherwise, if L2 handover is too large for 2) or you can't crank the >data rate, you are better off dropping the packets. > > jak Michael A. Ramalho, Ph.D. Office email: mramalho@cisco.com Personal email: mar42@cornell.edu Summer Office: +1.941.923.1203 (July/Aug 2001) Office: +1.732.449.5762 Cell: +1.732.809.0188 From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 26 13:58:12 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA27038 for ; Thu, 26 Jul 2001 13:58: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 JAA15453; Thu, 26 Jul 2001 09:12:37 -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 IAA08454; Thu, 26 Jul 2001 08:12:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6QFBHp02158 for mobile-ip-dist; Thu, 26 Jul 2001 08:11:17 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6QFBEY02151 for ; Thu, 26 Jul 2001 08:11:14 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA08161 for ; Thu, 26 Jul 2001 08:11:27 -0700 (PDT) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA18190 for ; Thu, 26 Jul 2001 08:11:27 -0700 (PDT) Received: by megisto-sql1.megisto.com with Internet Mail Service (5.5.2650.21) id ; Thu, 26 Jul 2001 11:09:51 -0400 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Handover Smoothing - What to Do? Date: Thu, 26 Jul 2001 11:09:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) 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: Well, I don't buy a lot of your response below, but notwithstanding that, some documentation of how these cases are handled needs to be made so it's available for scrutiny. It seems that it should discuss the sizes of these buffers and the criteria for determining when to forward and when to drop packets, and what bicasting doesn't do for you. Perhaps some guidance on how the agents involved in the implementation distinguish between and handle different types of traffic should be included, because although the proposals are intended to help in the case of realtime traffic, the implementation agents unless otherwise informed are subject to the effects of implementing the protocols for all traffic? > -----Original Message----- > From: Karim El-Malki (ERA) [mailto:Karim.El-Malki@era.ericsson.se] > Sent: Thursday, July 26, 2001 10:44 AM > To: 'mobile-ip@sunroof.eng.sun.com' > Subject: RE: [mobile-ip] Handover Smoothing - What to Do? > > > > They are both receiving packets without any knowledge of what > > the other > > has received, or has forwarded to the MN. Might you not have > > a situation > > like this? > > I agree that there should not be the need for nFA to know what > oFA has transmitted. What I'm saying is that if you bicast and > (if needed) have an appropriate (jitter) buffer size at nFA then > it should be possible to avoid duplicates. More below. > > > > > At a single point in time the MN is no longer reachable from > > the oFA and is > > not yet reachable on the nFA. At that point in time a packet > > arrives at > > both > > oFA and nFA and they discard the packet. The MN attaches to > > the nFA but the > > packet is gone. (That's in case A you describe). > > I would think that this is an effect of L2 (i.e. L2 handoff time) > and we are mostly aiming to minimise/eliminate effects due to L3. > Also what I was pointing to is that a buffer is probably needed > if the handoff time from oFA to nFA is not negligible (your next > case and this case). That's why packet dropping is a MAY. So this > case wouldn't happen, unless of course it's not TCP and you don't > care about dropping some packets. In fact low latency handoffs are > probably most useful for real-time services (e.g. Voice on UDP) > in which case, if there's an period of L2 disconnection during > handoff, the packets should be dropped. > > > > > Or like this? > > > > At a single point in time a packet arrives at the oFA and is > > sent to the MN > > and > > at the same time arrives at the nFA and gets buffered. The > > MN disconnects > > and then reconnects at the nFA and gets a second copy of the packet. > > (That's > > in case B you describe). > > The buffer size should be set such that you don't get duplicates. > By the time MN connects to nFA, the second copy of the packet > should be dropped out of the FIFO queue/buffer and the next one > should be ready for sending to MN. Of course this calculation > depends on the l2 handoff characteristics and possibly the wired > connectivity between the bicasting point and oFA/nFA. > > > > > Or like this? > > The same packet arrives at oFA and is transmitted to the MN > > which then moves > > to the > > nFA and gets the same packet which was delayed on its way > to the nFA. > > That would again need to be handled by a jitter-smoothing > buffer at nFA. > > > > > Or like this? > > The MN disconnects from the oFA the packet arrives and is > > dropped, then the > > MN comes > > back to the oFA because of radio conditions and the packet > > has been lost. > > We could devise some temporary oFA buffer for this, but the L2 > handoff failure is pretty serious so I think that it is > too much to expect smooth handoffs in this case. If we can > maintain L3 connectivity then I think that should be good enough. > > > > > It seems like there is some coordination needed between the > > oFA and the nFA > > to > > overcome these problems, perhaps a temporary tunnel? But > in that case > > bicasting from > > an HA or a hierarchical FA wouldn't be adding much to it, > > would it. > > Well, I think that having a local central HA would help. > Say that oFA and nFA are at an equal distance from the GFA > which is the aggregation router between the two. That could > alleviate jitter on the fixed network, as has been already > mentioned by James. Also, if oFA and nFA happen to be connected > to each other through the GFA router, then bicasting at the > GFA would be more efficient. > > >At any > > rate > > one would think that issues like this need some exploration > > and explanation > > somewhere. > > OK. Up to now there has been a lot of emphasis on TCP. Although I > agree that it would be useful to give more detail of how bicasting > + buffering works with TCP, we are also not considering the fact that > a major driver for having faster handoffs at L3 was to support > real-time services (over UDP). I would think that the issues above are > not applicable to this case? If this is so then we should not apply > these issues to bicasting/buffering in general and make that > clear too. > > Rgds > /Karim > From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 26 13:59:02 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA27143 for ; Thu, 26 Jul 2001 13:59:01 -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 IAA01738; Thu, 26 Jul 2001 08:56: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 HAA03672; Thu, 26 Jul 2001 07:56:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6QEt1W01959 for mobile-ip-dist; Thu, 26 Jul 2001 07:55:01 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6QEswY01952 for ; Thu, 26 Jul 2001 07:54:58 -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 HAA27425 for ; Thu, 26 Jul 2001 07:55:11 -0700 (PDT) Received: from zcars0m9.ca.nortel.com ([47.129.242.157]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA06993 for ; Thu, 26 Jul 2001 08:56:37 -0600 (MDT) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f6QEsm918137 for ; Thu, 26 Jul 2001 10:54:48 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Thu, 26 Jul 2001 10:54:43 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Jul 2001 10:54:47 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5E8E@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Handover Smoothing - What to Do? Date: Thu, 26 Jul 2001 10:54:49 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C115E2.EAF8A340" X-Orig: 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_01C115E2.EAF8A340 Content-Type: text/plain; charset="iso-8859-1" Rajeev: Reading this email from you, I now understand better what you meant by "many-to-one" mode. My first response was talking about doing "many-to-one" above or after ROHC. I believe you are referring to performing the combining of the two streams within ROHC - a very powerful idea, given that the information from the two separate streams could be used to improve robustness. However, the complexities of this approach do scare me, and I would think that the algorithm would need much more research. In the meantime, combining (or selecting) above ROHC would work, at the expense of running two independent ROHC decompressors at the MN (and probably two ROHC compressors for the traffic from MN to old and new AR respectively). Comments? Gary > -----Original Message----- > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > Sent: July 25, 2001 19:18 > To: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Handover Smoothing - What to Do? > > > Hello Phil, > > > Phil Roberts wrote: > [snip] > > > > > I wouldn't call it a procedural issue but a need to make a > decision. I > > (personally) > > would like to make a consensus call on both FMIPv4 and > FMIPv6 right after > > London and I don't want to send up drafts one with and one > without an option > > for smoothing. So our consensus calls will probably be > something like 1) do > > we want smoothing in a separate draft and if so, 2) is > FMIPv6 ready for last > > call and is FMIPv4 ready for last call after we remove the > smoothing bits; > > and > > if not 3) is FMIPv4 read for last call and FMIPv6 ready for > last call after > > we add the smoothing bits. > > > > Right now it seems that George at least is uncomfortable with making > > smoothing an essential part > > of the FMIP draft. Hesham at least is uncomfortable with > progressing the > > FMIP draft without smoothing. Hesham's position excludes > the middle ground > > of putting smoothing into a separate draft. As an aside it > seems clear that > > smoothing is an optional feature in the FMIPv4 draft but > I'm not sure > > whether > > the proposal is to make it optional when incorporated in FMIPv6. > > > > There does seem to be some consensus that if a smoothing > technique is chosen > > it should be through bicasting or simultaneous binding > rather than some kind > > of > > buffering. At the minimum we should have a discussion of > why the tradeoff > > of > > accepting the possibility of duplicate packets weighs more > heavily than > > accepting > > the possibility of lost packets and the results should be > documented. > > > > I would like to mention the issue surrounding header > compression and bicasting. > I posted a separate e-mail on this topic BTW. The problem is > what type of a > packet does the old-AR bicast ? If it is uncompressed, then > the new-AR needs > compression context to forward the compressed packet to the > MN. Unfortunately, > this means support for Many-to-One mode of header compression > (the two ARs to > the MN) which to my knowledge has not been defined. Thanks > [rohc]! If the > old-AR bicasts a compressed packet to the new-AR, how does > the new-AR forward > that packet ? > In the uplink, only the old-AR would have the up-to-date context. This > introduces synchronization issues even when the new-AR may > concurrently possess > the header compression state. > > So, it is perhaps premature to state that there is consensus. > I think bicasting > must not be coupled to FMIPv6. It could ofcourse be a separate draft. > > My two cents.. > > -Rajeev > > > > > > George has also asserted (and speaking for myself > personally I also agree > > with) > > that implementations in some environments at least can > solve this without > > any kind > > of protocol support at layer 3. > > > > Does this seem to summarize everyone's position accurately? > Does this > > answer your question > > enough, Jim? > > > > Of course, others contributing to the conversation COULD help, > > Phil > > > > ------_=_NextPart_001_01C115E2.EAF8A340 Content-Type: text/html; charset="iso-8859-1" RE: [mobile-ip] Handover Smoothing - What to Do?

Rajeev:

  Reading this email from you, I now understand better what you
meant by "many-to-one" mode. My first response was talking about
doing "many-to-one" above or after ROHC. I believe you are referring
to performing the combining of the two streams within ROHC - a
very powerful idea, given that the information from the two separate
streams could be used to improve robustness. However, the complexities
of this approach do scare me, and I would think that the algorithm
would need much more research.

  In the meantime, combining (or selecting) above ROHC would work,
at the expense of running two independent ROHC decompressors at the MN
(and probably two ROHC compressors for the traffic from MN to old and
new AR respectively).

  Comments?

Gary

> -----Original Message-----
> From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com]
> Sent: July 25, 2001 19:18
> To: mobile-ip@sunroof.eng.sun.com
> Subject: Re: [mobile-ip] Handover Smoothing - What to Do?
>
>
> Hello Phil,
>
>
> Phil Roberts wrote:
> [snip]
>
> >
> > I wouldn't call it a procedural issue but a need to make a
> decision.  I
> > (personally)
> > would like to make a consensus call on both FMIPv4 and
> FMIPv6 right after
> > London and I don't want to send up drafts one with and one
> without an option
> > for smoothing.  So our consensus calls will probably be
> something like 1) do
> > we want smoothing in a separate draft and if so, 2) is
> FMIPv6 ready for last
> > call and is FMIPv4 ready for last call after we remove the
> smoothing bits;
> > and
> > if not 3) is FMIPv4 read for last call and FMIPv6 ready for
> last call after
> > we add the smoothing bits.
> >
> > Right now it seems that George at least is uncomfortable with making
> > smoothing an essential part
> > of the FMIP draft.  Hesham at least is uncomfortable with
> progressing the
> > FMIP draft without smoothing.  Hesham's position excludes
> the middle ground
> > of putting smoothing into a separate draft.  As an aside it
> seems clear that
> > smoothing is an optional feature in the FMIPv4 draft but
> I'm not sure
> > whether
> > the proposal is to make it optional when incorporated in FMIPv6.
> >
> > There does seem to be some consensus that if a smoothing
> technique is chosen
> > it should be through bicasting or simultaneous binding
> rather than some kind
> > of
> > buffering.  At the minimum we should have a discussion of
> why the tradeoff
> > of
> > accepting the possibility of duplicate packets weighs more
> heavily than
> > accepting
> > the possibility of lost packets and the results should be
> documented.
> >
>
> I would like to mention the issue surrounding header
> compression and bicasting.
> I posted a separate e-mail on this topic BTW. The problem is
> what type of a
> packet does the old-AR bicast ? If it is uncompressed, then
> the new-AR needs
> compression context to forward the compressed packet to the
> MN. Unfortunately,
> this means support for Many-to-One mode of header compression
> (the two ARs to
> the MN) which to my knowledge has not been defined. Thanks
> [rohc]! If the
> old-AR bicasts a compressed packet to the new-AR, how does
> the new-AR forward
> that packet ?
> In the uplink, only the old-AR would have the up-to-date context. This
> introduces synchronization issues even when the new-AR may
> concurrently possess
> the header compression state.
>
> So, it is perhaps premature to state that there is consensus.
> I think bicasting
> must not be coupled to FMIPv6. It could ofcourse be a separate draft.
>
> My two cents..
>
> -Rajeev
>
>
> >
> > George has also asserted (and speaking for myself
> personally I also agree
> > with)
> > that implementations in some environments at least can
> solve this without
> > any kind
> > of protocol support at layer 3.
> >
> > Does this seem to summarize everyone's position accurately?
>  Does this
> > answer your question
> > enough, Jim?
> >
> > Of course, others contributing to the conversation COULD help,
> > Phil
> >
>
>

------_=_NextPart_001_01C115E2.EAF8A340-- From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 26 14:01:04 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA27391 for ; Thu, 26 Jul 2001 14:01:04 -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 IAA18482; Thu, 26 Jul 2001 08:41:15 -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 HAA16185; Thu, 26 Jul 2001 07:41:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6QEdsk01743 for mobile-ip-dist; Thu, 26 Jul 2001 07:39:54 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6QEdpY01736 for ; Thu, 26 Jul 2001 07:39:51 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA15892 for ; Thu, 26 Jul 2001 07:40:04 -0700 (PDT) Received: from zcars0m9.ca.nortel.com ([47.129.242.157]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA08538 for ; Thu, 26 Jul 2001 07:40:01 -0700 (PDT) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f6QEdd915549 for ; Thu, 26 Jul 2001 10:39:39 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Thu, 26 Jul 2001 10:39:31 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Jul 2001 10:39:35 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5E8C@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Analysis of Jitter in Bicasting Date: Thu, 26 Jul 2001 10:39:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C115E0.CAFEAC30" X-Orig: 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_01C115E0.CAFEAC30 Content-Type: text/plain; charset="iso-8859-1" James: Just a quick follow-up on this thread: you mentioned in one of your emails that the latency tolerance for conversational voice to be around 112.5 ms. It is my understanding that the latency bounds for reasonable quality voice conversations (for an MOS somewhere between 3 and 4), is around 250 ms round trip. Assuming symmetry, the implication is that the one way, end to end delay should be less then approximately 125ms end to end. If the end to end service is VoIP, then this 125 ms budget must be applied to all the IP networks along the path - typically, an access network, one or more transit networks and another access network. So, I wonder if there really is 112.5 ms to buffer packets, or anywhere near that amount, particularly given the fact that the current generation of radio link protocols seem to consume 10s of ms simply for packet access (I'm alluding here to VoIP over the air, not VoIP converted to 3G voice service). One rule of thumb I've always held to with packetized voice is that if you have to delay the packet by more then the vocoder delay (e.g. 20 ms for G.729), then you might as well drop the packet. If you start dropping sequentially packets - e.g. 2 or 3 consecutive voice frames, the drops will be audible to the user. It is my perception that the standard for voice service in cellular systems during handoffs is not as stringent. However, this would not be the "seamless handoff" that has been talked about. Anyway, the question I want to raise is whether there is really a 112.5 ms delay budget available at the AR for handover, or whether the number is actually much smaller. Some of the work I have seen suggests that the bound is more around 40 ms, for the whole access network. This is roughly two VoIP packets, for a scenario with one 20 ms G.729 voice frame per IP packet. Do you, or anyone else have any additional information? If we are talking about buffering vs. bicasting, this delay bound *is* very important. Gary > -----Original Message----- > From: James Kempf [mailto:James.Kempf@Sun.COM] > Sent: July 25, 2001 17:26 > To: mobile-ip@sunroof.eng.sun.com > Subject: RE: [mobile-ip] Analysis of Jitter in Bicasting > > > Gary, > > >This problem are not strictly a problem with bicasting. If > the MN doesn't > >receive x+2 on the old L2 because of poor radio channel > conditions, the > >same problem occurs with both re-routed and tunnelled > approaches - namely, > >how does the handover solution know that x+2 has been lost, > and how does > >it reinsert x+2? > > > >There are methods that can be used to address this problem > with bicast, that > >I suspect > >are simpler then the other approaches (but someone may have a better > >approach). > >It involves purposely off-setting the stream at new AR from > old L2. The > >offset > >should be equal to the number of possible packet losses > (hopefully, no more > >then 1 packet). This introduces duplicates as a result > (possibly with every > >handover), but a duplicate is easier to recover from then a loss, > >particularly > >when the duplicates are received within one or two packet durations. > > > > This is sort of what I had in mind, but there are problems with > inserting a jitter buffer, as PhilN and MikeT have pointed out. > > > > >Well, it takes more then over provisioning. You need to ensure > >the same number of hops between the bicasting source (the traffic > >bifurcation > >point if you will), and you also need to provide some > guaranteed bounds on > >the delay at each hop after the bicasting source. *if* you > want to ensure no > >duplicates > >at all at the receiver. This may seem like a definition of EF, but > >consider that the constraint is much more severe then that > of EF. With > >EF the bound is on inter-packet delay and delay jitter for a > single stream. > >With bicasting, the bound is on the arrival delay of two > copies of the > >same packet that traverse different paths through N hops. The maximum > >delay difference, I believe, is one packet duration, T. > Thus, the delay > >difference bound at each hop must roughly be T/N (the relationship is > >not linear, but this gives a rough approximation). If the source of > >the delay is from queuing, then this would imply that there can be > >no other traffic following the same path. E.g. if a bicasted packet > >arrives at an AR and is queued behind a packet that is being served > >(note: served, not queued), from a different packet stream, then > >it receives a delay of roughly T/2. > > > >One obvious approach to this delay problem is to have only one hop > >after the bicasting source - the AR itself. This would seem to > >impose serious constraints on the network engineering, and I believe > >would pose serious handover problems between bicasting sources. > > > > > Good points. Network engineering solutions along the lines you mention > are probably unrealistic. People want to have more choices in the > way they configure their access networks, not less. > > > > >You have covered a lot. I think the bottom line is that if you > >want to use bicasting, and avoid all duplicates at the receiver, you > >have to synchronize the traffic flows very carefully, which > contradicts > >the principle of a hop-by-hop IP forwarding network. > > > >The other idea is to consider the impact of duplicates, and look for > >reasonable comprimise between delay/loss compensation and duplicate > >removal over one to two packet durations. > > > > IP really isn't designed for isochronous types of situations, with > these kinds of tight timing constraints (though it does suprisingly > well if you are willing to allow L2 to take care of the > synchronization > for you). > > I think that the option of switching on an edge tunnel to new > AR after the MN > disappears probably would work better than bicasting, if you can > fine tune things. If you can't, then you are left with having to > either bicast or buffer or neither to smooth, none of which are > particularly good. > > jak > > ------_=_NextPart_001_01C115E0.CAFEAC30 Content-Type: text/html; charset="iso-8859-1" RE: [mobile-ip] Analysis of Jitter in Bicasting

James:

  Just a quick follow-up on this thread: you mentioned in one of
your emails that the latency tolerance for conversational voice to
be around 112.5 ms. It is my understanding that the latency bounds for
reasonable quality voice conversations (for an MOS somewhere between
3 and 4), is around 250 ms round trip. Assuming symmetry, the implication
is that the one way, end to end delay should be less then approximately
125ms end to end.

  If the end to end service is VoIP, then this 125 ms budget must be
applied to all the IP networks along the path - typically, an access
network, one or more transit networks and another access network. So,
I wonder if there really is 112.5 ms to buffer packets, or anywhere near
that amount, particularly given the fact that the current generation of
radio link protocols seem to consume 10s of ms simply for packet
access (I'm alluding here to VoIP over the air, not VoIP converted to
3G voice service).

   One rule of thumb I've always held to with packetized voice is that
if you have to delay the packet by more then the vocoder delay (e.g. 20 ms
for G.729), then you might as well drop the packet. If you start dropping
sequentially packets - e.g. 2 or 3 consecutive voice frames, the drops will
be audible to the user.

   It is my perception that the standard for voice service in cellular systems
during handoffs is not as stringent. However, this would not be the "seamless
handoff" that has been talked about.

   Anyway, the question I want to raise is whether there is really a 112.5 ms
delay budget available at the AR for handover, or whether the number is actually
much smaller. Some of the work I have seen suggests that the bound is more
around 40 ms, for the whole access network. This is roughly two VoIP packets,
for a scenario with one 20 ms G.729 voice frame per IP packet.

Do you, or anyone else have any additional information? If we are talking about
buffering vs. bicasting, this delay bound *is* very important.

Gary

> -----Original Message-----
> From: James Kempf [mailto:James.Kempf@Sun.COM]
> Sent: July 25, 2001 17:26
> To: mobile-ip@sunroof.eng.sun.com
> Subject: RE: [mobile-ip] Analysis of Jitter in Bicasting
>
>
> Gary,
>
> >This problem are not strictly a problem with bicasting. If
> the MN doesn't
> >receive x+2 on the old L2 because of poor radio channel
> conditions, the
> >same problem occurs with both re-routed and tunnelled
> approaches - namely,
> >how does the handover solution know that x+2 has been lost,
> and how does
> >it reinsert x+2?
> >
> >There are methods that can be used to address this problem
> with bicast, that
> >I suspect
> >are simpler then the other approaches (but someone may have a better
> >approach).
> >It involves purposely off-setting the stream at new AR from
> old L2. The
> >offset
> >should be equal to the number of possible packet losses
> (hopefully, no more
> >then 1 packet). This introduces duplicates as a result
> (possibly with every
> >handover), but a duplicate is easier to recover from then a loss,
> >particularly
> >when the duplicates are received within one or two packet durations.
> >
>
> This is sort of what I had in mind, but there are problems with
> inserting a jitter buffer, as PhilN and MikeT have pointed out.
>
> >
> >Well, it takes more then over provisioning. You need to ensure
> >the same number of hops between the bicasting source (the traffic
> >bifurcation
> >point if you will), and you also need to provide some
> guaranteed bounds on
> >the delay at each hop after the bicasting source. *if* you
> want to ensure no
> >duplicates
> >at all at the receiver. This may seem like a definition of EF, but
> >consider that the constraint is much more severe then that
> of EF. With
> >EF the bound is on inter-packet delay and delay jitter for a
> single stream.
> >With bicasting, the bound is on the arrival delay of two
> copies of the
> >same packet that traverse different paths through N hops. The maximum
> >delay difference, I believe, is one packet duration, T.
> Thus, the delay
> >difference bound at each hop must roughly be T/N (the relationship is
> >not linear, but this gives a rough approximation). If the source of
> >the delay is from queuing, then this would imply that there can be
> >no other traffic following the same path. E.g. if a bicasted packet
> >arrives at an AR and is queued behind a packet that is being served
> >(note: served, not queued), from a different packet stream, then
> >it receives a delay of roughly T/2.
> >
> >One obvious approach to this delay problem is to have only one hop
> >after the bicasting source - the AR itself. This would seem to
> >impose serious constraints on the network engineering, and I believe
> >would pose serious handover problems between bicasting sources.
> >
>
>
> Good points. Network engineering solutions along the lines you mention
> are probably  unrealistic. People want to have more choices in the
> way  they configure their access networks, not less.
>
> >
> >You have covered a lot. I  think the bottom line is that if you
> >want to use bicasting, and avoid all duplicates at the receiver, you
> >have to synchronize the traffic flows very carefully, which
> contradicts
> >the principle of a hop-by-hop IP forwarding network.
> >
> >The other idea is to consider the impact of duplicates, and look for
> >reasonable comprimise between delay/loss compensation and duplicate
> >removal over one to two packet durations.
> >
>
> IP really isn't designed for isochronous types of situations, with
> these kinds of tight timing constraints (though it does suprisingly
> well if you are willing to allow L2 to take care of the
> synchronization
> for you).
>
> I think that the option of switching on an edge tunnel to new
> AR after the MN
> disappears probably would work better than bicasting, if you can
> fine tune things. If you can't, then you are left with having to
> either bicast or buffer or neither to smooth, none of which are
> particularly good.
>
>               jak
>
>

------_=_NextPart_001_01C115E0.CAFEAC30-- From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 26 14:02:45 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA27592 for ; Thu, 26 Jul 2001 14:02:45 -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 JAA07453; Thu, 26 Jul 2001 09:18:04 -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 JAA16351; Thu, 26 Jul 2001 09:17:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6QGGl502782 for mobile-ip-dist; Thu, 26 Jul 2001 09:16:47 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6QGGhY02775 for ; Thu, 26 Jul 2001 09:16:43 -0700 (PDT) Received: from heliopolis.Eng.Sun.COM (eastapp2.East.Sun.COM [129.148.162.99]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA22200; Thu, 26 Jul 2001 09:16:33 -0700 (PDT) From: James Kempf Message-Id: <200107261616.JAA22200@heliopolis.eng.sun.com> Date: Thu, 26 Jul 2001 09:12:56 -0700 To: , Subject: RE: [mobile-ip] Handover Smoothing - What to Do? X-Mailer: Sun NetMail 2.3 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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Right, having the new AR compress was what I had in mind. jak >Gary Kenward writes: > > Rajeev: > > > > Is one answer that the old AR could send uncompressed packets > > to the new AR, and the new AR would then compress the packets or > > not, depending on whether it had the context (there is a an case > > to be made here for proactive ct ;^}). Depending on what was actually > > sent over the air, this could create a tricky problem to solve > > at the MN, as it may need to process the two streams before it could > > even attempt duplicate removal, and this would require two compression > > state machines, buffers, etc., etc. Not nice. > > It may not be nice, but I believe it comes with the > territory. The alternative is to miss packets during > the transition that you might have otherwise been > able to recover. For mobile initiated > break-before-make scenarios, you obviously > don't want to allow any otherwise valid packets > to be dropped making the situation worse. > > Mike From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 26 14:02:52 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA27612 for ; Thu, 26 Jul 2001 14:02:51 -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 MAA11409; Thu, 26 Jul 2001 12:02: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 LAA12850; Thu, 26 Jul 2001 11:02:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6QI1FG04092 for mobile-ip-dist; Thu, 26 Jul 2001 11:01:15 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6QI1BY04085 for ; Thu, 26 Jul 2001 11:01:11 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA28655 for ; Thu, 26 Jul 2001 11:01:26 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA15364 for ; Thu, 26 Jul 2001 11:01: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 LAA04750 for ; Thu, 26 Jul 2001 11:01:25 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6QI1P413183 for ; Thu, 26 Jul 2001 11:01:25 -0700 X-mProtect: Thu, 26 Jul 2001 11:01:25 -0700 Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdLVNyOo; Thu, 26 Jul 2001 11:01:14 PDT Message-ID: <3B605AEA.F460072@iprg.nokia.com> Date: Thu, 26 Jul 2001 11:01:14 -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: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Handover Smoothing - What to Do? References: <200107261616.JAA22200@heliopolis.eng.sun.com> <3B60560E.EA53B2F@iprg.nokia.com> <15200.22536.392256.3317@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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Michael Thomas wrote: > Rajeev Koodli writes: > > James, > > > > Could you be more specific ? I mentioned that the new-AR *could* do it if it > > got the context (e.g., via CT). But that's not it. It means dual contexts at > > the MN for downlink. And, synchronization issue for uplink contexts (since > > the MN is communicating with old-AR). > > > > Again, here is the point: these are the issues surrounding how to get > > bicasting to work with FMIPv6. This MUST NOT be part of FMIPv6. More > > generally, FMIPv6 must not depend on a particular smoothing technique. > > Well, I guess I'm glad to hear that you finally come > around to agreeing that buffering shouldn't be a part > of the FMIP draft either. > Interesting statement.. Not that I agree with its formulation! FYI, buffering is optional in FMIPv6. -Rajeev > > Mike From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 26 14:02:55 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA27632 for ; Thu, 26 Jul 2001 14:02:54 -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 IAA19483; Thu, 26 Jul 2001 08:41: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 IAA06598; Thu, 26 Jul 2001 08:41:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6QFe0302552 for mobile-ip-dist; Thu, 26 Jul 2001 08:40:00 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6QFduY02545 for ; Thu, 26 Jul 2001 08:39:57 -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 IAA26218 for ; Thu, 26 Jul 2001 08:40:09 -0700 (PDT) Received: from sonne.darmstadt.gmd.de (sonne.darmstadt.gmd.de [141.12.62.20]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA04364 for ; Thu, 26 Jul 2001 09:41:33 -0600 (MDT) Received: from ipsi.fraunhofer.de (pc-morion [141.12.35.155]) by sonne.darmstadt.gmd.de (8.8.8/8.8.5) with ESMTP id RAA17927; Thu, 26 Jul 2001 17:40:02 +0200 (MET DST) Message-ID: <3B603ACD.52AF3AA1@ipsi.fraunhofer.de> Date: Thu, 26 Jul 2001 17:44:13 +0200 From: Wolfgang Schoenfeld Organization: FhG IPSI X-Mailer: Mozilla 4.7 [de] (WinNT; I) X-Accept-Language: en,de MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] WG feedback on bicasting References: <200107241709.KAA13051@heliopolis.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 James Kempf schrieb: > > Wolfgang, > > Most of these problems go away if bicasting is done between oFA/oAR > and nFA/nAR. This is what I meant with "to by-pass registration message or data packets" travelling on the "standard" path oFA - HA - nFA via some direct link (or tunnel) oFA - nFA. > > The exchange of L3 handover messages across the wired backbone > (HI/HACK) is a coarse approximation of when the link changes. > The oAR continues to send packets down the old L2 until the > L2 disappears. Presumably it can detect this somehow. It starts bicasting to nAR > when it sends/receives a HACK. > > This can be fine tuned considerably if appropriate sequencing > information is available from L2 (see draft-manyfolks-mobilereq-l2-00.txt > for the kinds of sequencing information that can help). Have to go into that... Wolfgang > > jak > > >Date: Tue, 24 Jul 2001 17:43:40 +0200 > >From: Wolfgang Schoenfeld > >To: mobile-ip@sunroof.eng.sun.com > >Subject: Re: [mobile-ip] WG feedback on bicasting > > > >Hello Karim, > > > >may I just restate my considerations > >which had - I admid - a few flaws? > > > >Assume again that a stream of packets > >is running from CN to MN via oFA (or oAR or ...). > >When MN moves, some redirection of the stream may be necessary > >(which is done by registration at the HA). > >Which events can trigger that? > > > >The emergence of a new link between MN and some nFA is a good candidate > >since the stream can use it (as long as it is stable). > >And this is what MIP does. > >However, to propagate the event to HA takes some time > >during which packets keep on running to oFA. > >And after redirection is done, > >packets take some time to reach MN. > >Hence, the round-trip time from MN to HA > >determines handoff latency time. > > > >Obviously, it can be reduced > >by bringing HA functionality closer to MN - > >which is the purpose of hierarchies. > >What else can be done? > >Nothing if we consider layer 3 alone > >since this would mean to by-pass registration message or data packets. > >In particular, bicast/multicast will not help. > > > >Another (the only?) way is guessing the emergence of a new link, > >i.e. taking outer "oracles" like layer 2 events, statistics etc. into account. > >In this case, bicasting can indeed make sense > >if the guess does not give a unique answer: > >Just multicast to all nodes which the guess predicts. > >(Broadcast would result from the most vague guess.) > >This increases the probability that all packets reach MN. > > > >Note however that multicast is concerned only with vagueness of guesses - > >if they are precise, multicasting does have not have any effect. > >Hence, fast handover without bicasting > >(your original question) does make sense. > > > >I'm not sure whether the above is now "gap-free". Hence, please comment. > > > >Wolfgang > > -- Prof. Dr. Wolfgang Schoenfeld, Fraunhofer IPSI, Dolivostr. 15, D-64293 Darmstadt Office: +49-6151-869-865 FAX: -6847 Mobile: +49-174-7093455 From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 26 14:03:11 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA27718 for ; Thu, 26 Jul 2001 14:03:11 -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 IAA01549; Thu, 26 Jul 2001 08:04: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 IAA06016; Thu, 26 Jul 2001 08:04:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6QF3Qq02049 for mobile-ip-dist; Thu, 26 Jul 2001 08:03:26 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6QF3MY02042 for ; Thu, 26 Jul 2001 08:03:22 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA28750 for ; Thu, 26 Jul 2001 08:03:35 -0700 (PDT) Received: from zcars0m9.ca.nortel.com ([47.129.242.157]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA14172 for ; Thu, 26 Jul 2001 08:03:35 -0700 (PDT) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f6QF3D919823 for ; Thu, 26 Jul 2001 11:03:13 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Thu, 26 Jul 2001 11:03:14 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Jul 2001 11:03:18 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5E8F@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Handover Smoothing - What to Do? Date: Thu, 26 Jul 2001 11:03:20 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C115E4.1BA74B80" X-Orig: 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_01C115E4.1BA74B80 Content-Type: text/plain; charset="iso-8859-1" Absolutely Mike. If the ROHC packets are sent over the air to the MN, he decompressor states for the two streams will diverge rapidly (I'm imagining that they diverge exponentially, which would make the state relationship chaotic, but that's for another mailing list). The reason they will diverge is due to the inevitable gross differences in behaviour of the channel between old AR and MN compared to the behaviour of the channel between new AR and MN. The ROHC compression algorithms are designed to adapt to varying channel conditions, and thus will adapt differently to the two different channels (which is why the "many-to-one" mode Rajeev mentioned appears to me to be a very complex problem to solve). Gary > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: July 25, 2001 19:32 > To: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Handover Smoothing - What to Do? > > > James Kempf writes: > > >On the other hand, > > >if the new-AR has to possess the context > *simultaneously*, this adds a new > > >dimension to header compression: Many-to-One header compression! > > > > I don't follow. If the old AR gets the trigger for context transfer > > soon enough, it can send the header compression state to the new > > AR. New AR installs it, compresses incoming bicast packet headers. > > The problem is that you have one ROHC context with two > packet sources, AR1 and AR2. Sounds like the ROHC context > needs to be forked (cloned) on MN too, and the MN needs to pay > attention to the i/f it came in on for real (which already > does, I assume). > > Mike > ------_=_NextPart_001_01C115E4.1BA74B80 Content-Type: text/html; charset="iso-8859-1" RE: [mobile-ip] Handover Smoothing - What to Do?

Absolutely Mike.

If the ROHC packets are sent over the air to the MN, he decompressor
states for the two streams will diverge rapidly (I'm imagining that
they diverge exponentially, which would make the state relationship
chaotic, but that's for another mailing list).

The reason they will diverge is due to the inevitable gross differences
in behaviour of the channel between old AR and MN compared to the
behaviour of the channel between new AR and MN. The ROHC compression
algorithms are designed to adapt to varying channel conditions, and
thus will adapt differently to the two different channels (which is
why the "many-to-one" mode Rajeev mentioned appears to me to be
a very complex problem to solve).

Gary

> -----Original Message-----
> From: Michael Thomas [mailto:mat@cisco.com]
> Sent: July 25, 2001 19:32
> To: mobile-ip@sunroof.eng.sun.com
> Subject: Re: [mobile-ip] Handover Smoothing - What to Do?
>
>
> James Kempf writes:
>  > >On the other hand,
>  > >if the new-AR has to possess the context
> *simultaneously*, this adds a new
>  > >dimension to header compression: Many-to-One header compression!
>  >
>  > I don't follow. If the old AR gets the trigger for context transfer
>  > soon enough, it can send the header compression state to the new
>  > AR. New AR installs it, compresses incoming bicast packet headers.
>
>    The problem is that you have one ROHC context with two
>    packet sources, AR1 and AR2. Sounds like the ROHC context
>    needs to be forked (cloned) on MN too, and the MN needs to pay
>    attention to the i/f it came in on for real (which already
>    does, I assume).
>
>          Mike
>

------_=_NextPart_001_01C115E4.1BA74B80-- From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 26 14:07:31 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA28103 for ; Thu, 26 Jul 2001 14:07:28 -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 LAA02359; Thu, 26 Jul 2001 11:07: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 LAA13944; Thu, 26 Jul 2001 11:06:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6QI5rq04173 for mobile-ip-dist; Thu, 26 Jul 2001 11:05:53 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6QI5oY04166 for ; Thu, 26 Jul 2001 11:05:50 -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 LAA13707 for ; Thu, 26 Jul 2001 11:06:05 -0700 (PDT) Received: from RRMAIL01.RADIOROUTER_NT ([63.103.94.23]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA14090 for ; Thu, 26 Jul 2001 12:06:03 -0600 (MDT) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Jul 2001 14:06:03 -0400 Message-ID: <8C92E23A3E87FB479988285F9E22BE460546CA@ftmail> From: George Tsirtsis To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Analysis of Jitter in Bicasting Date: Thu, 26 Jul 2001 14:05:55 -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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Mike, I think you are making the point that - end hosts already deal with duplicate packets since this is a natural occurrence in the Internet today so bicasting should not be a problem - The difference is that end nodes deal with duplicate packets up to a point...i.e.: up to 3 re-orderings/losses etc generating 3 dupacks in a row, before TCP starts having problems. The fact that TCP deals with 3 dupacks and not with 5 or 10 or 100 was an engineering choice that balances adaptivity and throughput with the chances of this happening in the Internet or they just picked a number from thin air...wouldn't know...was not here :-) My argument is that bicasting, increases the chances of duplication on top of what the Internet naturally does and that could have bad effects if in widespread use. Say for example, due to natural re-ordering somewhere in the Internet, a node is about to receive 2 TCP acks, which TCP can actually deal with no problems. At the same time the MN's packets are duplicated (due to bicasting) at the receiving end, which results in the MN receiving 4 TCP acks! This forces TCP to half its window thinking that there must be congestion in the network and the packets do not get across which is clearly not the case! So, the objections here are not about being able to "deal" with re-ordering as it naturally occurs but that we should not introduce mechanisms that artificially increase the chance duplicate acks. Regards George -----Original Message----- From: Michael Thomas [mailto:mat@cisco.com] Sent: Thursday, July 26, 2001 6:34 PM To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Analysis of Jitter in Bicasting Gary Kenward writes: > > From: James Kempf [mailto:James.Kempf@Sun.COM] > > In the case of 1, the probability of a duplicate packet has nothing > > whatsoever to do with the radio link. It is purely a matter of traffic > > engineering in the wired network. So the probability of a duplicate > > packet can be reduced by properly engineering the wired network. In > > addition, the probability is likely to increase with the topological > > distance between the new AR and the source of the bicast (simply > > because, the more network a packet has to traverse, the more likely > > it is that a congestion event may cause delay). Since engineering > > of the wired network is largely under the network operator's control, > > this problem is fairly straightforward to solve, though it may > > require measures such as over provisioning. > > Well, it takes more then over provisioning. You need to ensure > the same number of hops between the bicasting source (the traffic > bifurcation > point if you will), and you also need to provide some guaranteed bounds on > the delay at each hop after the bicasting source. *if* you want to ensure no > duplicates > at all at the receiver. This may seem like a definition of EF, but > consider that the constraint is much more severe then that of EF. With > EF the bound is on inter-packet delay and delay jitter for a single stream. > With bicasting, the bound is on the arrival delay of two copies of the > same packet that traverse different paths through N hops. The maximum > delay difference, I believe, is one packet duration, T. Thus, the delay > difference bound at each hop must roughly be T/N (the relationship is > not linear, but this gives a rough approximation). If the source of > the delay is from queuing, then this would imply that there can be > no other traffic following the same path. E.g. if a bicasted packet > arrives at an AR and is queued behind a packet that is being served > (note: served, not queued), from a different packet stream, then > it receives a delay of roughly T/2. I am very, very confused by all of this. Bicasting at the IP layer would merely result in duplicates which the transport/application layer would need to deal with. In fact, it already needs to deal with dups because IP packets are fairly regularly duplicated anyway. While it may require some specific tweaks to TCP (which I assume EIFEL attempts to provide), I see no reason why one would want to shield the receiver from this in the network, nor do I see any reason why it requires a difference in the per hop behavior in the tunneled traffic to AR new, or any consideration of number of hops, etc. The beauty of the end to end principal is that the receiver just adapts *regardless* of where the source of the jitter/loss/duplication/etc came from. Trying to deal with jitter hop-by-hop is akin to the general X.25 approach to transport which is if nothing else against the general IP philosphy of end to end transport. More pragmatically, dealing with jitter in the network will almost certainly yield a worse end to end delay as a single jitter buffer on the receiver. Mike From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 26 14:20:19 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA00577 for ; Thu, 26 Jul 2001 14:20: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 LAA09033; Thu, 26 Jul 2001 11:19:53 -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 LAA03027; Thu, 26 Jul 2001 11:16:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6QIEwS04306 for mobile-ip-dist; Thu, 26 Jul 2001 11:14:58 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6QIEsY04299 for ; Thu, 26 Jul 2001 11:14:54 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA21535 for ; Thu, 26 Jul 2001 11:15:09 -0700 (PDT) Received: from netmail2.alcatel.com (netmail2.alcatel.com [128.251.168.51]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA08886 for ; Thu, 26 Jul 2001 11:15:04 -0700 (PDT) Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6]) by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id NAA13973 for ; Thu, 26 Jul 2001 13:15:03 -0500 (CDT) Received: from usa.alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f6QIF3d08698 for ; Thu, 26 Jul 2001 13:15:03 -0500 (CDT) Message-ID: <3B604F41.B8B4176C@usa.alcatel.com> Date: Thu, 26 Jul 2001 13:11:29 -0400 From: Behcet Sarikaya X-Mailer: Mozilla 4.76 [en]C-CCK-MCD BDPjm-Sony3 (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Handover Smoothing - What to Do? References: <8C92E23A3E87FB479988285F9E22BE460546C9@ftmail> <3B605958.60198216@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 Rajeev's email seems to be in line with my position. The only remark I have is to not to disregard the LMM due to whatever reasons. If there is a bar meeting planned on this in London, count me in. Rajeev Koodli wrote: > George, > > George Tsirtsis wrote: > > > -----Original Message----- > > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > > Sent: Thursday, July 26, 2001 6:28 PM > > To: mobile-ip@sunroof.eng.sun.com > > Subject: Re: [mobile-ip] Handover Smoothing - What to Do? > > > > ... > > Reiterating my point, this must not be part of FMIPv6. Time permitting, > > I will work on a separate draft for smoothing and HC and outline these > > issues in detail. > > > > GT> Rajeev, just to make sure I understand, do you think that bicasting > > should be part of FMIPv4 instead or you just do not care about it so match? > > Are the concerns you have IPv6 specific in any way? > > > > Rajeev: My personal opinion (without having participated in the design team > discussion!) is that any fast handover protocol must be able to work without > having to rely on a particular smoothing technique. This is especially > important when practical experience is absent. We are working on FMIPv6 > implementation and we hope to be able to shed some light (on smoothing) in due > course of time. > Hope this helps. > > Regards, > > -Rajeev > > > > > George -- Behcet From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 26 14:28:00 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA01388 for ; Thu, 26 Jul 2001 14:28:00 -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 LAA13676; Thu, 26 Jul 2001 11:28: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 LAA04695; Thu, 26 Jul 2001 11:21:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6QIKTf04397 for mobile-ip-dist; Thu, 26 Jul 2001 11:20:29 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6QIKPY04390 for ; Thu, 26 Jul 2001 11:20:26 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA11285 for ; Thu, 26 Jul 2001 11:20:37 -0700 (PDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA24959 for ; Thu, 26 Jul 2001 11:20:36 -0700 (PDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f6QIKk326424 for ; Thu, 26 Jul 2001 11:20:46 -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 AAW35235; Thu, 26 Jul 2001 11:20:35 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA11119; Thu, 26 Jul 2001 11:20:34 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15200.24434.229572.533478@thomasm-u1.cisco.com> Date: Thu, 26 Jul 2001 11:20:34 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Analysis of Jitter in Bicasting In-Reply-To: <8C92E23A3E87FB479988285F9E22BE460546CA@ftmail> References: <8C92E23A3E87FB479988285F9E22BE460546CA@ftmail> 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 George Tsirtsis writes: > I think you are making the point that - end hosts already deal with > duplicate packets since this is a natural occurrence in the Internet today > so bicasting should not be a problem - > > The difference is that end nodes deal with duplicate packets up to a > point...i.e.: up to 3 re-orderings/losses etc generating 3 dupacks in a row, > before TCP starts having problems. The fact that TCP deals with 3 dupacks > and not with 5 or 10 or 100 was an engineering choice that balances > adaptivity and throughput with the chances of this happening in the Internet > or they just picked a number from thin air...wouldn't know...was not here > :-) > > My argument is that bicasting, increases the chances of duplication on top > of what the Internet naturally does and that could have bad effects if in > widespread use. Say for example, due to natural re-ordering somewhere in the > Internet, a node is about to receive 2 TCP acks, which TCP can actually deal > with no problems. At the same time the MN's packets are duplicated (due to > bicasting) at the receiving end, which results in the MN receiving 4 TCP > acks! This forces TCP to half its window thinking that there must be > congestion in the network and the packets do not get across which is clearly > not the case! > > So, the objections here are not about being able to "deal" with re-ordering > as it naturally occurs but that we should not introduce mechanisms that > artificially increase the chance duplicate acks. George, First off, disclaimer: I'm neutral on both buffering and bicasting. My point was simply that we not try to perform any unnatural acts in the middle of the network to hide jitter and duplication from the end hosts. Yes, I agree that that will cause many TCP's to barf, but the right thing to do is to fix the TCP, not hide it in the network. In fact, the effects of bicasting would only affect mobile nodes, and I'd assume that ones which were the targets of bicasting would have a fair amount of incentive to deal with this inevitability. Were it a possibility toward any random CN, then I'd probably have a different opinion, but that doesn't seem to be the case. Mike From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 26 14:45:13 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA02798 for ; Thu, 26 Jul 2001 14:45:12 -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 MAA14801; Thu, 26 Jul 2001 12:45: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 LAA10788; Thu, 26 Jul 2001 11:45:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6QIi6U04542 for mobile-ip-dist; Thu, 26 Jul 2001 11:44:06 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6QIi3Y04535 for ; Thu, 26 Jul 2001 11:44: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 LAA17408 for ; Thu, 26 Jul 2001 11:44:16 -0700 (PDT) Received: from RRMAIL01.RADIOROUTER_NT ([63.103.94.23]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA13644 for ; Thu, 26 Jul 2001 12:44:14 -0600 (MDT) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Jul 2001 14:44:14 -0400 Message-ID: <8C92E23A3E87FB479988285F9E22BE460546CB@ftmail> From: George Tsirtsis To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Handover Smoothing - What to Do? Date: Thu, 26 Jul 2001 14:44: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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: -----Original Message----- From: Behcet Sarikaya [mailto:behcet.sarikaya@usa.alcatel.com] Sent: Thursday, July 26, 2001 6:11 PM To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Handover Smoothing - What to Do? Rajeev's email seems to be in line with my position. The only remark I have is to not to disregard the LMM due to whatever reasons. If there is a bar meeting planned on this in London, count me in. GT> I think the whole IETF IS a bar meeting :-) George From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 26 14:49:44 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA03076 for ; Thu, 26 Jul 2001 14:49:44 -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 GAA15008; Thu, 26 Jul 2001 06:00:51 -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 GAA14659; Thu, 26 Jul 2001 06:00:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6QCxCP01266 for mobile-ip-dist; Thu, 26 Jul 2001 05:59:12 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6QCx9Y01259 for ; Thu, 26 Jul 2001 05:59:09 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA20550 for ; Thu, 26 Jul 2001 05:59:23 -0700 (PDT) From: Yolanda.Benito-Prieto@t-systems.de Received: from fw9.telekom.de (gw9.telekom.de [62.156.152.68]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id FAA21417 for ; Thu, 26 Jul 2001 05:59:22 -0700 (PDT) Received: by fw9.telekom.de; (5.65v4.0/1.3/10May95) id AA21928; Thu, 26 Jul 2001 14:59:16 +0200 Received: from Q9J99.mgb01.telekom.de by U9JWN.mgb01.telekom.de with ESMTP for mobile-ip@sunroof.eng.sun.com; Thu, 26 Jul 2001 14:45:26 +0200 Received: from g9jbq.mgb01.telekom.de by Q9J99.mgb01.telekom.de with ESMTP for mobile-ip@sunroof.eng.sun.com; Thu, 26 Jul 2001 14:45:13 +0200 Received: by G9JBQ.mgb01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Jul 2001 14:45:12 +0200 Message-Id: <476F91F7CFDBD41182E000D0B7E7E693B9ACF6@U9JM7> To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] A question about 'traceroute' Date: Thu, 26 Jul 2001 14:45:05 +0200 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f6QCx9Y01260 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: X-MIME-Autoconverted: from 8bit to quoted-printable by mercury.Sun.COM id GAA15008 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA03076 > Good morning! > I would like to know a little bit more about the troubles to run "traceroute" for MIPv4. Is there someone who can answer me? I have read a mail, posted in this list. But it's not very clear. > Thank you. > > Best regards, > Yolanda Benito > > > Assumpte: [mobile-ip] "Traceroute" in MIPv4 > Data: Thu, 12 Jul 2001 10:32:47 -0500 > De: Sridhar Gurivireddy > Respon a: mobile-ip@sunroof.eng.sun.com > Organització: Alcatel USA > A: mobile-ip@sunroof.eng.sun.com > > "Traceroute" program works by incrementing TTL value from 1 to 255 and > by sending ICMP echo_request packet in the payload....The source lists > all the routers which send "ICMP_TTL_exceeded" to trace the route to IP > host....I guess "Traceroute" does not work in MIPv4 > > Let CN run "traceroute" program to find the route to MN... > > Case 1: Alternate CoA used > After the FA decapsulates the packet and finds that TTL=0 , it sends > "TTL exceeded" message back to HA. HA manupulates this packet and > changes the packet to ICMP_HOST_UNREACHABLE..{As per Mobile Ipv4 > specification) When the CN gets this packet, it is going to stop the > "traceroute" program..So, I guess "traceroute" does not work... > > Case 2: Co-located CoA used: > Even in this case it does not work for the same reason.... > > -- > Sridhar Guriviredddy, > Ph: 972.996.2048 > > > > Yolanda Benito > Active Networks and Mobility (EB23.4) > T-Systems > T-Nova Deutsche Telekom Innovationsgesellschaft mbH > Berkom > Goslarer Ufer 35 > D-10589 Berlin > phone: +49-(0)30-3497-3296 fax: +49-(0)30-3497-3297 > E-Mail: Yolanda.Benito-Prieto@t-systems.de > > > From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 26 14:49:50 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA03089 for ; Thu, 26 Jul 2001 14:49:50 -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 HAA07257; Thu, 26 Jul 2001 07:06: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 HAA11396; Thu, 26 Jul 2001 07:06:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6QE47101530 for mobile-ip-dist; Thu, 26 Jul 2001 07:04:07 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6QE44Y01523 for ; Thu, 26 Jul 2001 07:04:04 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA27223 for ; Thu, 26 Jul 2001 07:04:18 -0700 (PDT) Received: from netmail2.alcatel.com (netmail2.alcatel.com [128.251.168.51]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA20393 for ; Thu, 26 Jul 2001 07:04:18 -0700 (PDT) Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6]) by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id JAA01729 for ; Thu, 26 Jul 2001 09:04:17 -0500 (CDT) Received: from usa.alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f6QE4Hd18454 for ; Thu, 26 Jul 2001 09:04:17 -0500 (CDT) Message-ID: <3B60235F.1DE13A77@usa.alcatel.com> Date: Thu, 26 Jul 2001 09:04:15 -0500 From: Sridhar Gurivireddy Organization: Alcatel USA X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] A question about 'traceroute' References: <476F91F7CFDBD41182E000D0B7E7E693B9ACF6@U9JM7> 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: X-MIME-Autoconverted: from 8bit to quoted-printable by mercury.Sun.COM id HAA07257 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA03089 Traceroute program works by sending "ICMP_Echo_request" packets and incrementally increasing TTL value from 1 to 255 until it finds Destination...Traceroute program lists the address of the nodes which send "ICMP TTL exceeded" .....It stops when it gets ICMP_ECHO_REPLY from destination. If a CN runs "traceroute" program to MN But in MIpv4," ICMP TTL Exceeded" message from MN/FA is translated to "ICMP Destination unreachable" by HA. This translated ICMP error is sent back to CN So, the traceroute will stop either at MN or at FA , but the program will never end up finding the mobile host...Even when it reaches MN, the packet will not be sent to the "ping" program because TTL=0....Usually "Traceroute" program ends when the node receives a "Ping" packet with TTL=1 "ping" in the above paragraph refers to the name of program which responds to "ICMP_ECHO_REQUEST" packets Sridhar. Yolanda.Benito-Prieto@t-systems.de wrote: > > Good morning! > > I would like to know a little bit more about the troubles to run "traceroute" for MIPv4. Is there someone who can answer me? I have read a mail, posted in this list. But it's not very clear. > > Thank you. > > > > Best regards, > > Yolanda Benito > > > > > > Assumpte: [mobile-ip] "Traceroute" in MIPv4 > > Data: Thu, 12 Jul 2001 10:32:47 -0500 > > De: Sridhar Gurivireddy > > Respon a: mobile-ip@sunroof.eng.sun.com > > Organització: Alcatel USA > > A: mobile-ip@sunroof.eng.sun.com > > > > "Traceroute" program works by incrementing TTL value from 1 to 255 and > > by sending ICMP echo_request packet in the payload....The source lists > > all the routers which send "ICMP_TTL_exceeded" to trace the route to IP > > host....I guess "Traceroute" does not work in MIPv4 > > > > Let CN run "traceroute" program to find the route to MN... > > > > Case 1: Alternate CoA used > > After the FA decapsulates the packet and finds that TTL=0 , it sends > > "TTL exceeded" message back to HA. HA manupulates this packet and > > changes the packet to ICMP_HOST_UNREACHABLE..{As per Mobile Ipv4 > > specification) When the CN gets this packet, it is going to stop the > > "traceroute" program..So, I guess "traceroute" does not work... > > > > Case 2: Co-located CoA used: > > Even in this case it does not work for the same reason.... > > > > -- > > Sridhar Guriviredddy, > > Ph: 972.996.2048 > > > > > > > > Yolanda Benito > > Active Networks and Mobility (EB23.4) > > T-Systems > > T-Nova Deutsche Telekom Innovationsgesellschaft mbH > > Berkom > > Goslarer Ufer 35 > > D-10589 Berlin > > phone: +49-(0)30-3497-3296 fax: +49-(0)30-3497-3297 > > E-Mail: Yolanda.Benito-Prieto@t-systems.de > > > > > > -- Sridhar Guriviredddy, Alcatel- Network Strategic Group, Richardson, TX-75080 Ph: 972.996.2048 From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 26 14:53:24 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA03349 for ; Thu, 26 Jul 2001 14:53:24 -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 MAA20873; Thu, 26 Jul 2001 12:53:33 -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 LAA19140; Thu, 26 Jul 2001 11:53:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6QIpuu04595 for mobile-ip-dist; Thu, 26 Jul 2001 11:51:57 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6QIprY04588 for ; Thu, 26 Jul 2001 11:51:53 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA00156 for ; Thu, 26 Jul 2001 11:52:06 -0700 (PDT) Received: from RRMAIL01.RADIOROUTER_NT ([63.103.94.23]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA26727 for ; Thu, 26 Jul 2001 11:52:05 -0700 (PDT) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Jul 2001 14:52:04 -0400 Message-ID: <8C92E23A3E87FB479988285F9E22BE460546CC@ftmail> From: George Tsirtsis To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Analysis of Jitter in Bicasting Date: Thu, 26 Jul 2001 14:52:02 -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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: -----Original Message----- From: Michael Thomas [mailto:mat@cisco.com] Sent: Thursday, July 26, 2001 7:21 PM To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Analysis of Jitter in Bicasting George Tsirtsis writes: > I think you are making the point that - end hosts already deal with > duplicate packets since this is a natural occurrence in the Internet today > so bicasting should not be a problem - > > The difference is that end nodes deal with duplicate packets up to a > point...i.e.: up to 3 re-orderings/losses etc generating 3 dupacks in a row, > before TCP starts having problems. The fact that TCP deals with 3 dupacks > and not with 5 or 10 or 100 was an engineering choice that balances > adaptivity and throughput with the chances of this happening in the Internet > or they just picked a number from thin air...wouldn't know...was not here > :-) > > My argument is that bicasting, increases the chances of duplication on top > of what the Internet naturally does and that could have bad effects if in > widespread use. Say for example, due to natural re-ordering somewhere in the > Internet, a node is about to receive 2 TCP acks, which TCP can actually deal > with no problems. At the same time the MN's packets are duplicated (due to > bicasting) at the receiving end, which results in the MN receiving 4 TCP > acks! This forces TCP to half its window thinking that there must be > congestion in the network and the packets do not get across which is clearly > not the case! > > So, the objections here are not about being able to "deal" with re-ordering > as it naturally occurs but that we should not introduce mechanisms that > artificially increase the chance duplicate acks. George, First off, disclaimer: I'm neutral on both buffering and bicasting. My point was simply that we not try to perform any unnatural acts in the middle of the network to hide jitter and duplication from the end hosts. Yes, I agree that that will cause many TCP's to barf, but the right thing to do is to fix the TCP, not hide it in the network. In fact, the effects of bicasting would only affect mobile nodes, and I'd assume that ones which were the targets of bicasting would have a fair amount of incentive to deal with this inevitability. Were it a possibility toward any random CN, then I'd probably have a different opinion, but that doesn't seem to be the case. GT> But it will be towards a random CN...what do you thing the mobiles are going to be? Definately not only specialized devices...any PC with any OS may be mobile and thus the potential target of bicasting...BTW, I also thing that TCP should be fixed...and thus EIFFEL is good work...we just need experimentation experiance and time for it to be implemented/tested/deployed...then yes, bicasting may become feasible. Regards George Mike From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 26 14:56:18 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA27611 for ; Thu, 26 Jul 2001 14:02:51 -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 IAA04754; Thu, 26 Jul 2001 08:12: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 IAA08275; Thu, 26 Jul 2001 08:11:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6QFAQs02140 for mobile-ip-dist; Thu, 26 Jul 2001 08:10:26 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6QFANY02133 for ; Thu, 26 Jul 2001 08:10:23 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA07979 for ; Thu, 26 Jul 2001 08:10:36 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA24887 for ; Thu, 26 Jul 2001 08:10:32 -0700 (PDT) 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 f6QFAVg28180 for ; Thu, 26 Jul 2001 08:10:31 -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 AAW30007; Thu, 26 Jul 2001 08:10:25 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA11102; Thu, 26 Jul 2001 08:10:25 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15200.13025.479151.924059@thomasm-u1.cisco.com> Date: Thu, 26 Jul 2001 08:10:25 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Handover Smoothing - What to Do? In-Reply-To: <9FBD322B7824D511B36900508BF93C9C9F5E8D@zcard031.ca.nortel.com> References: <9FBD322B7824D511B36900508BF93C9C9F5E8D@zcard031.ca.nortel.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 Gary Kenward writes: > Rajeev: > > Is one answer that the old AR could send uncompressed packets > to the new AR, and the new AR would then compress the packets or > not, depending on whether it had the context (there is a an case > to be made here for proactive ct ;^}). Depending on what was actually > sent over the air, this could create a tricky problem to solve > at the MN, as it may need to process the two streams before it could > even attempt duplicate removal, and this would require two compression > state machines, buffers, etc., etc. Not nice. It may not be nice, but I believe it comes with the territory. The alternative is to miss packets during the transition that you might have otherwise been able to recover. For mobile initiated break-before-make scenarios, you obviously don't want to allow any otherwise valid packets to be dropped making the situation worse. Mike From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 26 15:01:42 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA03901 for ; Thu, 26 Jul 2001 15:01:41 -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 NAA27663; Thu, 26 Jul 2001 13:01: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 MAA21493; Thu, 26 Jul 2001 12:01:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6QJ0Mk04665 for mobile-ip-dist; Thu, 26 Jul 2001 12:00:22 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6QJ0IY04658 for ; Thu, 26 Jul 2001 12:00:19 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA02043 for ; Thu, 26 Jul 2001 12:00:32 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA13949 for ; Thu, 26 Jul 2001 12:00: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 MAA11823; Thu, 26 Jul 2001 12:00:32 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6QJ0VJ02353; Thu, 26 Jul 2001 12:00:31 -0700 X-mProtect: Thu, 26 Jul 2001 12:00:31 -0700 Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdkYCdko; Thu, 26 Jul 2001 12:00:30 PDT Message-ID: <3B6068CE.7BFCB343@iprg.nokia.com> Date: Thu, 26 Jul 2001 12:00:30 -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: Rajeev Koodli CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Handover Smoothing - What to Do? References: <8C92E23A3E87FB479988285F9E22BE460546C9@ftmail> <3B605958.60198216@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 Rajeev, This matches my view which, along with other members of the design team, I maintained during all of the discussions. We agreed during the meetings that smoothing techniques for handovers would be considered separately, and thus that both buffering techniques and bicasting techniques would not be specified within the fast handover draft. Regards, Charlie P. Rajeev Koodli wrote: > > George, > > George Tsirtsis wrote: > > > -----Original Message----- > > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > > Sent: Thursday, July 26, 2001 6:28 PM > > To: mobile-ip@sunroof.eng.sun.com > > Subject: Re: [mobile-ip] Handover Smoothing - What to Do? > > > > ... > > Reiterating my point, this must not be part of FMIPv6. Time permitting, > > I will work on a separate draft for smoothing and HC and outline these > > issues in detail. > > > > GT> Rajeev, just to make sure I understand, do you think that bicasting > > should be part of FMIPv4 instead or you just do not care about it so match? > > Are the concerns you have IPv6 specific in any way? > > > > Rajeev: My personal opinion (without having participated in the design team > discussion!) is that any fast handover protocol must be able to work without > having to rely on a particular smoothing technique. This is especially > important when practical experience is absent. We are working on FMIPv6 > implementation and we hope to be able to shed some light (on smoothing) in due > course of time. > Hope this helps. > > Regards, > > -Rajeev > > > > > George From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 26 15:11:18 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA04620 for ; Thu, 26 Jul 2001 15:11:16 -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 KAA29664; Thu, 26 Jul 2001 10:02:29 -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 KAA22306; Thu, 26 Jul 2001 10:02:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6QH0Ca03080 for mobile-ip-dist; Thu, 26 Jul 2001 10:00:12 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6QH08Y03073 for ; Thu, 26 Jul 2001 10:00:08 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA03512 for ; Thu, 26 Jul 2001 10:00:23 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA15474 for ; Thu, 26 Jul 2001 10:00:22 -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 KAA27320 for ; Thu, 26 Jul 2001 10:00:22 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6QH0Le29947 for ; Thu, 26 Jul 2001 10:00:21 -0700 X-mProtect: Thu, 26 Jul 2001 10:00:21 -0700 Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdzyyUIH; Thu, 26 Jul 2001 10:00:20 PDT Message-ID: <3B604CA4.B9936D1A@iprg.nokia.com> Date: Thu, 26 Jul 2001 10:00:21 -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: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Handover Smoothing - What to Do? References: <8C92E23A3E87FB479988285F9E22BE460546A1@ftmail> <3B5F4F57.1927AA19@iprg.nokia.com> <15199.23450.70449.789544@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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Michael Thomas wrote: > Rajeev Koodli writes: > > Hello folks, > > > > I would like to add that there are issues surrounding header compression as > > well. Note that the context resides on the old-AR. What type of packet does it > > bicast ? compressed or uncompressed packet ? If it is uncompressed, it is not > > useful without the new-AR having the compression context. On the other hand, > > if the new-AR has to possess the context *simultaneously*, this adds a new > > dimension to header compression: Many-to-One header compression! If the old-AR > > sends compressed packets to the new-AR, how does the latter handle them ? > > Also, since the MN is not bicasting in the uplink, the uplink context is > > current only on the old-AR even if the new-AR has the context. So, there is a > > synchronization issue as well. > > As a follow up to my previous comment, I believe > that regardless of whether you allow for bicasting > or not, context transfer of header compression > state should be viewed as a fork operation rather > than a move operation. This allows for race > conditions where MN still sees old-AR packets in > the movement window to be processed correctly. > When it eventually gets to new-AR, new packets to > MN will just look like there were a drop or two > which the new context should be able to recover > from. > We have specified the necessary extensions to address the problem in draft-koodli-seamoby-hc-relocate-01.txt. Please have a look and we will be happy to hear your comments. Regards, -Rajeev > > Mike From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 26 15:41:38 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA06596 for ; Thu, 26 Jul 2001 15:41:37 -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 KAA03170; Thu, 26 Jul 2001 10:09:13 -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 KAA28863; Thu, 26 Jul 2001 10:08:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6QH81I03177 for mobile-ip-dist; Thu, 26 Jul 2001 10:08:01 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6QH7wY03170 for ; Thu, 26 Jul 2001 10:07:58 -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 KAA23641 for ; Thu, 26 Jul 2001 10:08:12 -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 LAA24522 for ; Thu, 26 Jul 2001 11:08:05 -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 KAA28076 for ; Thu, 26 Jul 2001 10:08:06 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6QH86w19443 for ; Thu, 26 Jul 2001 10:08:06 -0700 X-mProtect: Thu, 26 Jul 2001 10:08:06 -0700 Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdtvofOd; Thu, 26 Jul 2001 10:08:02 PDT Message-ID: <3B604E72.837856C9@iprg.nokia.com> Date: Thu, 26 Jul 2001 10:08: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: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Handover Smoothing - What to Do? References: <200107251830.LAA07903@heliopolis.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 Hello James, James Kempf wrote: > Hi Phil, > > >There does seem to be some consensus that if a smoothing technique is chosen > >it should be through bicasting or simultaneous binding rather than some kind > >of > >buffering. At the minimum we should have a discussion of why the tradeoff > >of > >accepting the possibility of duplicate packets weighs more heavily than > >accepting > >the possibility of lost packets and the results should be documented. > > > > I have not heard much from advocates of buffering in the discussion > so far, so I would have to agree. > > I don't understand your viewpoint. Just because you have not heard from buffering advocates does not imply that the alternative is the way to go. There are at least two things to consider. First, you are proposing to add a particular smoothing technique to FMIPv6. I am registering my complaint saying that it is not the right thing to do. FMIPv6 must be able to work independently of bicasting. I have provided the problems stemming from header compression as an example to illustrate the added complexity. Second, taking up smoothing as a topic by itself, it is not a foregone conclusion that bicasting/simultaneous binding are the only means. This is an open area and we need discussion and *real experimental* evidence. Also, the header compression example hold here as well. Regards, -Rajeev > >George has also asserted (and speaking for myself personally I also agree > >with) > >that implementations in some environments at least can solve this without > >any kind > >of protocol support at layer 3. > > > > I agree also. > > >Does this seem to summarize everyone's position accurately? Does this > >answer your question > >enough, Jim? > > > > Yes, thanx. > > >Of course, others contributing to the conversation COULD help, > > Agree. > > jak From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 26 15:44:31 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA06852 for ; Thu, 26 Jul 2001 15:44:30 -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 NAA28041; Thu, 26 Jul 2001 13:44:46 -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 MAA00893; Thu, 26 Jul 2001 12:44:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6QJgxb04887 for mobile-ip-dist; Thu, 26 Jul 2001 12:42:59 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6QJgtY04880 for ; Thu, 26 Jul 2001 12:42:55 -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 MAA10725 for ; Thu, 26 Jul 2001 12:42: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 NAA20865 for ; Thu, 26 Jul 2001 13:44:25 -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 MAA16503 for ; Thu, 26 Jul 2001 12:42:54 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6QJgrJ16732 for ; Thu, 26 Jul 2001 12:42:53 -0700 X-mProtect: Thu, 26 Jul 2001 12:42:53 -0700 Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdOyyhQW; Thu, 26 Jul 2001 12:42:29 PDT Message-ID: <3B6072A5.DC83B5A0@iprg.nokia.com> Date: Thu, 26 Jul 2001 12:42: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: Mobile IP Working Group Subject: [mobile-ip] New authentication scheme in Mobile IPv6 draft revision ...-14 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, Somehow, the e-mail address on this note got truncated, so I am resending to this list. Regards, Charlie P. -------- Original Message -------- Subject: New authentication scheme in Mobile IPv6 draft revision ...-14 Date: Thu, 26 Jul 2001 12:28:13 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center To: Bill Sommerfeld CC: mobile-ip@sunroof.eng.sun.co References: <200107251556.f6PFuTS21588@thunk.east.sun.com> Hello Bill, Draft revision ...-14 incorporates the authentication data as part of the Binding Update option itself. I thought that this modification was essentially mandated by Jeff Schiller's comments at the last IETF, and the surrounding discussion about use of IPsec vs. various destination options. One good thing about this arrangement is that it allows the verification of the Binding Update authentication data to happen independently of any IPsec requirement between the mobile node and the recipient of the Binding Update. To me, this seems like a good thing, and I am hoping that you would agree. > This is a *consequence* of the issue I pointed out yesterday: namely, > that if you allow for traffic on a connection/flow to contain a mix of > encrypted and unencrypted packets, you open yourself up to various > nasty denial of service attacks, and IPsec cannot provide useful > guarantees to upper layers. Could you make a small description about how the attacks work? I would have thought that IPsec should be applied depending on the kind of socket opened by the application, but maybe not... >> if piggybacking a BU was the problem, we could have solved >> it long back. just disallow piggybacking. anyway its a 'MAY' >> in the current draft. you dont lose much by not piggybacking >> the BU. > > I disagree. If it's a "MAY", then folks will build implementations > which always piggyback, which will cause interoperabilty problems with > IPsec implementations (such as Solaris's) which do per-connection > policy checks. Doesn't this problem go away entirely in draft ...-14? Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 26 15:49:18 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA07306 for ; Thu, 26 Jul 2001 15:49:16 -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 MAA26021; Thu, 26 Jul 2001 12:49: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 MAA08280; Thu, 26 Jul 2001 12:48:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6QJlWJ04933 for mobile-ip-dist; Thu, 26 Jul 2001 12:47:32 -0700 (PDT) Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6QJlSY04926 for ; Thu, 26 Jul 2001 12:47:28 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA17785; Thu, 26 Jul 2001 15:47:40 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f6QJl4S09268; Thu, 26 Jul 2001 15:47:04 -0400 (EDT) Message-Id: <200107261947.f6QJl4S09268@thunk.east.sun.com> From: Bill Sommerfeld To: "Charles E. Perkins" cc: Bill Sommerfeld , mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Re: New authentication scheme in Mobile IPv6 draft revision ...-14 In-reply-to: Your message of "Thu, 26 Jul 2001 12:28:13 PDT." <3B606F4D.72D2F7E9@iprg.nokia.com> Date: Thu, 26 Jul 2001 15:47:04 -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: > > This is a *consequence* of the issue I pointed out yesterday: namely, > > that if you allow for traffic on a connection/flow to contain a mix of > > encrypted and unencrypted packets, you open yourself up to various > > nasty denial of service attacks, and IPsec cannot provide useful > > guarantees to upper layers. > > Could you make a small description about how the attacks work? > > I would have thought that IPsec should be applied depending on the > kind of socket opened by the application, but maybe not. It's more complicated than that. A system may want to allow opportunistic use of IPsec. In particular, a server doing a passive tcp open may wish to accept either unprotected or protected traffic, leaving the choice of whether to use IPsec up to the client which does the active open. However, once the connection is started, it would be a security hole for the server to accept an unprotected packet; otherwise, an attacker could inject a forged RST or FIN as a denial-of-service attack. If AH or ESP is used to protect the binding update, then a server doing the MIPv6 Correspondant-node protocol and allowing opportunistic use of encryption does not know whether the protection applies to both the BU and the rest of the packet. > >> if piggybacking a BU was the problem, we could have solved > >> it long back. just disallow piggybacking. anyway its a 'MAY' > >> in the current draft. you dont lose much by not piggybacking > >> the BU. > > > > I disagree. If it's a "MAY", then folks will build implementations > > which always piggyback, which will cause interoperabilty problems with > > IPsec implementations (such as Solaris's) which do per-connection > > policy checks. > > Doesn't this problem go away entirely in draft ...-14? I have no idea. It may, but there may be new problems introduced by the new protocol in -14. The document is 120 pages long and I simply don't have time at the moment to review it. The underlying message you should have been getting all along from the security experts is to simplify the protocol. This change increases its complexity. I repeat my recommendation that MIPv6 discard the use of destination options and just use straightforward IPv6-in-IPvN tunnels, which are already understood and are well-handled by existing IPsec implementations. - Bill From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 26 15:54:58 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA07657 for ; Thu, 26 Jul 2001 15:54:57 -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 NAA05631; Thu, 26 Jul 2001 13:55: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 MAA09827; Thu, 26 Jul 2001 12:54:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6QJqEH04994 for mobile-ip-dist; Thu, 26 Jul 2001 12:52:14 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6QJqBY04987 for ; Thu, 26 Jul 2001 12:52:11 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA24504 for ; Thu, 26 Jul 2001 12:52:24 -0700 (PDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id MAA23479 for ; Thu, 26 Jul 2001 12:52:24 -0700 (PDT) Received: (qmail 12987 invoked by uid 500); 26 Jul 2001 19:41:20 -0000 Date: Thu, 26 Jul 2001 12:41:20 -0700 From: Pat Calhoun To: mobile-ip@sunroof.eng.sun.com Cc: iesg@ietf.org Subject: Re: [mobile-ip] RE: Last Call: Generalized NAI (GNAIE) Extension to Proposed Standard Message-ID: <20010726124120.G6433@charizard.diameter.org> References: <20010725073933.B10225@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from fredrik@ipunplugged.com on Thu, Jul 26, 2001 at 02:38:16PM +0200 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 Thu, Jul 26, 2001 at 02:38:16PM +0200, Fredrik Johansson wrote: > Ok, sounds good to me. > Can't believe that I didn't think of the mobile sending the previous FA nai. good. > > Just for my own curiosity, what are the rules to obsolete a rfc by another? > e.g. to obsolete rfc 2794 and use the GNAI for all nai extensions? An RFC that obsoletes another states in its header the RFCs that it obsoletes. Take a look at RFC 2865 for an example. When submitting an RFC to the IESG, one has to state that it will be obsoleting another RFC. However, we don't just obsolete RFCs for fun. Typically it is done when an RFC moves from PS to DS, or when a crucial fix was made and the older RFC is no longer relevant. In this particular case, obsoleting RFC 2794, when folks just started shipping products supporting it, would be a very bad thing (TM). PatC From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 26 16:20:34 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09422 for ; Thu, 26 Jul 2001 16:20:33 -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 NAA09732; Thu, 26 Jul 2001 13:18: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 NAA14492; Thu, 26 Jul 2001 13:13:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6QKC7U05111 for mobile-ip-dist; Thu, 26 Jul 2001 13:12:07 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6QKC4Y05104 for ; Thu, 26 Jul 2001 13:12:04 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA05966 for ; Thu, 26 Jul 2001 13:12:18 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA03132; Thu, 26 Jul 2001 13:12:16 -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 NAA19927; Thu, 26 Jul 2001 13:12:15 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6QKCEM00332; Thu, 26 Jul 2001 13:12:14 -0700 X-mProtect: Thu, 26 Jul 2001 13:12:14 -0700 Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdRwBMDv; Thu, 26 Jul 2001 13:12:12 PDT Message-ID: <3B60799C.C5219744@iprg.nokia.com> Date: Thu, 26 Jul 2001 13:12:12 -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: Bill Sommerfeld CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: New authentication scheme in Mobile IPv6 draft revision ...-14 References: <200107261947.f6QJl4S09268@thunk.east.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 >>> I disagree. If it's a "MAY", then folks will build implementations >>> which always piggyback, which will cause interoperabilty problems with >>> IPsec implementations (such as Solaris's) which do per-connection >>> policy checks. >> >> Doesn't this problem go away entirely in draft ...-14? > > I have no idea. It may, but there may be new problems introduced by > the new protocol in -14. The document is 120 pages long and I simply > don't have time at the moment to review it. I can certainly understand that. If you had time to review just a dozen pages, I could suggest the Changes appendix and just the Binding Update option. > The underlying message you should have been getting all along from the > security experts is to simplify the protocol. This change increases > its complexity. I don't think so! The change amounts to putting the authentication data directly into the Binding Update option (an increase in complexity) and removing dependence on IPsec. The latter, as I think has been conclusively demonstrated even by your notes of the last week, amounts to a very large decrease in overall complexity. For instance, there wouldn't be the kind of denial of service attacks you mentioned. > I repeat my recommendation that MIPv6 discard the use of destination > options and just use straightforward IPv6-in-IPvN tunnels, which are > already understood and are well-handled by existing IPsec > implementations. It's something to consider. However, I should also point out that - People have been building implementations for a long time - There have been numerous interoperability tests - The protocol was already working pretty well, and then the request was made by security authorities to enlarge the problem space in order to make the protocol more immediately applicable to all IPv6 nodes. This all amounts to a pretty big delay, but I continue to hope that we could be done soon after some work on getting keys set up for the Binding Update message. Throwing away all the previous work doesn't seem fair, nor even warranted because it doesn't get to the root of the problem(s). That's not fair, and a high price to pay for catharsis. Plus, it seems to me that the destination option structure is exactly right for the purpose -- which is to notify the destination about something related to the delivery of data back to the source. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 26 16:38:04 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA10433 for ; Thu, 26 Jul 2001 16:38:03 -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 OAA05531; Thu, 26 Jul 2001 14:37: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 NAA21197; Thu, 26 Jul 2001 13:36:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6QKZQ805246 for mobile-ip-dist; Thu, 26 Jul 2001 13:35:26 -0700 (PDT) Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6QKZMY05239 for ; Thu, 26 Jul 2001 13:35:22 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA20054; Thu, 26 Jul 2001 16:35:36 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f6QKZ0S09747; Thu, 26 Jul 2001 16:35:00 -0400 (EDT) Message-Id: <200107262035.f6QKZ0S09747@thunk.east.sun.com> From: Bill Sommerfeld To: mobile-ip@sunroof.eng.sun.com cc: Bill Sommerfeld Subject: Re: [mobile-ip] Re: New authentication scheme in Mobile IPv6 draft revision ...-14 In-reply-to: Your message of "Thu, 26 Jul 2001 13:12:12 PDT." <3B60799C.C5219744@iprg.nokia.com> Date: Thu, 26 Jul 2001 16:35:00 -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: > > I repeat my recommendation that MIPv6 discard the use of destination > > options and just use straightforward IPv6-in-IPvN tunnels, which are > > already understood and are well-handled by existing IPsec > > implementations. > > It's something to consider. Good. I hope it gets a fair consideration. > However, I should also point out that > > - People have been building implementations for a long time > - There have been numerous interoperability tests > - The protocol was already working pretty well, and then the > request was made by security authorities to enlarge the problem > space in order to make the protocol more immediately applicable > to all IPv6 nodes. In response, I'll point out that folks have been asking me how to secure mobile IPv6 for about a year and a half, and I've been providing the feedback quoted above for nearly that entire time. - Bill From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 26 16:50:34 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA11120 for ; Thu, 26 Jul 2001 16:50: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 MAA21325; Thu, 26 Jul 2001 12:14:50 -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 LAA02536; Thu, 26 Jul 2001 11:14:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6QIDUd04280 for mobile-ip-dist; Thu, 26 Jul 2001 11:13:30 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6QIDQY04273 for ; Thu, 26 Jul 2001 11:13:26 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA21256 for ; Thu, 26 Jul 2001 11:13:41 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA08181 for ; Thu, 26 Jul 2001 11:13: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 LAA06355 for ; Thu, 26 Jul 2001 11:13:40 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6QIDef22466 for ; Thu, 26 Jul 2001 11:13:40 -0700 X-mProtect: Thu, 26 Jul 2001 11:13:40 -0700 Nokia Silicon Valley Messaging Protection Received: from vijayd.iprg.nokia.com (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdsJOPX7; Thu, 26 Jul 2001 11:13:38 PDT Message-ID: <3B605DD3.35A4376C@iprg.nokia.com> Date: Thu, 26 Jul 2001 11:13:39 -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: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Relation between IPv6 and MIP 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 Qiang Zhang wrote: > > Hello, I've always thought that MIP is an addon protocol for IPv6, so it > is a SHOULD not a MUST implementation, is this correct? > If MIP is optional, then a node doesn't have to maintain all binding > signaling, but REALLY has to support home address option, is this an > valid requirement imposed from MIP? > > Please clarify, thank you that is correct. the minimum requirement is " any node should be able to process the home address option ". vijay From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 26 16:57:29 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA11510 for ; Thu, 26 Jul 2001 16:57:28 -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 NAA28302; Thu, 26 Jul 2001 13:57: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 NAA25311; Thu, 26 Jul 2001 13:56:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6QKt0T05360 for mobile-ip-dist; Thu, 26 Jul 2001 13:55:00 -0700 (PDT) Received: from locked.eng.sun.com (locked [129.146.85.189]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6QKsvY05353 for ; Thu, 26 Jul 2001 13:54:57 -0700 (PDT) Received: (from mohanp@localhost) by locked.eng.sun.com (8.11.2+Sun/8.11.2) id f6QKrjT28860 for mobile-ip@sunroof.eng.sun.com; Thu, 26 Jul 2001 13:53:45 -0700 (PDT) From: Mohan Parthasarathy Message-Id: <200107262053.f6QKrjT28860@locked.eng.sun.com> Subject: Re: [mobile-ip] New authentication scheme in Mobile IPv6 draft revision ...-14 In-Reply-To: <3B6072A5.DC83B5A0@iprg.nokia.com> from "Charles E. Perkins" at "Jul 26, 2001 12:42:29 pm" To: mobile-ip@sunroof.eng.sun.com Date: Thu, 26 Jul 2001 13:53:45 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL66 (25)] 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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Charlie, You still want to have the possibility of using IPsec between MN and HA. In that case the i would assume that some of the fields mentioned in section 4.4. will be zero. In Section 4.4 Authentication requirements, it does not talk about IPsec at all. It will be needed if we still think that we may allow IPsec between MN and HA. Section 10.2 still talks about Outbound IPsec processing. It looks a bit confusing to me. -mohan > Hello folks, > > Somehow, the e-mail address on this note got truncated, so > I am resending to this list. > > Regards, > Charlie P. > > > -------- Original Message -------- > Subject: New authentication scheme in Mobile IPv6 draft revision ...-14 > Date: Thu, 26 Jul 2001 12:28:13 -0700 > From: "Charles E. Perkins" > Organization: Nokia Research Center > To: Bill Sommerfeld > CC: mobile-ip@sunroof.eng.sun.co > References: <200107251556.f6PFuTS21588@thunk.east.sun.com> > > > Hello Bill, > > Draft revision ...-14 incorporates the authentication data as part of > the Binding Update option itself. I thought that this modification > was essentially mandated by Jeff Schiller's comments at the last IETF, > and the surrounding discussion about use of IPsec vs. various > destination options. > > One good thing about this arrangement is that it allows the verification > of the Binding Update authentication data to happen independently of > any IPsec requirement between the mobile node and the recipient of the > Binding Update. To me, this seems like a good thing, and I am hoping > that you would agree. > > > This is a *consequence* of the issue I pointed out yesterday: namely, > > that if you allow for traffic on a connection/flow to contain a mix of > > encrypted and unencrypted packets, you open yourself up to various > > nasty denial of service attacks, and IPsec cannot provide useful > > guarantees to upper layers. > > Could you make a small description about how the attacks work? > > I would have thought that IPsec should be applied depending on the > kind of socket opened by the application, but maybe not... > > >> if piggybacking a BU was the problem, we could have solved > >> it long back. just disallow piggybacking. anyway its a 'MAY' > >> in the current draft. you dont lose much by not piggybacking > >> the BU. > > > > I disagree. If it's a "MAY", then folks will build implementations > > which always piggyback, which will cause interoperabilty problems with > > IPsec implementations (such as Solaris's) which do per-connection > > policy checks. > > Doesn't this problem go away entirely in draft ...-14? > > > > Regards, > Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 26 17:25:31 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA13176 for ; Thu, 26 Jul 2001 17:25:30 -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 OAA12408; Thu, 26 Jul 2001 14:25: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 OAA00195; Thu, 26 Jul 2001 14:15:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6QLDvo05455 for mobile-ip-dist; Thu, 26 Jul 2001 14:13:57 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6QLDrY05448 for ; Thu, 26 Jul 2001 14:13:53 -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 OAA20257 for ; Thu, 26 Jul 2001 14:14:08 -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 PAA03975; Thu, 26 Jul 2001 15:15:31 -0600 (MDT) 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 f6QLEHT09977; Thu, 26 Jul 2001 14:14: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 AAW40121; Thu, 26 Jul 2001 14:14:03 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA11129; Thu, 26 Jul 2001 14:14:03 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15200.34843.140037.687168@thomasm-u1.cisco.com> Date: Thu, 26 Jul 2001 14:14:03 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Cc: Bill Sommerfeld Subject: Re: [mobile-ip] Re: New authentication scheme in Mobile IPv6 draft revision ...-14 In-Reply-To: <3B60799C.C5219744@iprg.nokia.com> References: <200107261947.f6QJl4S09268@thunk.east.sun.com> <3B60799C.C5219744@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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Charles E. Perkins writes: > > The underlying message you should have been getting all along from the > > security experts is to simplify the protocol. This change increases > > its complexity. > > I don't think so! The change amounts to putting the authentication > data directly into the Binding Update option (an increase in complexity) > and removing dependence on IPsec. The latter, as I think has been > conclusively demonstrated even by your notes of the last week, amounts > to a very large decrease in overall complexity. For instance, there > wouldn't be the kind of denial of service attacks you mentioned. Bill's right: what IKE DOI currently describes how to key that authentication data? How does that authentication data prevent replays? &tc. If we use standard IPsec mechanisms, we inherit answers for those questions automatically along with a well understood set of complaints about them. Rolling our own in MIP gets to answer all of those questions anew (and more, I'll bet) which IMO is an increase in complexity, and certainly a more complex security analysis would be needed. > Plus, it seems to me that the destination option > structure is exactly right for the purpose -- which is to notify the > destination about something related to the delivery of data back > to the source. That's arguable. It's a routing change and could easily be treated as such. The main advantage seems like the ability to piggyback, but it remains to be seem whether that optimization is really worth the trouble it brings. Mike From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 26 17:31:29 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA13587 for ; Thu, 26 Jul 2001 17:31:28 -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 PAA15335; Thu, 26 Jul 2001 15:31: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 OAA04070; Thu, 26 Jul 2001 14:31:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6QLU1E05621 for mobile-ip-dist; Thu, 26 Jul 2001 14:30:01 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6QLTvY05614 for ; Thu, 26 Jul 2001 14:29:57 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA03729 for ; Thu, 26 Jul 2001 14:30:12 -0700 (PDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id OAA19834 for ; Thu, 26 Jul 2001 14:30:12 -0700 (PDT) Received: (qmail 13324 invoked by uid 500); 26 Jul 2001 21:19:08 -0000 Date: Thu, 26 Jul 2001 14:19:08 -0700 From: Pat Calhoun To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Analysis of Jitter in Bicasting Message-ID: <20010726141908.W6433@charizard.diameter.org> References: <8C92E23A3E87FB479988285F9E22BE460546CA@ftmail> <15200.24434.229572.533478@thomasm-u1.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <15200.24434.229572.533478@thomasm-u1.cisco.com>; from mat@cisco.com on Thu, Jul 26, 2001 at 11:20:34AM -0700 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: > My point was simply that we not try to perform any > unnatural acts in the middle of the network to > hide jitter and duplication from the end > hosts. Yes, I agree that that will cause many > TCP's to barf, but the right thing to do is to fix > the TCP, not hide it in the network. Amen! PatC From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 26 17:32:54 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA13676 for ; Thu, 26 Jul 2001 17:32:53 -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 OAA15715; Thu, 26 Jul 2001 14:33:18 -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 OAA03426; Thu, 26 Jul 2001 14:29:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6QLSQ505591 for mobile-ip-dist; Thu, 26 Jul 2001 14:28:26 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6QLSMY05584 for ; Thu, 26 Jul 2001 14:28: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 OAA03186 for ; Thu, 26 Jul 2001 14:28:37 -0700 (PDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA10922 for ; Thu, 26 Jul 2001 15:30:01 -0600 (MDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f6QLSh302635 for ; Thu, 26 Jul 2001 14:28:44 -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 AAW40596; Thu, 26 Jul 2001 14:28:32 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA11132; Thu, 26 Jul 2001 14:28:32 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15200.35712.194451.748831@thomasm-u1.cisco.com> Date: Thu, 26 Jul 2001 14:28:32 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] New authentication scheme in Mobile IPv6 draft revision ...-14 In-Reply-To: <3B6072A5.DC83B5A0@iprg.nokia.com> References: <3B6072A5.DC83B5A0@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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Charles E. Perkins writes: > Draft revision ...-14 incorporates the authentication data as part of > the Binding Update option itself. I thought that this modification > was essentially mandated by Jeff Schiller's comments at the last IETF, > and the surrounding discussion about use of IPsec vs. various > destination options. I disagree. Piggybacking and selective authentication were what was causing the problems with 2401 IPsec. That doesn't mean that IPsec is inadequate for this task. If we remove those two requirements on IPsec, IPsec should be an adequate solution for this problem. Indeed, given the complexity of creating a new DOI for BU's, etc, making MIPv6 conform to IPsec is comparatively trivial. > One good thing about this arrangement is that it allows the verification > of the Binding Update authentication data to happen independently of > any IPsec requirement between the mobile node and the recipient of the > Binding Update. To me, this seems like a good thing, and I am hoping > that you would agree. It's marginal, and introduces keying questions which are always hard. Also: you can have multiple SA's with different selectors to accomplish this segregation. > I would have thought that IPsec should be applied depending on the > kind of socket opened by the application, but maybe not... Not in the IPsec I'm looking at right now (KLIPS). Unfortunately. Dunno if Solaris has a better socket API. Mike From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 26 17:38:33 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA13991 for ; Thu, 26 Jul 2001 17:38:33 -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 PAA21340; Thu, 26 Jul 2001 15:39: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 OAA06628; Thu, 26 Jul 2001 14:38:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6QLben05758 for mobile-ip-dist; Thu, 26 Jul 2001 14:37:40 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6QLbaY05751 for ; Thu, 26 Jul 2001 14:37:36 -0700 (PDT) Received: from heliopolis.eng.sun.com (pacrimapp2.Singapore.Sun.COM [129.158.124.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA06045; Thu, 26 Jul 2001 14:37:26 -0700 (PDT) From: James Kempf Message-Id: <200107262137.OAA06045@heliopolis.eng.sun.com> Date: Thu, 26 Jul 2001 14:33:57 -0700 To: , "Rajeev Koodli" Cc: Subject: Re: [mobile-ip] Handover Smoothing - What to Do? X-Mailer: Sun NetMail 2.3 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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit I believe both the low latency MIPv4 and FMIPv6 protocols will work regardless of smoothing or lack thereof. They may not work optimally, but they will work. As such, I believe we could separate out smoothing along the lines of Pat's comments a few days ago. However, I do believe that we need to agree on a consistent editorial position. The worst course would be to have one set of specs that have smoothing in them and one without, which is currently where we are at. This would be confusing to implementors, and it also looks unprofessional and just plain tacky. jak >Hello Rajeev, > >This matches my view which, along with other members of the >design team, I maintained during all of the discussions. >We agreed during the meetings that smoothing techniques >for handovers would be considered separately, and thus that >both buffering techniques and bicasting techniques would not >be specified within the fast handover draft. > >Regards, >Charlie P. > > > > >Rajeev Koodli wrote: >> >> George, >> >> George Tsirtsis wrote: >> >> > -----Original Message----- >> > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] >> > Sent: Thursday, July 26, 2001 6:28 PM >> > To: mobile-ip@sunroof.eng.sun.com >> > Subject: Re: [mobile-ip] Handover Smoothing - What to Do? >> > >> > ... >> > Reiterating my point, this must not be part of FMIPv6. Time permitting, >> > I will work on a separate draft for smoothing and HC and outline these >> > issues in detail. >> > >> > GT> Rajeev, just to make sure I understand, do you think that bicasting >> > should be part of FMIPv4 instead or you just do not care about it so match? >> > Are the concerns you have IPv6 specific in any way? >> > >> >> Rajeev: My personal opinion (without having participated in the design team >> discussion!) is that any fast handover protocol must be able to work without >> having to rely on a particular smoothing technique. This is especially >> important when practical experience is absent. We are working on FMIPv6 >> implementation and we hope to be able to shed some light (on smoothing) in >due >> course of time. >> Hope this helps. >> >> Regards, >> >> -Rajeev >> >> > >> > George From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 26 17:40:18 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA14197 for ; Thu, 26 Jul 2001 17:40:17 -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 OAA19356; Thu, 26 Jul 2001 14:40: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 OAA07117; Thu, 26 Jul 2001 14:40:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6QLctx05780 for mobile-ip-dist; Thu, 26 Jul 2001 14:38:55 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6QLcpY05773 for ; Thu, 26 Jul 2001 14:38:52 -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 OAA04922 for ; Thu, 26 Jul 2001 14:39:06 -0700 (PDT) Received: from zcars0m9.ca.nortel.com ([47.129.242.157]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA16304 for ; Thu, 26 Jul 2001 15:40:30 -0600 (MDT) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f6QLcf913712 for ; Thu, 26 Jul 2001 17:38:41 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Thu, 26 Jul 2001 17:38:44 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Jul 2001 17:38:49 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5E96@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Analysis of Jitter in Bicasting Date: Thu, 26 Jul 2001 17:38:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1161B.5C379880" X-Orig: 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_01C1161B.5C379880 Content-Type: text/plain; charset="iso-8859-1" James: I'm not sure that comparing handover latencies with 2, 2.5, or 3G is all that relevant. With soft handover, there is theoretically, no latency, although I suspect that there are exceptions - I'm checking to see if there are published numbers. I have heard some atrociously poor numbers for packet data, but I won't repeat them here because they are not verifiable. The issue with packet data, and the reason that the latency starts to look bad, is that soft handover is extremely difficult to do with shared channels, datagrams and a routed network (i.e. the issues are not all that different from the issues being discussed with respect to bicasting). IMHO 2-3G networks are not well suited to IP services because they were not designed to switch packets fast across the channel (by fast I mean ms, not 10s or 100s of ms). Ultimately, this channel access delay may be the real pacer for handover, not the mobility solution. Enough doom and gloom. In anticipation of a different approach in 4G, there is little information on how to allocate an appropriate "latency budget" across the network. I know that the transit delays for North America for single operator networks have been dropping steadily, and are well below 100 ms (I've heard numbers as low as 50 ms, but I haven't had a chance to check the latest). So, if its 50 ms transit delay, that leaves approximately 30 ms for each access network for one leg of a two way conversation. Not a heck of a lot of time. Of course, it is arguable that you can asymmetrically allocate the budget between access networks, as it is unlikely that they will both need the maximum budget at the same instant (e.g. if both access networks are wireless, it is unlikely that both will be in the process of handing over at the same time). BTW: I did not checked the ITU spec, but 300 ms is as good as 250 ms, certainly as far as these discussions are concerned. End to end latency bounds are determined by the desired quality of the voice service, and usually are based upon empirical measurements from subjective quality tests (the ITU numbers are). The numbers from these tests, called Mean Opinion Scores, have a very high variance, and the real quality difference caused by an increase in latency from 250 to 300 ms is not easily detected (which means you probably can drop the 0.5 from 112.5 ;^} ). One has to be careful in some respects, because there are thresholds where a majority of listeners can detect significant changes in quality (humans being largely non-linear systems), but if I believe the first threshold is upwards towards 500 ms, as someone else has mentioned. Gary > -----Original Message----- > From: James Kempf [mailto:James.Kempf@Sun.COM] > Sent: July 26, 2001 12:06 > To: mobile-ip; 'mobile-ip@sunroof.eng.sun.com' > Subject: RE: [mobile-ip] Analysis of Jitter in Bicasting > > > Hi Gary, > > > Just a quick follow-up on this thread: you mentioned in one of > >your emails that the latency tolerance for conversational voice to > >be around 112.5 ms. It is my understanding that the latency > bounds for > >reasonable quality voice conversations (for an MOS somewhere between > >3 and 4), is around 250 ms round trip. Assuming symmetry, > the implication > >is that the one way, end to end delay should be less then > approximately > >125ms end to end. > > > > Actually, I've been using a figure of 300 ms RTT, based on > ITU recommendations. > 112.5 ms is the handover latency that pops out when you plug > a 6 kbps incoming > voice stream (about what VoIP gets) and a 9.6 kbps uplink > data rate into > the formula dervied in Appendix B of > draft-kempf-beth-ipv6-00.txt, which bounds > handover latency given uplink and incoming real time data > rates when you buffer. > The problem is the handover latency propagates forward as you > dump the buffer > to the uplink, during which time you have to buffer, then > dump that buffer, etc. > > IMHO, buffering is probably a nonoption for real time > traffic, though I think > it could play a role for nonrealtime traffic. > > > If the end to end service is VoIP, then this 125 ms budget must be > >applied to all the IP networks along the path - typically, an access > >network, one or more transit networks and another access network. So, > >I wonder if there really is 112.5 ms to buffer packets, or > anywhere near > >that amount, particularly given the fact that the current > generation of > >radio link protocols seem to consume 10s of ms simply for packet > >access (I'm alluding here to VoIP over the air, not VoIP > converted to > >3G voice service). > > > > Hmm, good question. I have unfortunately been unable to get > any figures > on L2 handover time, so I really can't say. But you are right that > this analysis only takes into account the handover latency. > If you start > throwing in other sources, like for example transatlantic RTT for > a transatlantic call, you very quickly use up the delay budget. > > > One rule of thumb I've always held to with packetized > voice is that > >if you have to delay the packet by more then the vocoder > delay (e.g. 20 ms > >for G.729), then you might as well drop the packet. If you > start dropping > >sequentially packets - e.g. 2 or 3 consecutive voice frames, > the drops will > >be audible to the user. > > > > Sounds like a good rule of thumb. > > > It is my perception that the standard for voice service > in cellular > >systems > >during handoffs is not as stringent. However, this would not be the > >"seamless > >handoff" that has been talked about. > > > > The goal is to make 4G (VoIP over the air) hard (break before > make) handover have the > same quality or better as 2.5 and 3G. If the handover latency > in 2.5 and 3G handover > exposes the user to artifacts, then 4G could I suppose, > though running up the delay > budget to seconds with lots of signalling for new CoA > aquisition, DAD, etc. > probably isn't a good idea. > > Do you have any idea what the latency is for, say, a GSM > handoff (which is normally > break before make)? This would certainly help us bound the > problem more cleanly. > > > Anyway, the question I want to raise is whether there is > really a 112.5 > >ms > >delay budget available at the AR for handover, or whether > the number is > >actually > >much smaller. Some of the work I have seen suggests that the > bound is more > >around 40 ms, for the whole access network. This is roughly two VoIP > >packets, > >for a scenario with one 20 ms G.729 voice frame per IP packet. > > > > If you consider only one direction, then 40 ms sounds right > (it would be slightly less than > half of the 112 ms I calculated, which was based on a RTT > time of 300 ms). > > >Do you, or anyone else have any additional information? If > we are talking > >about > >buffering vs. bicasting, this delay bound *is* very important. > > > > No, but I really wish someone out there in ListLand could > give us some hard figures > on GSM break before make handover times. Last time I tried, I > got some number like > "seconds", which doesn't sound right to me. wCDMA isn't > comparable, nor is cdma2000 > because they use soft handover most of the time (though > perhaps their hard handover > figures would be useful). > > jak > > ------_=_NextPart_001_01C1161B.5C379880 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Analysis of Jitter in Bicasting

James:

  I'm not sure that comparing handover latencies = with 2, 2.5, or 3G
is all that relevant. With soft handover, there is = theoretically,
no latency, although I suspect that there are = exceptions - I'm checking
to see if there are published numbers. I have heard = some atrociously
poor numbers for packet data, but I won't repeat = them here because
they are not verifiable.

  The issue with packet data, and the reason = that the latency starts to
look bad, is that soft handover is extremely = difficult to do with shared
channels, datagrams and a routed network (i.e. the = issues are not all
that different from the issues being discussed with = respect to bicasting).
IMHO 2-3G networks are not well suited to IP = services because they were not
designed to switch packets fast across the channel = (by fast I mean ms, not
10s or 100s of ms). Ultimately, this channel access = delay may be the
real pacer for handover, not the mobility = solution.

  Enough doom and gloom. In anticipation of a = different approach in 4G,
there is little information on how to allocate an = appropriate "latency
budget" across the network. I know that the = transit delays for North
America for single operator networks have been = dropping steadily, and are
well below 100 ms (I've heard numbers as low as 50 = ms, but I haven't had
a chance to check the latest).

  So, if its 50 ms transit delay, that leaves = approximately 30 ms for each
access network for one leg of a two way = conversation. Not a heck of a lot
of time. Of course, it is arguable that you can = asymmetrically allocate
the budget between access networks, as it is = unlikely that they will both
need the maximum budget at the same instant (e.g. if = both access networks
are wireless, it is unlikely that both will be in = the process of handing over
at the same time).

  BTW: I did not checked the ITU spec, but 300 = ms is as good as 250 ms, certainly
as far as these discussions are concerned. End to = end latency bounds are
determined by the desired quality of the voice = service, and usually are based upon empirical measurements from = subjective quality tests (the ITU numbers are).

The numbers from these tests, called Mean Opinion = Scores, have a very high
variance, and the real quality difference caused by = an increase in latency from
250 to 300 ms is not easily detected (which means = you probably can drop
the 0.5 from 112.5 ;^} ). One has to be careful in = some respects, because there
are thresholds where a majority of listeners can = detect significant changes in
quality (humans being largely non-linear systems), = but if I believe the first
threshold is upwards towards 500 ms, as someone else = has mentioned.

Gary

> -----Original Message-----
> From: James Kempf [mailto:James.Kempf@Sun.COM]
> Sent: July 26, 2001 12:06
> To: mobile-ip; = 'mobile-ip@sunroof.eng.sun.com'
> Subject: RE: [mobile-ip] Analysis of Jitter in = Bicasting
>
>
> Hi Gary,
>
> >  Just a quick follow-up on this = thread: you mentioned in one of
> >your emails that the latency tolerance for = conversational voice to
> >be around 112.5 ms. It is my understanding = that the latency
> bounds for
> >reasonable quality voice conversations (for = an MOS somewhere between
> >3 and 4), is around 250 ms round trip. = Assuming symmetry,
> the implication
> >is that the one way, end to end delay = should be less then
> approximately
> >125ms end to end.
> >
>
> Actually, I've been using a figure of 300 ms = RTT, based on
> ITU recommendations.
> 112.5 ms is the handover latency that pops out = when you plug
> a 6 kbps incoming
> voice stream (about what VoIP gets) and a 9.6 = kbps uplink
> data rate into
> the formula dervied in Appendix B of
> draft-kempf-beth-ipv6-00.txt, which = bounds
> handover latency given uplink and incoming real = time data
> rates when you buffer.
> The problem is the handover latency propagates = forward as you
> dump the buffer
> to the uplink, during which time you have to = buffer, then
> dump that buffer, etc.
>
> IMHO, buffering is probably a nonoption for = real time
> traffic, though I think
> it could play a role for nonrealtime = traffic.
>
> >  If the end to end service is VoIP, = then this 125 ms budget must be
> >applied to all the IP networks along the = path - typically, an access
> >network, one or more transit networks and = another access network. So,
> >I wonder if there really is 112.5 ms to = buffer packets, or
> anywhere near
> >that amount, particularly given the fact = that the current
> generation of
> >radio link protocols seem to consume 10s of = ms simply for packet
> >access (I'm alluding here to VoIP over the = air, not VoIP
> converted to
> >3G voice service).
> >
>
> Hmm, good question. I have unfortunately been = unable to get
> any figures
> on L2 handover time, so I really can't say. But = you are right that
> this analysis only takes into account the = handover latency.
> If you start
> throwing in other sources, like for example = transatlantic RTT for
> a transatlantic call, you very quickly use up = the delay budget.
>
> >   One rule of thumb I've always = held to with packetized
> voice is that
> >if you have to delay the packet by more = then the vocoder
> delay (e.g. 20 ms
> >for G.729), then you might as well drop the = packet. If you
> start dropping
> >sequentially packets - e.g. 2 or 3 = consecutive voice frames,
> the drops will
> >be audible to the user.
> >
>
> Sounds like a good rule of thumb.
>
> >   It is my perception that the = standard for voice service
> in cellular
> >systems
> >during handoffs is not as stringent. = However, this would not be the
> >"seamless
> >handoff" that has been talked = about.
> >
>
> The goal is to make 4G (VoIP over the air) hard = (break before
> make) handover have the
> same quality or better as 2.5 and 3G. If the = handover latency
> in 2.5 and 3G handover
> exposes the user to artifacts, then 4G could I = suppose,
> though running up the delay
> budget to seconds with lots of signalling for = new CoA
> aquisition, DAD, etc.
> probably isn't a good idea.
>
> Do you have any idea what the latency is for, = say, a GSM
> handoff (which is normally
> break before make)? This would certainly help = us bound the
> problem more cleanly.
>
> >   Anyway, the question I want to = raise is whether there is
> really a 112.5
> >ms
> >delay budget available at the AR for = handover, or whether
> the number is
> >actually
> >much smaller. Some of the work I have seen = suggests that the
> bound is more
> >around 40 ms, for the whole access network. = This is roughly two VoIP
> >packets,
> >for a scenario with one 20 ms G.729 voice = frame per IP packet.
> >
>
> If you consider only one direction,  then = 40 ms sounds right
> (it would be slightly less than
> half of the 112 ms I calculated, which was = based on a RTT
> time of 300 ms).
>
> >Do you, or anyone else have any additional = information? If
> we are talking
> >about
> >buffering vs. bicasting, this delay bound = *is* very important.
> >
>
> No, but I really wish someone out there in ListL= and could
> give us some hard figures
> on GSM break before make handover times. Last = time I tried, I
> got some number like
> "seconds", which doesn't sound right = to me. wCDMA isn't
> comparable, nor is cdma2000
> because they use soft handover most of the time = (though
> perhaps their hard handover
> figures would be useful).
>
>       =         jak
>
>

------_=_NextPart_001_01C1161B.5C379880-- From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 26 17:47:43 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15490 for ; Thu, 26 Jul 2001 17:47: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 PAA27720; Thu, 26 Jul 2001 15:48: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 OAA09262; Thu, 26 Jul 2001 14:48:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6QLkpb05926 for mobile-ip-dist; Thu, 26 Jul 2001 14:46:51 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6QLklY05919 for ; Thu, 26 Jul 2001 14:46: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 OAA06411 for ; Thu, 26 Jul 2001 14:47:02 -0700 (PDT) Received: from mailsys01.intnet.net (mailhost.wwc.com [198.252.32.15]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA19636 for ; Thu, 26 Jul 2001 15:48:25 -0600 (MDT) Received: from [206.112.107.99] ([206.112.107.99] verified) by mailsys01.intnet.net (CommuniGate Pro SMTP 3.4.8) with ESMTP id 12102164 for mobile-ip@sunroof.eng.sun.com; Thu, 26 Jul 2001 17:46:04 -0400 Mime-Version: 1.0 X-Sender: ahmrphd@pop3.attglobal.net Message-Id: In-Reply-To: <20010726141908.W6433@charizard.diameter.org> References: <8C92E23A3E87FB479988285F9E22BE460546CA@ftmail> <15200.24434.229572.533478@thomasm-u1.cisco.com> <20010726141908.W6433@charizard.diameter.org> Date: Thu, 26 Jul 2001 14:46:54 -0700 To: mobile-ip@sunroof.eng.sun.com From: Arthur Ross Subject: Re: [mobile-ip] Analysis of Jitter in Bicasting 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 14:19 -0700 07/26/2001, Pat Calhoun wrote: > > My point was simply that we not try to perform any >> unnatural acts in the middle of the network to >> hide jitter and duplication from the end >> hosts. Yes, I agree that that will cause many >> TCP's to barf, but the right thing to do is to fix >> the TCP, not hide it in the network. >Amen! > Likewise. That was, basically, the point of my comment about "transmit erasures". If the app/host cares, it is up to the app to cope with the network, warts & all. One app's "desirable network behavior hiding" can be another app's "unnatural act". -- ahmr From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 26 17:50:01 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15621 for ; Thu, 26 Jul 2001 17:50:00 -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 KAA06545; Thu, 26 Jul 2001 10:11:44 -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 JAA14605; Thu, 26 Jul 2001 09:11:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6QGA5v02706 for mobile-ip-dist; Thu, 26 Jul 2001 09:10:05 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6QGA2Y02699 for ; Thu, 26 Jul 2001 09:10:02 -0700 (PDT) Received: from heliopolis.Eng.Sun.COM (eastapp2.East.Sun.COM [129.148.162.99]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA21823; Thu, 26 Jul 2001 09:10:00 -0700 (PDT) From: James Kempf Message-Id: <200107261610.JAA21823@heliopolis.eng.sun.com> Date: Thu, 26 Jul 2001 09:06:23 -0700 To: , "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Analysis of Jitter in Bicasting X-Mailer: Sun NetMail 2.3 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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Gary, > Just a quick follow-up on this thread: you mentioned in one of >your emails that the latency tolerance for conversational voice to >be around 112.5 ms. It is my understanding that the latency bounds for >reasonable quality voice conversations (for an MOS somewhere between >3 and 4), is around 250 ms round trip. Assuming symmetry, the implication >is that the one way, end to end delay should be less then approximately >125ms end to end. > Actually, I've been using a figure of 300 ms RTT, based on ITU recommendations. 112.5 ms is the handover latency that pops out when you plug a 6 kbps incoming voice stream (about what VoIP gets) and a 9.6 kbps uplink data rate into the formula dervied in Appendix B of draft-kempf-beth-ipv6-00.txt, which bounds handover latency given uplink and incoming real time data rates when you buffer. The problem is the handover latency propagates forward as you dump the buffer to the uplink, during which time you have to buffer, then dump that buffer, etc. IMHO, buffering is probably a nonoption for real time traffic, though I think it could play a role for nonrealtime traffic. > If the end to end service is VoIP, then this 125 ms budget must be >applied to all the IP networks along the path - typically, an access >network, one or more transit networks and another access network. So, >I wonder if there really is 112.5 ms to buffer packets, or anywhere near >that amount, particularly given the fact that the current generation of >radio link protocols seem to consume 10s of ms simply for packet >access (I'm alluding here to VoIP over the air, not VoIP converted to >3G voice service). > Hmm, good question. I have unfortunately been unable to get any figures on L2 handover time, so I really can't say. But you are right that this analysis only takes into account the handover latency. If you start throwing in other sources, like for example transatlantic RTT for a transatlantic call, you very quickly use up the delay budget. > One rule of thumb I've always held to with packetized voice is that >if you have to delay the packet by more then the vocoder delay (e.g. 20 ms >for G.729), then you might as well drop the packet. If you start dropping >sequentially packets - e.g. 2 or 3 consecutive voice frames, the drops will >be audible to the user. > Sounds like a good rule of thumb. > It is my perception that the standard for voice service in cellular >systems >during handoffs is not as stringent. However, this would not be the >"seamless >handoff" that has been talked about. > The goal is to make 4G (VoIP over the air) hard (break before make) handover have the same quality or better as 2.5 and 3G. If the handover latency in 2.5 and 3G handover exposes the user to artifacts, then 4G could I suppose, though running up the delay budget to seconds with lots of signalling for new CoA aquisition, DAD, etc. probably isn't a good idea. Do you have any idea what the latency is for, say, a GSM handoff (which is normally break before make)? This would certainly help us bound the problem more cleanly. > Anyway, the question I want to raise is whether there is really a 112.5 >ms >delay budget available at the AR for handover, or whether the number is >actually >much smaller. Some of the work I have seen suggests that the bound is more >around 40 ms, for the whole access network. This is roughly two VoIP >packets, >for a scenario with one 20 ms G.729 voice frame per IP packet. > If you consider only one direction, then 40 ms sounds right (it would be slightly less than half of the 112 ms I calculated, which was based on a RTT time of 300 ms). >Do you, or anyone else have any additional information? If we are talking >about >buffering vs. bicasting, this delay bound *is* very important. > No, but I really wish someone out there in ListLand could give us some hard figures on GSM break before make handover times. Last time I tried, I got some number like "seconds", which doesn't sound right to me. wCDMA isn't comparable, nor is cdma2000 because they use soft handover most of the time (though perhaps their hard handover figures would be useful). jak From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 26 17:51:18 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15710 for ; Thu, 26 Jul 2001 17:51: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 PAB00068; Thu, 26 Jul 2001 15:51: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 OAA10202; Thu, 26 Jul 2001 14:51:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6QLnuG06039 for mobile-ip-dist; Thu, 26 Jul 2001 14:49:56 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6QLnqY06032 for ; Thu, 26 Jul 2001 14:49: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 OAA09877 for ; Thu, 26 Jul 2001 14:50:07 -0700 (PDT) Received: from zcars0m9.ca.nortel.com ([47.129.242.157]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA21233 for ; Thu, 26 Jul 2001 15:51:31 -0600 (MDT) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f6QLnh916097 for ; Thu, 26 Jul 2001 17:49:43 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Thu, 26 Jul 2001 17:49:56 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Jul 2001 17:50:01 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5E97@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Analysis of Jitter in Bicasting Date: Thu, 26 Jul 2001 17:50:03 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1161C.ED39FB60" X-Orig: 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_01C1161C.ED39FB60 Content-Type: text/plain; charset="iso-8859-1" Michael: Sorry for the confusion. I agree that if you are willing to accept duplicates, much of the problem goes away. However, duplicate removal can be a tad nasty for real time services, depending upon the time latency between received copies. That is, if you know that the duplicates always arrive together, then you can use a very short (two packet) buffer, but if the duplicates can be 10s of packets apart, not only do you need more memory, but you likely have to spend more time searching the buffer for duplicates. This search time is usually the main difficulty for real time duplicate removal. But you probably are more familiar with these issues then I am. As a side issue, I don't see why anything really special needs to be done for TCP. TCP is designed around best effort delivery, and as long as you keep within the rather generous limits of a best effort service (which means you can buffer for a very long time), everything should be fine (I'm presuming here that 4G, if not 3G, gets beyond the long, thin pipe problem). Cheers, Gary > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: July 26, 2001 13:34 > To: mobile-ip@sunroof.eng.sun.com > Subject: RE: [mobile-ip] Analysis of Jitter in Bicasting > > > Gary Kenward writes: > > > From: James Kempf [mailto:James.Kempf@Sun.COM] > > > In the case of 1, the probability of a duplicate packet > has nothing > > > whatsoever to do with the radio link. It is purely a > matter of traffic > > > engineering in the wired network. So the probability of > a duplicate > > > packet can be reduced by properly engineering the wired > network. In > > > addition, the probability is likely to increase with the > topological > > > distance between the new AR and the source of the bicast (simply > > > because, the more network a packet has to traverse, the > more likely > > > it is that a congestion event may cause delay). Since engineering > > > of the wired network is largely under the network > operator's control, > > > this problem is fairly straightforward to solve, though it may > > > require measures such as over provisioning. > > > > Well, it takes more then over provisioning. You need to ensure > > the same number of hops between the bicasting source (the traffic > > bifurcation > > point if you will), and you also need to provide some > guaranteed bounds on > > the delay at each hop after the bicasting source. *if* you > want to ensure no > > duplicates > > at all at the receiver. This may seem like a definition of EF, but > > consider that the constraint is much more severe then that > of EF. With > > EF the bound is on inter-packet delay and delay jitter for > a single stream. > > With bicasting, the bound is on the arrival delay of two > copies of the > > same packet that traverse different paths through N hops. > The maximum > > delay difference, I believe, is one packet duration, T. > Thus, the delay > > difference bound at each hop must roughly be T/N (the > relationship is > > not linear, but this gives a rough approximation). If the source of > > the delay is from queuing, then this would imply that there can be > > no other traffic following the same path. E.g. if a bicasted packet > > arrives at an AR and is queued behind a packet that is being served > > (note: served, not queued), from a different packet stream, then > > it receives a delay of roughly T/2. > > I am very, very confused by all of this. Bicasting > at the IP layer would merely result in duplicates > which the transport/application layer would need > to deal with. In fact, it already needs to deal > with dups because IP packets are fairly regularly > duplicated anyway. While it may require some > specific tweaks to TCP (which I assume EIFEL > attempts to provide), I see no reason why one > would want to shield the receiver from this in the > network, nor do I see any reason why it requires a > difference in the per hop behavior in the tunneled > traffic to AR new, or any consideration of number > of hops, etc. The beauty of the end to end principal is > that the receiver just adapts *regardless* of > where the source of the jitter/loss/duplication/etc > came from. Trying to deal with jitter hop-by-hop is akin > to the general X.25 approach to transport which > is if nothing else against the general IP > philosphy of end to end transport. More > pragmatically, dealing with jitter in the network > will almost certainly yield a worse end to end > delay as a single jitter buffer on the receiver. > > Mike > > ------_=_NextPart_001_01C1161C.ED39FB60 Content-Type: text/html; charset="iso-8859-1" RE: [mobile-ip] Analysis of Jitter in Bicasting

Michael:

 Sorry for the confusion. I agree that if you are willing
to accept duplicates, much of the problem goes away. However,
duplicate removal can be a tad nasty for real time services,
depending upon the time latency between received copies. That
is, if you know that the duplicates always arrive together,
then you can use a very short (two packet) buffer, but if the
duplicates can be 10s of packets apart, not only do you need
more memory, but you likely have to spend more time searching the
buffer for duplicates. This search time is usually the main
difficulty for real time duplicate removal.

But you probably are more familiar with these issues then I am.

As a side issue, I don't see why anything really special needs to
be done for TCP. TCP is designed around best effort delivery, and
as long as you keep within the rather generous limits of a best
effort service (which means you can buffer for a very long time),
everything should be fine (I'm presuming here that 4G, if not
3G, gets beyond the long, thin pipe problem).

Cheers,
Gary

> -----Original Message-----
> From: Michael Thomas [mailto:mat@cisco.com]
> Sent: July 26, 2001 13:34
> To: mobile-ip@sunroof.eng.sun.com
> Subject: RE: [mobile-ip] Analysis of Jitter in Bicasting
>
>
> Gary Kenward writes:
>  > > From: James Kempf [mailto:James.Kempf@Sun.COM]
>  > > In the case of 1, the probability of a duplicate packet
> has nothing
>  > > whatsoever to do with the radio link. It is purely a
> matter of traffic
>  > > engineering in the wired network. So the probability of
> a duplicate
>  > > packet can be reduced by properly engineering the wired
> network. In
>  > > addition, the probability is likely to increase with the
> topological
>  > > distance between the new AR and the source of the bicast (simply
>  > > because, the more network a packet has to traverse, the
> more likely
>  > > it is that a congestion event may cause delay). Since engineering
>  > > of the wired network is largely under the network
> operator's control,
>  > > this problem is fairly straightforward to solve, though it may
>  > > require measures such as over provisioning.
>  >
>  > Well, it takes more then over provisioning. You need to ensure
>  > the same number of hops between the bicasting source (the traffic
>  > bifurcation
>  > point if you will), and you also need to provide some
> guaranteed bounds on
>  > the delay at each hop after the bicasting source. *if* you
> want to ensure no
>  > duplicates
>  > at all at the receiver. This may seem like a definition of EF, but
>  > consider that the constraint is much more severe then that
> of EF. With
>  > EF the bound is on inter-packet delay and delay jitter for
> a single stream.
>  > With bicasting, the bound is on the arrival delay of two
> copies of the
>  > same packet that traverse different paths through N hops.
> The maximum
>  > delay difference, I believe, is one packet duration, T.
> Thus, the delay
>  > difference bound at each hop must roughly be T/N (the
> relationship is
>  > not linear, but this gives a rough approximation). If the source of
>  > the delay is from queuing, then this would imply that there can be
>  > no other traffic following the same path. E.g. if a bicasted packet
>  > arrives at an AR and is queued behind a packet that is being served
>  > (note: served, not queued), from a different packet stream, then
>  > it receives a delay of roughly T/2.
>
> I am very, very confused by all of this. Bicasting
> at the IP layer would merely result in duplicates
> which the transport/application layer would need
> to deal with. In fact, it already needs to deal
> with dups because IP packets are fairly regularly
> duplicated anyway. While it may require some
> specific tweaks to TCP (which I assume EIFEL
> attempts to provide), I see no reason why one
> would want to shield the receiver from this in the
> network, nor do I see any reason why it requires a
> difference in the per hop behavior in the tunneled
> traffic to AR new, or any consideration of number
> of hops, etc. The beauty of the end to end principal is
> that the receiver just adapts *regardless* of
> where the source of the jitter/loss/duplication/etc
> came from. Trying to deal with jitter hop-by-hop is akin
> to the general X.25 approach to transport which
> is if nothing else against the general IP
> philosphy of end to end transport. More
> pragmatically, dealing with jitter in the network
> will almost certainly yield a worse end to end
> delay as a single jitter buffer on the receiver.
>
>        Mike
>   
>

------_=_NextPart_001_01C1161C.ED39FB60-- From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 26 17:57:35 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA16140 for ; Thu, 26 Jul 2001 17:57:34 -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 OAA27252; Thu, 26 Jul 2001 14:58:02 -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 OAA11616; Thu, 26 Jul 2001 14:57:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6QLu1U06177 for mobile-ip-dist; Thu, 26 Jul 2001 14:56:01 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6QLtwY06170 for ; Thu, 26 Jul 2001 14:55:58 -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 OAA11347 for ; Thu, 26 Jul 2001 14:56:13 -0700 (PDT) Received: from zcars0m9.ca.nortel.com ([47.129.242.157]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA23813 for ; Thu, 26 Jul 2001 15:57:30 -0600 (MDT) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f6QLtg917390 for ; Thu, 26 Jul 2001 17:55:42 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Thu, 26 Jul 2001 17:55:46 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Jul 2001 17:55:51 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5E98@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Analysis of Jitter in Bicasting Date: Thu, 26 Jul 2001 17:55:53 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1161D.BDAF27C0" X-Orig: 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_01C1161D.BDAF27C0 Content-Type: text/plain; charset="iso-8859-1" I agree with you Michael, but with the caveat that we must consider that many of these hosts will be small, low power, light weight devices, not 1GHz processor, 256MRAM workstations (or, maybe PDAs will have 1GHz/256M in them the time this all gets deployed *ponder*). My point being that while I am also against PEPs, we have to be careful of pushing things out to the host, at least on the wireless side? Gary > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: July 26, 2001 14:21 > To: mobile-ip@sunroof.eng.sun.com > Subject: RE: [mobile-ip] Analysis of Jitter in Bicasting > > > George Tsirtsis writes: > > I think you are making the point that - end hosts already deal with > > duplicate packets since this is a natural occurrence in > the Internet today > > so bicasting should not be a problem - > > > > The difference is that end nodes deal with duplicate > packets up to a > > point...i.e.: up to 3 re-orderings/losses etc generating 3 > dupacks in a row, > > before TCP starts having problems. The fact that TCP deals > with 3 dupacks > > and not with 5 or 10 or 100 was an engineering choice that balances > > adaptivity and throughput with the chances of this > happening in the Internet > > or they just picked a number from thin air...wouldn't > know...was not here > > :-) > > > > My argument is that bicasting, increases the chances of > duplication on top > > of what the Internet naturally does and that could have > bad effects if in > > widespread use. Say for example, due to natural > re-ordering somewhere in the > > Internet, a node is about to receive 2 TCP acks, which TCP > can actually deal > > with no problems. At the same time the MN's packets are > duplicated (due to > > bicasting) at the receiving end, which results in the MN > receiving 4 TCP > > acks! This forces TCP to half its window thinking that > there must be > > congestion in the network and the packets do not get > across which is clearly > > not the case! > > > > So, the objections here are not about being able to "deal" > with re-ordering > > as it naturally occurs but that we should not introduce > mechanisms that > > artificially increase the chance duplicate acks. > > George, > > First off, disclaimer: I'm neutral on both > buffering and bicasting. > > My point was simply that we not try to perform any > unnatural acts in the middle of the network to > hide jitter and duplication from the end > hosts. Yes, I agree that that will cause many > TCP's to barf, but the right thing to do is to fix > the TCP, not hide it in the network. In fact, the > effects of bicasting would only affect mobile > nodes, and I'd assume that ones which were the > targets of bicasting would have a fair amount of > incentive to deal with this inevitability. Were it > a possibility toward any random CN, then I'd > probably have a different opinion, but that > doesn't seem to be the case. > > Mike > ------_=_NextPart_001_01C1161D.BDAF27C0 Content-Type: text/html; charset="iso-8859-1" RE: [mobile-ip] Analysis of Jitter in Bicasting

I agree with you Michael, but with the caveat that we must
consider that many of these hosts will be small, low power,
light weight devices, not 1GHz processor, 256MRAM workstations (or,
maybe PDAs will have 1GHz/256M in them the time this all gets
deployed *ponder*).

My point being that while I am also against PEPs, we have to be
careful of pushing things out to the host, at least on the wireless
side?

Gary

> -----Original Message-----
> From: Michael Thomas [mailto:mat@cisco.com]
> Sent: July 26, 2001 14:21
> To: mobile-ip@sunroof.eng.sun.com
> Subject: RE: [mobile-ip] Analysis of Jitter in Bicasting
>
>
> George Tsirtsis writes:
>  > I think you are making the point that - end hosts already deal with
>  > duplicate packets since this is a natural occurrence in
> the Internet today
>  > so bicasting should not be a problem -
>  >
>  > The difference is that end nodes deal with duplicate
> packets up to a
>  > point...i.e.: up to 3 re-orderings/losses etc generating 3
> dupacks in a row,
>  > before TCP starts having problems. The fact that TCP deals
> with 3 dupacks
>  > and not with 5 or 10 or 100 was an engineering choice that balances
>  > adaptivity and throughput with the chances of this
> happening in the Internet
>  > or they just picked a number from thin air...wouldn't
> know...was not here
>  > :-)
>  >
>  > My argument is that bicasting, increases the chances of
> duplication on top
>  > of what the Internet naturally does and that could have
> bad effects if in
>  > widespread use. Say for example, due to natural
> re-ordering somewhere in the
>  > Internet, a node is about to receive 2 TCP acks, which TCP
> can actually deal
>  > with no problems. At the same time the MN's packets are
> duplicated (due to
>  > bicasting) at the receiving end, which results in the MN
> receiving 4 TCP
>  > acks! This forces TCP to half its window thinking that
> there must be
>  > congestion in the network and the packets do not get
> across which is clearly
>  > not the case!
>  >
>  > So, the objections here are not about being able to "deal"
> with re-ordering
>  > as it naturally occurs but that we should not introduce
> mechanisms that
>  > artificially increase the chance duplicate acks.
>
> George,
>
> First off, disclaimer: I'm neutral on both
> buffering and bicasting.
>
> My point was simply that we not try to perform any
> unnatural acts in the middle of the network to
> hide jitter and duplication from the end
> hosts. Yes, I agree that that will cause many
> TCP's to barf, but the right thing to do is to fix
> the TCP, not hide it in the network. In fact, the
> effects of bicasting would only affect mobile
> nodes, and I'd assume that ones which were the
> targets of bicasting would have a fair amount of
> incentive to deal with this inevitability. Were it
> a possibility toward any random CN, then I'd
> probably have a different opinion, but that
> doesn't seem to be the case.
>
>            Mike
>

------_=_NextPart_001_01C1161D.BDAF27C0-- From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 26 18:01:06 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA16413 for ; Thu, 26 Jul 2001 18:01:05 -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 PAA28893; Thu, 26 Jul 2001 15:01:31 -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 PAA12820; Thu, 26 Jul 2001 15:01:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6QLxcY06242 for mobile-ip-dist; Thu, 26 Jul 2001 14:59:38 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6QLxZY06235 for ; Thu, 26 Jul 2001 14:59:35 -0700 (PDT) Received: from heliopolis.eng.sun.com (pacrimapp2.Singapore.Sun.COM [129.158.124.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA07034; Thu, 26 Jul 2001 14:59:26 -0700 (PDT) From: James Kempf Message-Id: <200107262159.OAA07034@heliopolis.eng.sun.com> Date: Thu, 26 Jul 2001 14:55:55 -0700 To: , "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Analysis of Jitter in Bicasting X-Mailer: Sun NetMail 2.3 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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Gary, > I'm not sure that comparing handover latencies with 2, 2.5, or 3G >is all that relevant. With soft handover, there is theoretically, >no latency, although I suspect that there are exceptions - I'm checking >to see if there are published numbers. I have heard some atrociously >poor numbers for packet data, but I won't repeat them here because >they are not verifiable. > My point is that users have a given level of service with 2.5G. If we come to the 3Gs and say "we've got mobile IP handover figured out, but hard handover times are 1.5 sec instead of 200 ms, so users are going to notice when a hard handover occurs" they are less likely to be interested in deploying VoIP to the handset. > The issue with packet data, and the reason that the latency starts to >look bad, is that soft handover is extremely difficult to do with shared >channels, datagrams and a routed network (i.e. the issues are not all >that different from the issues being discussed with respect to bicasting). Well, after having spent the last year looking at soft handover in IP RANs, I am not convinced that this is the case. Soft handover is an L2 issue, once the packet pops out of the macrodiversity combiner (or goes in), it's exactly like getting it out of or putting it into a router that's connected to an optical network or any other L2. Sure, there are issues of isochrony w.r.t. getting the radio frames from the macrodiversity combining point to the radio access points, but these need to be handled by properly designing the L1/L2 in the RAN, regardless of whether IP or ATM is used as the transport. But we should probably take this to a separate thread. >IMHO 2-3G networks are not well suited to IP services because they were not >designed to switch packets fast across the channel (by fast I mean ms, not >10s or 100s of ms). Ultimately, this channel access delay may be the >real pacer for handover, not the mobility solution. > The PDSN/GGSN designs seem a bit on the heavy weight side. If/when we get this handover story straigtened out, perhaps we can move the routing point at least as far as the RAN controller. > Enough doom and gloom. In anticipation of a different approach in 4G, >there is little information on how to allocate an appropriate "latency >budget" across the network. I know that the transit delays for North >America for single operator networks have been dropping steadily, and are >well below 100 ms (I've heard numbers as low as 50 ms, but I haven't had >a chance to check the latest). > > So, if its 50 ms transit delay, that leaves approximately 30 ms for each >access network for one leg of a two way conversation. Not a heck of a lot >of time. Of course, it is arguable that you can asymmetrically allocate >the budget between access networks, as it is unlikely that they will both >need the maximum budget at the same instant (e.g. if both access networks >are wireless, it is unlikely that both will be in the process of handing >over >at the same time). > Agreed. > BTW: I did not checked the ITU spec, but 300 ms is as good as 250 ms, >certainly >as far as these discussions are concerned. End to end latency bounds are >determined by the desired quality of the voice service, and usually are >based upon empirical measurements from subjective quality tests (the ITU >numbers are). >The numbers from these tests, called Mean Opinion Scores, have a very high >variance, and the real quality difference caused by an increase in latency >from >250 to 300 ms is not easily detected (which means you probably can drop >the 0.5 from 112.5 ;^} ). One has to be careful in some respects, because >there >are thresholds where a majority of listeners can detect significant changes >in >quality (humans being largely non-linear systems), but if I believe the >first >threshold is upwards towards 500 ms, as someone else has mentioned. > > I've heard the upper threshold is around 600 ms when the conversation really starts to sound half duplex. One thing concerns me though: should we be using RTT or single leg? I've been using RTT in my calculations, because if the mobile is out of contact or busy downloading a buffer, then it would be so for both directions. In any event, I think we need to use the delay budget for the access network alone, which removes the delay across the backbone and in the other access network. jak From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 26 18:16:56 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA17393 for ; Thu, 26 Jul 2001 18:16:55 -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 QAA18051; Thu, 26 Jul 2001 16:17: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 PAA26982; Thu, 26 Jul 2001 15:17:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6QMFqG06374 for mobile-ip-dist; Thu, 26 Jul 2001 15:15:52 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6QMFmY06367 for ; Thu, 26 Jul 2001 15:15:48 -0700 (PDT) Received: from heliopolis.eng.sun.com (pacrimapp2.Singapore.Sun.COM [129.158.124.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA07786; Thu, 26 Jul 2001 15:15:43 -0700 (PDT) From: James Kempf Message-Id: <200107262215.PAA07786@heliopolis.eng.sun.com> Date: Thu, 26 Jul 2001 15:12:08 -0700 To: , Subject: Re: [mobile-ip] Handover Smoothing - What to Do? X-Mailer: Sun NetMail 2.3 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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Rajeev, I don't understand why there needs to be dual contexts at the MN. In the single interface case, the MN is only connected to one AP/AR at a time. And, it is sequentially connected to oAR then nAR, unless a ping-pong occurs. So if CT is available, oAR simply sends the compression context to nAR when the bicast stream is started, then runs the compression algorithm until MN shows up and it can start getting packets. The compressor context on MN just keeps working, since the CT causes the state on the nAR side to start out the same as on the oAR. The MN drops the old L2 bicast leg when it aquires the new L2 leg through nAR. Last time I talked with the ROHC guys (at IETF 50), they seemed OK with this. The fact that MIPv6 changes CoA after handover was giving them more heartburn, but that won't be a problem until the MN actually completes new CoA aquisition. Before that the packets should be coming with the old CoA either from the oAR (if you are using the tunnelling approach) or from the remote agent (if you are using the simultaneous bindings approach). Regarding if bicasting should be part of FMIPv6, I agree that it should be separated out until we have a better understanding of the issues. The tougher issue (and the one I think we are debating) is whether we should make the low latency MIPv4 spec consistent by also separating it out. I am in favor of consistency, perhaps as a consequence of my long Germanic ancestory (== a genetic predisposition towards liking things orderly as opposed to chaotic). jak >James, > >Could you be more specific ? I mentioned that the new-AR *could* do it if it >got the context (e.g., via CT). But that's not it. It means dual contexts at >the MN for downlink. And, synchronization issue for uplink contexts (since >the MN is communicating with old-AR). > >Again, here is the point: these are the issues surrounding how to get >bicasting to work with FMIPv6. This MUST NOT be part of FMIPv6. More >generally, FMIPv6 must not depend on a particular smoothing technique. > >I hope you understand and agree as well! > >Regards, > >-Rajeev > > >James Kempf wrote: > >> Right, having the new AR compress was what I had in mind. >> >> jak >> >> >Gary Kenward writes: >> > > Rajeev: >> > > >> > > Is one answer that the old AR could send uncompressed packets >> > > to the new AR, and the new AR would then compress the packets or >> > > not, depending on whether it had the context (there is a an case >> > > to be made here for proactive ct ;^}). Depending on what was actually >> > > sent over the air, this could create a tricky problem to solve >> > > at the MN, as it may need to process the two streams before it could >> > > even attempt duplicate removal, and this would require two compression >> > > state machines, buffers, etc., etc. Not nice. >> > >> > It may not be nice, but I believe it comes with the >> > territory. The alternative is to miss packets during >> > the transition that you might have otherwise been >> > able to recover. For mobile initiated >> > break-before-make scenarios, you obviously >> > don't want to allow any otherwise valid packets >> > to be dropped making the situation worse. >> > >> > Mike > From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 26 18:27:32 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA18029 for ; Thu, 26 Jul 2001 18:27: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 QAA24156; Thu, 26 Jul 2001 16:28: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 PAA28782; Thu, 26 Jul 2001 15:27:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6QMQZd06470 for mobile-ip-dist; Thu, 26 Jul 2001 15:26:36 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6QMQWY06463 for ; Thu, 26 Jul 2001 15:26:32 -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 PAA15319 for ; Thu, 26 Jul 2001 15:26:45 -0700 (PDT) Received: from mailsys01.intnet.net (mailhost.wwc.com [198.252.32.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA23441 for ; Thu, 26 Jul 2001 16:26:43 -0600 (MDT) Received: from [206.112.107.99] ([206.112.107.99] verified) by mailsys01.intnet.net (CommuniGate Pro SMTP 3.4.8) with ESMTP id 12104870 for mobile-ip@sunroof.eng.sun.com; Thu, 26 Jul 2001 18:26:10 -0400 Mime-Version: 1.0 X-Sender: ahmrphd@pop3.attglobal.net Message-Id: In-Reply-To: <9FBD322B7824D511B36900508BF93C9C9F5E96@zcard031.ca.nortel.com> References: <9FBD322B7824D511B36900508BF93C9C9F5E96@zcard031.ca.nortel.com> Date: Thu, 26 Jul 2001 15:23:57 -0700 To: mobile-ip@sunroof.eng.sun.com From: Arthur Ross Subject: RE: [mobile-ip] Analysis of Jitter in Bicasting 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 17:38 -0400 07/26/2001, Gary Kenward wrote: > >The numbers from these tests, called Mean Opinion Scores, have a very high >variance, and the real quality difference caused by an increase in >latency from >250 to 300 ms is not easily detected (which means you probably can drop >the 0.5 from 112.5 ;^} ). One has to be careful in some respects, >because there >are thresholds where a majority of listeners can detect significant changes in >quality (humans being largely non-linear systems), but if I believe the first >threshold is upwards towards 500 ms, as someone else has mentioned. > Vocoder folklore, and some old Bell Labs research on the subjective effects of delay and echo on listener perception, would suggest that these begin to be objectionable around 100 ms. Around 250 ms is of the order of one geosynchronous satellite hop; delay that large tends to be subjectively VERY objectionable. Not that people can't learn to cope with it (as they do when calling to the few remaining places where ol' fashioned PSTN access is by satellite - example most familiar to me: USA to/from India). The sensitivity to echo rises with magnitude of delay (for those of you who are NOT old Bell-heads, the echo LEVEL in the typical local analog voice call is VERY large, but not noticed because its DELAY is VERY SMALL). This is the reason for all the technology devoted to echo suppression/cancellation on long-distance calls over the years (the former was just a dumb level-dependent switch that makes the connection essentially half-duplex; the latter, more modern, is adaptive signal processing that really subtracts off the echos). My personal belief has long been that this is all connected with biologically programmed timeouts in the human brain. For example, the feeling that one gets, watching one of those satellite remotes on the evening TV news - one is always left with the impression that the remote reporter is somehow retarded, or otherwise a couple of cards short of a full deck, due to the large delay. There is an intrinsic, programmed by nature, human brain expectation of how long a person should take to react in a verbal dialog; exceeding that delay leads to bogus electro-socio-linguistic-psychological conclusions. It is very annoying in trying to conduct a conversation. Average folks, faced with large delay in a call, will typically notice that there is something wrong, but will be hard pressed to identify what it is. And yes, the MOS (mean opinion score) is notoriously hard to pin down; it is, by construction, entirely subjective: you simply ask subjects their opinion of something on a 1 to 5 scale, and try to reduce the variance by averaging over a large number of subjects. Trying to attach too much objective scientific meaning to ANY MOS is both futile and meaningless ... although such attempts are frequently encountered in the world of telecom, often connected with exaggerated marketing claims for one or another technology. Rough summary: Net delay below 50-100 ms tends to be ok; more than that is increasingly objectionable as the magnitude increases (500 ms is WAY too much for public voice telephony). And don't throw away those echo cancellers in the PSTN plant. Again, just my 2 cents ... -- ahmr From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 26 18:35:41 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA18428 for ; Thu, 26 Jul 2001 18:35:40 -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 PAA13881; Thu, 26 Jul 2001 15:36: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 PAA00556; Thu, 26 Jul 2001 15:34:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6QMXdi06545 for mobile-ip-dist; Thu, 26 Jul 2001 15:33:39 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6QMXZY06538 for ; Thu, 26 Jul 2001 15:33:35 -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 PAA08516 for ; Thu, 26 Jul 2001 15:33:48 -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 QAA10888 for ; Thu, 26 Jul 2001 16:35:14 -0600 (MDT) 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 f6QMXog06565 for ; Thu, 26 Jul 2001 15:33: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 AAW42731; Thu, 26 Jul 2001 15:33:44 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA11136; Thu, 26 Jul 2001 15:33:44 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15200.39624.541505.857983@thomasm-u1.cisco.com> Date: Thu, 26 Jul 2001 15:33:44 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Analysis of Jitter in Bicasting In-Reply-To: <9FBD322B7824D511B36900508BF93C9C9F5E98@zcard031.ca.nortel.com> References: <9FBD322B7824D511B36900508BF93C9C9F5E98@zcard031.ca.nortel.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 Gary Kenward writes: > I agree with you Michael, but with the caveat that we must > consider that many of these hosts will be small, low power, > light weight devices, not 1GHz processor, 256MRAM workstations (or, > maybe PDAs will have 1GHz/256M in them the time this all gets > deployed *ponder*). > > My point being that while I am also against PEPs, we have to be > careful of pushing things out to the host, at least on the wireless > side? I seriously doubt that a few small tweaks to the TCP stack -- as I imagine that EIFEL is -- should be the basis of any decision. Mike From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 26 18:39:46 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA18702 for ; Thu, 26 Jul 2001 18:39: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 QAA02558; Thu, 26 Jul 2001 16:40: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 PAA01759; Thu, 26 Jul 2001 15:40:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6QMdG606648 for mobile-ip-dist; Thu, 26 Jul 2001 15:39:16 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6QMdDY06641 for ; Thu, 26 Jul 2001 15:39:13 -0700 (PDT) Received: from heliopolis.eng.sun.com (pacrimapp2.Singapore.Sun.COM [129.158.124.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA08719; Thu, 26 Jul 2001 15:39:04 -0700 (PDT) From: James Kempf Message-Id: <200107262239.PAA08719@heliopolis.eng.sun.com> Date: Thu, 26 Jul 2001 15:35:33 -0700 To: , Subject: Re: [mobile-ip] Handover Smoothing - What to Do? X-Mailer: Sun NetMail 2.3 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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit >Sounds unnecessary, especially for implementing FMIPv6. Bicasting must >not be part of FMIPv6. > Nor should buffering! And likewise for low latency MIPv4. jak From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 26 18:42:45 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA18925 for ; Thu, 26 Jul 2001 18:42:44 -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 PAA17014; Thu, 26 Jul 2001 15:43: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 PAA02018; Thu, 26 Jul 2001 15:41:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6QMeIh06674 for mobile-ip-dist; Thu, 26 Jul 2001 15:40:18 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6QMeEY06667 for ; Thu, 26 Jul 2001 15:40:14 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA18239 for ; Thu, 26 Jul 2001 15:40:27 -0700 (PDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA13585 for ; Thu, 26 Jul 2001 15:40:25 -0700 (PDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f6QMeX318369 for ; Thu, 26 Jul 2001 15:40:34 -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 AAW42962; Thu, 26 Jul 2001 15:40:23 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA11139; Thu, 26 Jul 2001 15:40:23 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15200.40023.162646.713784@thomasm-u1.cisco.com> Date: Thu, 26 Jul 2001 15:40:23 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Analysis of Jitter in Bicasting In-Reply-To: <9FBD322B7824D511B36900508BF93C9C9F5E97@zcard031.ca.nortel.com> References: <9FBD322B7824D511B36900508BF93C9C9F5E97@zcard031.ca.nortel.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 Gary Kenward writes: > Sorry for the confusion. I agree that if you are willing > to accept duplicates, much of the problem goes away. However, > duplicate removal can be a tad nasty for real time services, > depending upon the time latency between received copies. Why so? You get the same SSRC, same timestamps, etc, and there's already in that slot, you ditch it. Doesn't sound very complicated to me. Also: it's already required in any implementation since UDP doesn't make any guarantees about delivery including duplicates. > That > is, if you know that the duplicates always arrive together, > then you can use a very short (two packet) buffer, but if the > duplicates can be 10s of packets apart, not only do you need > more memory, but you likely have to spend more time searching the > buffer for duplicates. This search time is usually the main > difficulty for real time duplicate removal. You already need a jitter buffer to smooth out jitter over the net in general, so this comes for free. Frankly, RTP traffic is probably the least of considerations with bicasting. Mike From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 26 19:05:55 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA20417 for ; Thu, 26 Jul 2001 19:05:50 -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 QAA26198; Thu, 26 Jul 2001 16:06: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 QAA07118; Thu, 26 Jul 2001 16:04:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6QN3e107008 for mobile-ip-dist; Thu, 26 Jul 2001 16:03:40 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6QN3bY07001 for ; Thu, 26 Jul 2001 16:03:37 -0700 (PDT) Received: from heliopolis.eng.sun.com (pacrimapp2.Singapore.Sun.COM [129.158.124.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA09811 for ; Thu, 26 Jul 2001 16:03:33 -0700 (PDT) From: James Kempf Message-Id: <200107262303.QAA09811@heliopolis.eng.sun.com> Date: Thu, 26 Jul 2001 15:59:54 -0700 To: Subject: Re: [mobile-ip] Analysis of Jitter in Bicasting X-Mailer: Sun NetMail 2.3 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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Michael, OK, so it sounds to me like the delay budget is even *worse* for buffering than I thought. 300 ms is being generous. The numbers Gary and Arthur were quoting seemed to be pointing in that direction. It is beginning to sound more and more as if neither buffering nor bicasting will do the trick. As you say, perhaps we should simply just get the tunnel up as fast as possible and drop anything that comes in during L2 handover. jak >Comments in line .. Michael Ramalho > >At 03:15 PM 7/25/2001 -0700, James Kempf wrote: >>Vijay, >> >> >> >> >> Um, so what happens to the real time packets while the FBACK is getting >> >> buffered? And how do you know that the FBACK will arrive and should >> >> be buffered exactly during L2 handover? It could arrive before, it >> >> could arrive after. What about the rest (minimum 4 at my count) >> >> packets involved in FMIP handover before the MN gets to start >> >> doing DAD (over the air), etc., on the new AR before it can >> >> start getting its real time traffic? >> > >> >i lost you. it doesnt matter when the FBack arrives at the newAR, >> >the newAR has to buffer it till the MN shows up. the newAR doesnt >> >know if the MN got the FBack while it was still attached to the >> >oldAR. >> > >> >>What I'm saying is that if there is more than a 300 ms gap in >>a real time voice stream, the user notices a click. If the gap >>propagates forward, so that there is more than a 300 ms delay >>in the real time traffic, then the conversation begins to >>sound like half duplex. > >Jim, > >I noticed this 300 ms assumption in your draft. However, you will >probably notice a pop/click long before 300 ms (assuming there is >coded voice/music coming toward you during this time). This depends >on the error concealment algorithms in the codec for lost/delayed >packets. > >For example, depending on if you were in the middle of a long >voiced vowel - which is more forgiving - or short duration/energy >fricative or plosive - like a "b" or "p" - which becomes completely lost >in the lost packet. Thus sixty ms of loss in the middle of a vowel >can be easily concealed (six G.729 frames - usually three packets >worth), whereas the same time loss during a low energy fricative is >completely lost. Then you say ... what did you say? ... unless >you have good word interpolation skills. > >The bottom line is that if the jitter buffer gets a packet after its >playback time ... it is lost for the purposes of meaningful playback >(I think Phil tried to bring this point out a few days ago). Having >good heuristics for the buffer management in this environment is >very important (Mike Thomas brought out this point a few days >ago as well). > >The "worse case" 300 ms ITU number was an end-to-end number >for delay budgeting - not an "additive jitter before delays become >noticeable" number. In that sense, you misrepresented its meaning. > >After 300 ms of one way delay ... interactive communications becomes >almost impossible (becomes increasingly toward a half-duplex >conversation). A satellite connection has a minimum of 512 ms >round trip delay - which is half-duplex for me. > >Fortunately ... most of the coding is non-speech (e.g., silence/background >noise) and most of the "remaining real speech" is voiced ... so we have >some statistics working for us during handoff additive delays. > >Lets just get the handoff/tunnels up as fast as we can .... > >Michael Ramalho > > >>The number I gave of 112.5 ms is the maximum amount time on a 9.6 kbps >>uplink that buffering can be done before the 300 ms bound is exceeded. >>For the scenarios calculated in Appendix A of draft-kempf-beth-ipv6-01.txt, >>which I think are about the minimum traffic for an FMIPv6 handover >>(somebody please correct me if I am wrong), the minimum L3 handover time >>is 133 >>ms. This already exceeds the buffering bound. >> >>The FBACK isn't strictly necessary for the MN to start getting >>real time traffic right away after handover (and, frankly, that >>is really all that counts if you want the user not to notice). The >>FBACK is only necessary to complete new CoA aquisition. The MN >>can get its real time traffic through a tunnel from the old AR >>using its old CoA then finish new CoA aquisition whenever. That is what >>draft-kempf-beth-ipv6-01.txt advocates, and it is envisioned in >>draft-ietf-mobileip-fast-mipv6-01.txt as a corner case. >> >>So if you want to buffer and you've got real time traffic, your choices are: >> >> 1) Use FMIPv6 handover and crank the uplink data rate up until you can >> download >> the buffer fast enough over the air from the new AR to not have the latency >> propogate. >> >> 2) Use BETH handover if the L2 handover time is less than 112.5 ms (for >> a 9.6 kbps downlink data rate). >> >>Otherwise, if L2 handover is too large for 2) or you can't crank the >>data rate, you are better off dropping the packets. >> >> jak > > >Michael A. Ramalho, Ph.D. >Office email: mramalho@cisco.com >Personal email: mar42@cornell.edu >Summer Office: +1.941.923.1203 (July/Aug 2001) >Office: +1.732.449.5762 >Cell: +1.732.809.0188 > From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 26 19:14:09 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA20936 for ; Thu, 26 Jul 2001 19:14:04 -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 DAA20447; Thu, 26 Jul 2001 03:56:15 -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 CAA21019; Thu, 26 Jul 2001 02:55:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6Q9ss300596 for mobile-ip-dist; Thu, 26 Jul 2001 02:54:54 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6Q9soY00589 for ; Thu, 26 Jul 2001 02:54:50 -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 CAA08565 for ; Thu, 26 Jul 2001 02:55:04 -0700 (PDT) Received: from sonne.darmstadt.gmd.de (sonne.darmstadt.gmd.de [141.12.62.20]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA19805 for ; Thu, 26 Jul 2001 03:55:02 -0600 (MDT) Received: from ipsi.fraunhofer.de (pc-morion [141.12.35.155]) by sonne.darmstadt.gmd.de (8.8.8/8.8.5) with ESMTP id LAA17844; Thu, 26 Jul 2001 11:54:57 +0200 (MET DST) Message-ID: <3B5FE9EC.23C4F010@ipsi.fraunhofer.de> Date: Thu, 26 Jul 2001 11:59:08 +0200 From: Wolfgang Schoenfeld Organization: FhG IPSI X-Mailer: Mozilla 4.7 [de] (WinNT; I) X-Accept-Language: en,de MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] WG feedback on bicasting References: <795A014AF92DD21182AF0008C7A404320C52048A@esealnt117> 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 "Karim El-Malki (ERA)" schrieb: > > Hello Wolfgang > > > Another (the only?) way is guessing the emergence of a new link, > > i.e. taking outer "oracles" like layer 2 events, statistics > > etc. into account. > > That's the approach taken in FMIP (low-latency & fast handover drafts). > I wouldn't consider link-layer "triggers" as statistics or guesses. > They are messages from/at L2 which can "warn" the receiver in > anticipation of a handoff event. So it's not a guess, the handoff > will be or is being performed at L2. Note that an L2 handoff does > not always mean a L3 handoff, so it is up to the L3 receiver of > the trigger to determine whether FMIP is needed. The anticipation > time instead will be dependent on the L2 system. Maybe, "oracle" is more appropriate than "guess" since its meaning is well-known: The operations of the model your are considering (here: Layer 3 handoff) are affected by some information/trigger from the outside. > > > In this case, bicasting can indeed make sense > > if the guess does not give a unique answer: > > Just multicast to all nodes which the guess predicts. > > (Broadcast would result from the most vague guess.) > > This increases the probability that all packets reach MN. > > You can have simultaneous bindings with multiple COAs. > So that gives the same result as multicasting without > the need to join groups. Are you sure? Simultaneous binding is a matter of FA's whereas multicasting can originate soemwhere else. > > > > > Note however that multicast is concerned only with vagueness > > of guesses - > > if they are precise, multicasting does have not have any effect. > > Hence, fast handover without bicasting > > (your original question) does make sense. > > > > I'm not sure whether the above is now "gap-free". Hence, > > please comment. > > It is not gap free since, assuming anticipated triggers and > registrations (i.e. FMIP) you have no knowledge as to when the > L2 handoff event occurs with respect to the moment the HA or > local HA receives the BU/registration. So if the COA is updated > too late or too early with respect to the L2 handoff event, > the MN will find itself unable to communicate. That is what > FMIP is trying to avoid. If you assume that the predictions of the L2 "oracle" are imprecise, i.e. the "oracle" is unsure WHERE a link will come up, then, from what I said, it follows that bicasting will in general have an effect on L3 handoff. On the other hand, unsureness of WHEN L2 "oracle" acts does not suffice as a justification for bicasting. Wolfgang > > Regards > /Karim -- Wolfgang Schoenfeld, Fraunhofer IPSI, Dolivostr. 15, D-64293 Darmstadt Office: +49-6151-869-865 FAX: -6847 Mobile: +49-174-7093455 From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 26 19:50:53 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA23795 for ; Thu, 26 Jul 2001 19:50:53 -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 QAA12347; Thu, 26 Jul 2001 16:51:25 -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 QAA02235; Thu, 26 Jul 2001 16:51:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6QNoF407554 for mobile-ip-dist; Thu, 26 Jul 2001 16:50:15 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6QNoBY07547 for ; Thu, 26 Jul 2001 16:50:11 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA24323 for ; Thu, 26 Jul 2001 16:50:25 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA14570 for ; Thu, 26 Jul 2001 16:50: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 QAA16147 for ; Thu, 26 Jul 2001 16:50:24 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6QNoOF12681 for ; Thu, 26 Jul 2001 16:50:24 -0700 X-mProtect: Thu, 26 Jul 2001 16:50:24 -0700 Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdDBPRwT; Thu, 26 Jul 2001 16:50:22 PDT Message-ID: <3B60ACBE.FCCCBD1B@iprg.nokia.com> Date: Thu, 26 Jul 2001 16:50:22 -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: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Handover Smoothing - What to Do? References: <200107262236.PAA08640@heliopolis.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 Hello again James, James Kempf wrote: > Hi Rajeev, > > I believe you misunderstood me. I am not advocating that smoothing be added > to the current FMIPv6. I think we should have smoothing be a separate item. > I also think it should be taken out of the low latency MIPv4 spec. There > are some WG members I've talked to who don't believe smoothing is actually > needed if the latency is kept low enough (for example, for BETH it will > only be the L2 latency, no L3 latency at all). I am not of that opinion, however, > I think that some smoothing technique requiring perhaps both may be needed in most > cases, but only implementation experience will really tell. > Ok. Glad that we are on the same page. > > W.r.t. buffering, there has been alot of focus on the drawbacks of bicasting. > Things are not so golden with respect to buffering, however. As I've tried > to mention in a couple of emails, if you buffer during handover, the latency > propagates. When you download the buffer to the MN, you need to buffer until > the download is finished, etc. There's no free lunch, those real time packets > keep coming in. > The actual process depends however on the end-to-end network dynamics. For example, if there is a talkspurt during handover followed by an idle time, then you could drain the buffer without actually propagating the delay per se. You might affect the start time of the *next* talkspurt however, in the sense that the idle time is not exactly the same as that of the sener's. However, this is not a big deal in packet networks with jitter buffers and smart playback adjustment. Regards, -Rajeev > > If you take that into account, you end up getting some pretty strict bounds > on what you can do for real time traffic. This is the discussion that > Gary and I were having about delay budget. Buffering essentially prolongs > the handover latency as the subsequent buffering periods are downloaded. > There's an analysis in Appendix B of draft-kempf-beth-ipv6-01.txt if you > care to check it > > jak > > >Hello James, > > > > > >James Kempf wrote: > > > >> Hi Phil, > >> > >> >There does seem to be some consensus that if a smoothing technique is chosen > >> >it should be through bicasting or simultaneous binding rather than some kind > >> >of > >> >buffering. At the minimum we should have a discussion of why the tradeoff > >> >of > >> >accepting the possibility of duplicate packets weighs more heavily than > >> >accepting > >> >the possibility of lost packets and the results should be documented. > >> > > >> > >> I have not heard much from advocates of buffering in the discussion > >> so far, so I would have to agree. > >> > >> > > > >I don't understand your viewpoint. Just because you have not heard from > >buffering advocates does not imply that the alternative is the way to go. There > >are at least two things to consider. First, you are proposing to add a > >particular smoothing technique to FMIPv6. I am registering my complaint saying > >that it is not the right thing to do. FMIPv6 must be able to work independently > >of bicasting. I have provided the problems stemming from header compression as > >an example to illustrate the added complexity. Second, taking up smoothing as a > >topic by itself, it is not a foregone conclusion that bicasting/simultaneous > >binding are the only means. This is an open area and we need discussion and > >*real experimental* evidence. Also, the header compression example hold here as > >well. > > > >Regards, > > > >-Rajeev > > > > > > > >> >George has also asserted (and speaking for myself personally I also agree > >> >with) > >> >that implementations in some environments at least can solve this without > >> >any kind > >> >of protocol support at layer 3. > >> > > >> > >> I agree also. > >> > >> >Does this seem to summarize everyone's position accurately? Does this > >> >answer your question > >> >enough, Jim? > >> > > >> > >> Yes, thanx. > >> > >> >Of course, others contributing to the conversation COULD help, > >> > >> Agree. > >> > >> jak > > From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 26 20:08:27 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA24895 for ; Thu, 26 Jul 2001 20:08:26 -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 RAA17652; Thu, 26 Jul 2001 17:08: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 RAA05351; Thu, 26 Jul 2001 17:08:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6R07WH07766 for mobile-ip-dist; Thu, 26 Jul 2001 17:07:32 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6R07SY07759 for ; Thu, 26 Jul 2001 17:07:28 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA18425 for ; Thu, 26 Jul 2001 17:07:42 -0700 (PDT) Received: from mail.lge.com ([156.147.1.150]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA20269 for ; Thu, 26 Jul 2001 17:07:41 -0700 (PDT) Received: from lgekrhqmh01.lge.com (lgekrhqmh01.lge.com [156.147.51.51]) by mail.lge.com (8.8.4_hhk9703/8.6.9) with ESMTP id JAA07945 for ; Fri, 27 Jul 2001 09:04:10 +0900 (KST) Received: from aeb099w ([150.150.60.99]) by lgekrhqmh01.lge.com (Lotus Domino Release 5.07a) with SMTP id 2001072709073112:109079 ; Fri, 27 Jul 2001 09:07:31 +0900 Message-ID: <000b01c1162f$6aeaa0c0$633c9696@aeb099w> From: "Kim Taeyong" To: References: <476F91F7CFDBD41182E000D0B7E7E693B9ACF6@U9JM7> <3B60235F.1DE13A77@usa.alcatel.com> Subject: Re: [mobile-ip] A question about 'traceroute' Date: Fri, 27 Jul 2001 09:02:25 +0900 MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-MIMETrack: Itemize by SMTP Server on LGEKRHQMH01/LGE/LG Group(Release 5.07a |May 14, 2001) at 07/27/2001 09:07:31 AM, Serialize by Router on LGEKRHQMH01/LGE/LG Group(Release 5.07a |May 14, 2001) at 07/27/2001 09:07:48 AM, Serialize complete at 07/27/2001 09:07:48 AM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by sunroof.eng.sun.com id f6R07TY07760 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 Hi. I think traceroute program works. But wholl path not detectable. Nodes exists in FA-HA tunnel can not be traced. ex) CN send ICMP packet by incrementing TTL=1, 2, 3, ....(TTL decrease ) Then HA encapsulate ICMP message do not decrease TTL, and send the packet through the tunnel between HA and FA(TTL decrease ) FA decapsulate the packet and send to MN,(TTL decrease ) Finally, MN send ICMP Port Unreachable message to CN. Then traceroute ends. From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 26 21:18:19 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA27475 for ; Thu, 26 Jul 2001 21:18:19 -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 TAA20406; Thu, 26 Jul 2001 19:18:49 -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 SAA28406; Thu, 26 Jul 2001 18:18:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6R1HNV08200 for mobile-ip-dist; Thu, 26 Jul 2001 18:17:23 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6R1HKY08193 for ; Thu, 26 Jul 2001 18:17:20 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id SAA15569 for ; Thu, 26 Jul 2001 18:17:35 -0700 (PDT) Message-Id: <200107270117.SAA15569@heliopolis.eng.sun.com> Date: Thu, 26 Jul 2001 18:17:33 -0700 (PDT) From: James Kempf Subject: Re: [mobile-ip] Handover Smoothing - What to Do? To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: pe0HyNbwX6U+zdzbNVn/ww== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 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: Hi Rajeev, >> I don't follow. If the old AR gets the trigger for context transfer >> soon enough, it can send the header compression state to the new >> AR. New AR installs it, compresses incoming bicast packet headers. >> > >First, what is this soon enough ? Soon enough is before the old AR starts sending packets, so new AR can compress when the first packet gets there. > Second, you need special route entry to make >sure that a packet addressed to old-IP address of the MN is properly forwarded. What special route? It's just a tunnel. See RFC 2473 about how to do IPv6 tunnels. Tunnels are a standard IPv6 router function, no? >Third, the some fields do not necessarily remain constant due to processing at >new-AR. What happens to the Hop Limit and perhaps the Traffic Class field ? If >they change, how does the MN's compression engine know about this ? > Old AR puts a tunnel header on, new AR strips it off. The carmel core of the original packet is unchanged. Thus, new AR gets to compress just as old AR would have. >If there is a context at both the ARs, the uplink context is current only on the >old-AR to which the MN is connected. The MN does not transmit packets to both the >ARs (uplink bicasting) correct ? The new AR is also getting the packets, so it can also compress, even though MN isn't there to take them. Or are you thinking that compression will require some over the air traffic on the old L2 that will cause the context to change on the old AR? My recollection is that once the context is established, it doesn't change unless the header changes (i.e. it is not dependent on the channel, just on the contents). Need to check the ROHC algorithms, though. >Hope this helps. > >Anyway, my point is there are (important, hairy) issues to consider when combining >bicasting with compression. I don't want unwanted complexity in implementing >header compression due to bicasting (even if you can specify how to do it)! If you >really want bicasting, propose it as a separate draft. > What I want is *smoothing* (i.e. bicasting *and* buffering) to be in a separate draft. For both IPv6 and IPv4... jak From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 26 21:28:26 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA27924 for ; Thu, 26 Jul 2001 21:28: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 RAA09579; Thu, 26 Jul 2001 17:44:52 -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 QAA23239; Thu, 26 Jul 2001 16:44:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6QNgY407432 for mobile-ip-dist; Thu, 26 Jul 2001 16:42:34 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6QNgUY07425 for ; Thu, 26 Jul 2001 16:42:30 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA00456 for ; Thu, 26 Jul 2001 16:42:44 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA12140 for ; Thu, 26 Jul 2001 16:42:44 -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 QAA15377 for ; Thu, 26 Jul 2001 16:42:43 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6QNgh021133 for ; Thu, 26 Jul 2001 16:42:43 -0700 X-mProtect: Thu, 26 Jul 2001 16:42:43 -0700 Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdmHTAz0; Thu, 26 Jul 2001 16:42:39 PDT Message-ID: <3B60AAEF.29E4D057@iprg.nokia.com> Date: Thu, 26 Jul 2001 16:42:39 -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: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Handover Smoothing - What to Do? References: <200107262215.PAA07786@heliopolis.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 Hello James, James Kempf wrote: > Rajeev, > > I don't understand why there needs to be dual contexts at the MN. In the > single interface case, the MN is only connected to one AP/AR at a time. > And, it is sequentially connected to oAR then nAR, unless a ping-pong > occurs. > > So if CT is available, oAR simply sends the compression context to > nAR when the bicast stream is started, then runs the compression algorithm > until MN shows up and it can start getting packets. The compressor > context on MN just keeps working, since the CT causes the state > on the nAR side to start out the same as on the oAR. The MN drops > the old L2 bicast leg when it aquires the new L2 leg through nAR. > By dual contexts I didn't mean the two are simultaneously active. However, that is a separate problem. Indeed, I mentioned that only the old-AR has the up-to-date uplink context. Even if you can get the semantics right (i.e, make sure that the route entry is ok since you are bicasting to an old IP address), the switch of contexts when the MN joins the new-AR is not automatic. As I said previously, some fields change, e.g., Hop Limit, TC. And then there are tunneling extensions to consider. So, the state that the new-AR has is not the same as old-AR and this affects the corresponding state in the MN. This means when the MN shows up at new-AR, the state that new-AR has is not consistent wrt that of the MN's. We have identified the fields necessary to have the state consistent and proposed extensions in our recent draft (draft-koodli-seamoby-hc-relocate-01.txt). Your comments would be appreciated. [If you do CT after the old-AR stops forwarding packets to MN, then you could have consistent state in both uplink and downlink with the extensions. ] > > Last time I talked with the ROHC guys (at IETF 50), they seemed OK with > this. The fact that MIPv6 changes CoA after handover was giving them > more heartburn, but that won't be a problem until the MN actually > completes new CoA aquisition. Before that the packets should be > coming with the old CoA either from the oAR (if you are using the tunnelling > approach) or from the remote agent (if you are using the simultaneous bindings > approach). > Actually, we have defined a "New-IP-Address" extension that a MN sends right after it attaches to the new-AR. [In FMIPv6, the new CoA acquisition happens before the MN attaches to the new-AR.] This would be an extension to a compressed rohc packet that updates the state at the new-AR. Note that there is a framework defined in rohc-rtp draft (now an RFC) to carry extensions. > > Regarding if bicasting should be part of FMIPv6, I agree that it should be separated > out until we have a better understanding of the issues. The tougher issue > (and the one I think we are debating) is whether we should make the low latency > MIPv4 spec consistent by also separating it out. I am in favor of consistency, > perhaps as a consequence of my long Germanic ancestory (== a genetic predisposition > towards liking things orderly as opposed to chaotic). > Good that we agree regarding separating out bicasting. I would also support it for FMIPv4. Consistency will good! (even though my roots sometimes force me to seek order in chaos!) Regards, -Rajeev > > jak > > >James, > > > >Could you be more specific ? I mentioned that the new-AR *could* do it if it > >got the context (e.g., via CT). But that's not it. It means dual contexts at > >the MN for downlink. And, synchronization issue for uplink contexts (since > >the MN is communicating with old-AR). > > > >Again, here is the point: these are the issues surrounding how to get > >bicasting to work with FMIPv6. This MUST NOT be part of FMIPv6. More > >generally, FMIPv6 must not depend on a particular smoothing technique. > > > >I hope you understand and agree as well! > > > >Regards, > > > >-Rajeev > > > > > >James Kempf wrote: > > > >> Right, having the new AR compress was what I had in mind. > >> > >> jak > >> > >> >Gary Kenward writes: > >> > > Rajeev: > >> > > > >> > > Is one answer that the old AR could send uncompressed packets > >> > > to the new AR, and the new AR would then compress the packets or > >> > > not, depending on whether it had the context (there is a an case > >> > > to be made here for proactive ct ;^}). Depending on what was actually > >> > > sent over the air, this could create a tricky problem to solve > >> > > at the MN, as it may need to process the two streams before it could > >> > > even attempt duplicate removal, and this would require two compression > >> > > state machines, buffers, etc., etc. Not nice. > >> > > >> > It may not be nice, but I believe it comes with the > >> > territory. The alternative is to miss packets during > >> > the transition that you might have otherwise been > >> > able to recover. For mobile initiated > >> > break-before-make scenarios, you obviously > >> > don't want to allow any otherwise valid packets > >> > to be dropped making the situation worse. > >> > > >> > Mike > > From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 26 21:28:53 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA27960 for ; Thu, 26 Jul 2001 21:28:53 -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 TAA24468; Thu, 26 Jul 2001 19:29: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 SAA29542; Thu, 26 Jul 2001 18:29:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6R1Rxv08280 for mobile-ip-dist; Thu, 26 Jul 2001 18:27:59 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6R1RuY08273 for ; Thu, 26 Jul 2001 18:27:56 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id SAA15910 for ; Thu, 26 Jul 2001 18:28:11 -0700 (PDT) Message-Id: <200107270128.SAA15910@heliopolis.eng.sun.com> Date: Thu, 26 Jul 2001 18:28:09 -0700 (PDT) From: James Kempf Subject: Re: [mobile-ip] Handover Smoothing - What to Do? To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: DOXrlafuFU6J54O50v61Tw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 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: Hi Rajeev, > >By dual contexts I didn't mean the two are simultaneously active. However, that is a >separate problem. >Indeed, I mentioned that only the old-AR has the up-to-date uplink context. > OK, now I understand. You are thinking of the uplink context. I agree that the uplink context will have to be break before make. Sorry for being so dense. >Even if you can get the semantics right (i.e, make sure that the route entry is ok >since you are bicasting to an old IP address), the switch of contexts when the MN joins >the new-AR is not automatic. As I said previously, some fields change, e.g., Hop Limit, >TC. And then there are tunneling extensions to consider. So, the state that the >new-AR has is not the same as old-AR and this affects the corresponding state in the >MN. This means when the MN shows up at new-AR, the state that new-AR has is not >consistent wrt that of the MN's. > If you do IP in IP, why would the header change? The point is to put the pristine, incoming packet into the tunnel, then pop it out on the other end, without adding anything. >We have identified the fields necessary to have the state consistent and proposed >extensions in our recent draft (draft-koodli-seamoby-hc-relocate-01.txt). Your comments >would be appreciated. OK, I'll take a look. >[If you do CT after the old-AR stops forwarding packets to MN, then you could have >consistent state in both uplink and downlink with the extensions. ] > Right, that seems to be the best bet. MN disappears from old link, old AR transfers context to new AR, MN reappears and starts sending packets, new AR uses transferred context to compress/decompress. Unless you could figure out some way to get the compression context reinitialized quickly. Or put the compressed packets into the tunnel on old AR, so the context wouldn't have to be transferred. >Actually, we have defined a "New-IP-Address" extension that a MN sends right after it >attaches to the new-AR. [In FMIPv6, the new CoA acquisition happens before the MN >attaches to the new-AR.] This would be an extension to a compressed rohc packet that >updates the state at the new-AR. Note that there is a framework defined in rohc-rtp >draft (now an RFC) to carry extensions. > I am really skeptical of the MN doing any signalling over the air when it gets to new AR on 3G-like links. I frankly don't think there will be time for all the stuff in the FMIPv6 draft (FBU,FBACK, etc.) if there is a 6-8 kbps real time stream coming at the mobile and the uplink is 9.6 kbps. To say nothing of additional extensions. Hence the BETH proposal. I think there needs to be an option in fast handover where there is absolutely no L3 signalling between the MN and network, for those cases where the radio uplink is slow and the incoming data stream is about using up the uplink capacity. jak From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 26 21:32:22 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA28102 for ; Thu, 26 Jul 2001 21:32:22 -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 SAA09613; Thu, 26 Jul 2001 18:32:53 -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 SAA00236; Thu, 26 Jul 2001 18:32:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6R1VVs08330 for mobile-ip-dist; Thu, 26 Jul 2001 18:31:31 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6R1VSY08323 for ; Thu, 26 Jul 2001 18:31:28 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id SAA16062 for ; Thu, 26 Jul 2001 18:31:43 -0700 (PDT) Message-Id: <200107270131.SAA16062@heliopolis.eng.sun.com> Date: Thu, 26 Jul 2001 18:31:41 -0700 (PDT) From: James Kempf Subject: Re: [mobile-ip] Handover Smoothing - What to Do? To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Ehh6cTqc267Btn2g1coviw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 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: Hi again Rajeev, >The actual process depends however on the end-to-end network dynamics. For example, >if there is a talkspurt during handover followed by an idle time, then you could >drain the buffer without actually propagating the delay per se. You might affect the >start time of the *next* talkspurt however, in the sense that the idle time is not >exactly the same as that of the sener's. However, this is not a big deal in packet >networks with jitter buffers and smart playback adjustment. > It doesn't have anything to do with the network dynamics. If I buffer during time T(0), then it takes me T(1) to download, so I must buffer during that period. I download the T(1) buffer during time T(2), during which time I have to download, etc. It's a simple geometric series. Look in Appendix B of draft-kempf-beth-ipv6-01.txt for the math. On second thought, maybe I ought to just post a summary of the analysis, since we seem to be talking around it. jak From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 27 00:54:02 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA08106 for ; Fri, 27 Jul 2001 00:54:01 -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 VAA16526; Thu, 26 Jul 2001 21:54:34 -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 VAA05745; Thu, 26 Jul 2001 21:54:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6R4rFh08631 for mobile-ip-dist; Thu, 26 Jul 2001 21:53:15 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6R4rBY08624 for ; Thu, 26 Jul 2001 21:53:11 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA16830 for ; Thu, 26 Jul 2001 21:53:26 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA29972 for ; Thu, 26 Jul 2001 21:53: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 VAA15809 for ; Thu, 26 Jul 2001 21:53:24 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6R4rNC04575 for ; Thu, 26 Jul 2001 21:53:23 -0700 X-mProtect: Thu, 26 Jul 2001 21:53:23 -0700 Nokia Silicon Valley Messaging Protection Received: from Icharliep-1.iprg.nokia.com (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdwG1w8w; Thu, 26 Jul 2001 21:53:16 PDT Message-ID: <3B60F367.1136AAE9@iprg.nokia.com> Date: Thu, 26 Jul 2001 21:51:51 -0700 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] New authentication scheme in Mobile IPv6 draft revision...-14 References: <200107262053.f6QKrjT28860@locked.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 Hello Mohan, I thought that the use of AH and the use of the authentication data within the Binding Update were to be logically independent, so that the presence of one would not affect the presence of the other (except insofar as the AH data would be computed over the Binding Update option fields). So I don't see why any of the fields would have to be zero if AH were present. The AH could theoretically be computed using an algorithm that was less secure than the Binding Update authentication algorithm. Regards, Charlie P. Mohan Parthasarathy wrote: > Charlie, > > You still want to have the possibility of using IPsec between MN and > HA. In that case the i would assume that some of the fields mentioned > in section 4.4. will be zero. In Section 4.4 Authentication requirements, > it does not talk about IPsec at all. It will be needed if we still > think that we may allow IPsec between MN and HA. Section 10.2 still > talks about Outbound IPsec processing. It looks a bit confusing to me. > > -mohan > > > Hello folks, > > > > Somehow, the e-mail address on this note got truncated, so > > I am resending to this list. > > > > Regards, > > Charlie P. > > > > > > -------- Original Message -------- > > Subject: New authentication scheme in Mobile IPv6 draft revision ...-14 > > Date: Thu, 26 Jul 2001 12:28:13 -0700 > > From: "Charles E. Perkins" > > Organization: Nokia Research Center > > To: Bill Sommerfeld > > CC: mobile-ip@sunroof.eng.sun.co > > References: <200107251556.f6PFuTS21588@thunk.east.sun.com> > > > > > > Hello Bill, > > > > Draft revision ...-14 incorporates the authentication data as part of > > the Binding Update option itself. I thought that this modification > > was essentially mandated by Jeff Schiller's comments at the last IETF, > > and the surrounding discussion about use of IPsec vs. various > > destination options. > > > > One good thing about this arrangement is that it allows the verification > > of the Binding Update authentication data to happen independently of > > any IPsec requirement between the mobile node and the recipient of the > > Binding Update. To me, this seems like a good thing, and I am hoping > > that you would agree. > > > > > This is a *consequence* of the issue I pointed out yesterday: namely, > > > that if you allow for traffic on a connection/flow to contain a mix of > > > encrypted and unencrypted packets, you open yourself up to various > > > nasty denial of service attacks, and IPsec cannot provide useful > > > guarantees to upper layers. > > > > Could you make a small description about how the attacks work? > > > > I would have thought that IPsec should be applied depending on the > > kind of socket opened by the application, but maybe not... > > > > >> if piggybacking a BU was the problem, we could have solved > > >> it long back. just disallow piggybacking. anyway its a 'MAY' > > >> in the current draft. you dont lose much by not piggybacking > > >> the BU. > > > > > > I disagree. If it's a "MAY", then folks will build implementations > > > which always piggyback, which will cause interoperabilty problems with > > > IPsec implementations (such as Solaris's) which do per-connection > > > policy checks. > > > > Doesn't this problem go away entirely in draft ...-14? > > > > > > > > Regards, > > Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 27 02:11:00 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA26153 for ; Fri, 27 Jul 2001 02:10:59 -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 XAA28708; Thu, 26 Jul 2001 23:11: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 XAA23919; Thu, 26 Jul 2001 23:11:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6R6A0U08769 for mobile-ip-dist; Thu, 26 Jul 2001 23:10:00 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6R69vY08762 for ; Thu, 26 Jul 2001 23:09:57 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA02177 for ; Thu, 26 Jul 2001 23:10:12 -0700 (PDT) Received: from mail.n016.co.kr ([203.229.169.4]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA19258 for ; Thu, 26 Jul 2001 23:10:08 -0700 (PDT) Received: from freenet.ktf.co.kr (freenet.ktf.com [203.229.169.83]) by mail.n016.co.kr (v3smtp 8.11.4 Copyright (c) 1998-2001 Sendmail, Inc. All rights reserved.Copyright (c) 1988, 1993 The Regents of the University of California. All rights reserved./8.11.1) with ESMTP id f6R65M826567 for ; Fri, 27 Jul 2001 15:05:22 +0900 (KST) Received: from words ([10.6.10.175]) by freenet.ktf.co.kr (8.9.3/8.9.3) with SMTP id PAA09295 for ; Fri, 27 Jul 2001 15:07:21 +0900 (KST) Message-ID: <012001c11662$7f80fb50$af0a060a@words> From: "Jiwoong Lee" To: References: <200107262053.f6QKrjT28860@locked.eng.sun.com> <3B60F367.1136AAE9@iprg.nokia.com> Subject: Re: [mobile-ip] New authentication scheme in Mobile IPv6 draft revision...-14 Date: Fri, 27 Jul 2001 15:08:03 +0900 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.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: 8bit I agree with Charlie on that point. BTW, when HA decaps reverse tunneled packet, which among the tunnel header and the inner header MUST be accompanied by a valid AH ? From my reading, "tunneled packet" means "inner header and its payload". "Tunneling packet" means "tunnel header and its payload, which is in turn, inner header and its payload." Jiwoong ----- Original Message ----- From: "Charlie Perkins" To: Sent: Friday, July 27, 2001 1:51 PM Subject: Re: [mobile-ip] New authentication scheme in Mobile IPv6 draft revision...-14 > Hello Mohan, > > I thought that the use of AH and the use of the authentication > data within the Binding Update were to be logically independent, > so that the presence of one would not affect the presence of > the other (except insofar as the AH data would be computed > over the Binding Update option fields). So I don't see why > any of the fields would have to be zero if AH were present. > The AH could theoretically be computed using an algorithm > that was less secure than the Binding Update authentication > algorithm. > > Regards, > Charlie P. > > > > Mohan Parthasarathy wrote: > > > Charlie, > > > > You still want to have the possibility of using IPsec between MN and > > HA. In that case the i would assume that some of the fields mentioned > > in section 4.4. will be zero. In Section 4.4 Authentication requirements, > > it does not talk about IPsec at all. It will be needed if we still > > think that we may allow IPsec between MN and HA. Section 10.2 still > > talks about Outbound IPsec processing. It looks a bit confusing to me. > > > > -mohan > > > > > Hello folks, > > > > > > Somehow, the e-mail address on this note got truncated, so > > > I am resending to this list. > > > > > > Regards, > > > Charlie P. > > > > > > > > > -------- Original Message -------- > > > Subject: New authentication scheme in Mobile IPv6 draft revision ...-14 > > > Date: Thu, 26 Jul 2001 12:28:13 -0700 > > > From: "Charles E. Perkins" > > > Organization: Nokia Research Center > > > To: Bill Sommerfeld > > > CC: mobile-ip@sunroof.eng.sun.co > > > References: <200107251556.f6PFuTS21588@thunk.east.sun.com> > > > > > > > > > Hello Bill, > > > > > > Draft revision ...-14 incorporates the authentication data as part of > > > the Binding Update option itself. I thought that this modification > > > was essentially mandated by Jeff Schiller's comments at the last IETF, > > > and the surrounding discussion about use of IPsec vs. various > > > destination options. > > > > > > One good thing about this arrangement is that it allows the verification > > > of the Binding Update authentication data to happen independently of > > > any IPsec requirement between the mobile node and the recipient of the > > > Binding Update. To me, this seems like a good thing, and I am hoping > > > that you would agree. > > > > > > > This is a *consequence* of the issue I pointed out yesterday: namely, > > > > that if you allow for traffic on a connection/flow to contain a mix of > > > > encrypted and unencrypted packets, you open yourself up to various > > > > nasty denial of service attacks, and IPsec cannot provide useful > > > > guarantees to upper layers. > > > > > > Could you make a small description about how the attacks work? > > > > > > I would have thought that IPsec should be applied depending on the > > > kind of socket opened by the application, but maybe not... > > > > > > >> if piggybacking a BU was the problem, we could have solved > > > >> it long back. just disallow piggybacking. anyway its a 'MAY' > > > >> in the current draft. you dont lose much by not piggybacking > > > >> the BU. > > > > > > > > I disagree. If it's a "MAY", then folks will build implementations > > > > which always piggyback, which will cause interoperabilty problems with > > > > IPsec implementations (such as Solaris's) which do per-connection > > > > policy checks. > > > > > > Doesn't this problem go away entirely in draft ...-14? > > > > > > > > > > > > Regards, > > > Charlie P. > > From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 27 02:56:00 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA27121 for ; Fri, 27 Jul 2001 02:55:59 -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 QAA00788; Thu, 26 Jul 2001 16:38:07 -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 PAA01236; Thu, 26 Jul 2001 15:37:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6QMalC06610 for mobile-ip-dist; Thu, 26 Jul 2001 15:36:47 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6QMaiY06603 for ; Thu, 26 Jul 2001 15:36:44 -0700 (PDT) Received: from heliopolis.eng.sun.com (pacrimapp2.Singapore.Sun.COM [129.158.124.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA08640; Thu, 26 Jul 2001 15:36:36 -0700 (PDT) From: James Kempf Message-Id: <200107262236.PAA08640@heliopolis.eng.sun.com> Date: Thu, 26 Jul 2001 15:33:03 -0700 To: , Subject: Re: [mobile-ip] Handover Smoothing - What to Do? X-Mailer: Sun NetMail 2.3 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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Rajeev, I believe you misunderstood me. I am not advocating that smoothing be added to the current FMIPv6. I think we should have smoothing be a separate item. I also think it should be taken out of the low latency MIPv4 spec. There are some WG members I've talked to who don't believe smoothing is actually needed if the latency is kept low enough (for example, for BETH it will only be the L2 latency, no L3 latency at all). I am not of that opinion, however, I think that some smoothing technique requiring perhaps both may be needed in most cases, but only implementation experience will really tell. W.r.t. buffering, there has been alot of focus on the drawbacks of bicasting. Things are not so golden with respect to buffering, however. As I've tried to mention in a couple of emails, if you buffer during handover, the latency propagates. When you download the buffer to the MN, you need to buffer until the download is finished, etc. There's no free lunch, those real time packets keep coming in. If you take that into account, you end up getting some pretty strict bounds on what you can do for real time traffic. This is the discussion that Gary and I were having about delay budget. Buffering essentially prolongs the handover latency as the subsequent buffering periods are downloaded. There's an analysis in Appendix B of draft-kempf-beth-ipv6-01.txt if you care to check it. jak >Hello James, > > >James Kempf wrote: > >> Hi Phil, >> >> >There does seem to be some consensus that if a smoothing technique is chosen >> >it should be through bicasting or simultaneous binding rather than some kind >> >of >> >buffering. At the minimum we should have a discussion of why the tradeoff >> >of >> >accepting the possibility of duplicate packets weighs more heavily than >> >accepting >> >the possibility of lost packets and the results should be documented. >> > >> >> I have not heard much from advocates of buffering in the discussion >> so far, so I would have to agree. >> >> > >I don't understand your viewpoint. Just because you have not heard from >buffering advocates does not imply that the alternative is the way to go. There >are at least two things to consider. First, you are proposing to add a >particular smoothing technique to FMIPv6. I am registering my complaint saying >that it is not the right thing to do. FMIPv6 must be able to work independently >of bicasting. I have provided the problems stemming from header compression as >an example to illustrate the added complexity. Second, taking up smoothing as a >topic by itself, it is not a foregone conclusion that bicasting/simultaneous >binding are the only means. This is an open area and we need discussion and >*real experimental* evidence. Also, the header compression example hold here as >well. > >Regards, > >-Rajeev > > > >> >George has also asserted (and speaking for myself personally I also agree >> >with) >> >that implementations in some environments at least can solve this without >> >any kind >> >of protocol support at layer 3. >> > >> >> I agree also. >> >> >Does this seem to summarize everyone's position accurately? Does this >> >answer your question >> >enough, Jim? >> > >> >> Yes, thanx. >> >> >Of course, others contributing to the conversation COULD help, >> >> Agree. >> >> jak > From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 27 04:31:58 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA01202 for ; Fri, 27 Jul 2001 04:31:53 -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 BAA28063; Fri, 27 Jul 2001 01:32: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 BAA08999; Fri, 27 Jul 2001 01:31:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6R8UnJ09042 for mobile-ip-dist; Fri, 27 Jul 2001 01:30:49 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6R8UjY09035 for ; Fri, 27 Jul 2001 01:30: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 BAA29614 for ; Fri, 27 Jul 2001 01:31:00 -0700 (PDT) Received: from mail.n016.co.kr ([203.229.169.4]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA20023 for ; Fri, 27 Jul 2001 02:32:25 -0600 (MDT) Received: from freenet.ktf.co.kr (freenet.ktf.com [203.229.169.83]) by mail.n016.co.kr (v3smtp 8.11.4 Copyright (c) 1998-2001 Sendmail, Inc. All rights reserved.Copyright (c) 1988, 1993 The Regents of the University of California. All rights reserved./8.11.1) with ESMTP id f6R8Mh806578 for ; Fri, 27 Jul 2001 17:22:43 +0900 (KST) Received: from words ([10.6.10.175]) by freenet.ktf.co.kr (8.9.3/8.9.3) with SMTP id RAA29984 for ; Fri, 27 Jul 2001 17:24:43 +0900 (KST) Message-ID: <019701c11675$af671e40$af0a060a@words> From: "Jiwoong Lee" To: References: <3B605DD3.35A4376C@iprg.nokia.com> Subject: Re: [mobile-ip] Relation between IPv6 and MIP Date: Fri, 27 Jul 2001 17:25:24 +0900 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.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: 8bit Vijay, I doubt it. Please see section 7.1 of mobileip-ipv6-14. 7.1. Requirements for All IPv6 Hosts and Routers Since any IPv6 node may at any time be a correspondent node of a mobile node, either sending a packet to a mobile node or receiving a packet from a mobile node, the following requirements apply to ALL IPv6 nodes (whether host or router, whether mobile or stationary): - Every IPv6 node MUST be able to process a Home Address option received in any IPv6 packet. blah blah.. Jiwoong ----- Original Message ----- From: "Vijay Devarapalli" To: Sent: Friday, July 27, 2001 3:13 AM Subject: Re: [mobile-ip] Relation between IPv6 and MIP > Qiang Zhang wrote: > > > > Hello, I've always thought that MIP is an addon protocol for IPv6, so it > > is a SHOULD not a MUST implementation, is this correct? > > If MIP is optional, then a node doesn't have to maintain all binding > > signaling, but REALLY has to support home address option, is this an > > valid requirement imposed from MIP? > > > > Please clarify, thank you > > that is correct. the minimum requirement is " any node should be able > to process the home address option ". > > vijay From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 27 04:42:00 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA01658 for ; Fri, 27 Jul 2001 04:41:59 -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 BAA01226; Fri, 27 Jul 2001 01:42: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 BAA10385; Fri, 27 Jul 2001 01:42:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6R8f9409127 for mobile-ip-dist; Fri, 27 Jul 2001 01:41:09 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6R8f5Y09120 for ; Fri, 27 Jul 2001 01:41:05 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA14283 for ; Fri, 27 Jul 2001 01:41:20 -0700 (PDT) Received: from mail.n016.co.kr ([203.229.169.4]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA08902 for ; Fri, 27 Jul 2001 01:41:16 -0700 (PDT) Received: from freenet.ktf.co.kr (freenet.ktf.com [203.229.169.83]) by mail.n016.co.kr (v3smtp 8.11.4 Copyright (c) 1998-2001 Sendmail, Inc. All rights reserved.Copyright (c) 1988, 1993 The Regents of the University of California. All rights reserved./8.11.1) with ESMTP id f6R8Zi807230 for ; Fri, 27 Jul 2001 17:35:44 +0900 (KST) Received: from words ([10.6.10.175]) by freenet.ktf.co.kr (8.9.3/8.9.3) with SMTP id RAA08043 for ; Fri, 27 Jul 2001 17:37:44 +0900 (KST) Message-ID: <019e01c11677$8135a3a0$af0a060a@words> From: "Jiwoong Lee" To: References: <200107161656.JAA23654@heliopolis.eng.sun.com> Subject: Re: [mobile-ip] Mobile Operators REquirements (MORE) BOF Date: Fri, 27 Jul 2001 17:38:24 +0900 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.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: 8bit James, Did you succeed in acquiring time slot for MORE BOF ? I counldn't find it in the current agenda. Cheers, Jiwoong ----- Original Message ----- From: "James Kempf" To: ; ; Sent: Tuesday, July 17, 2001 1:56 AM Subject: [mobile-ip] Mobile Operators REquirements (MORE) BOF > Folks, > > Apologies for the wide posting. > > Recently, there was a draft posted > (draft-reynolds-mobile-isp-requirements-00.txt) that discusses requirements > for wireless ISPs (WISPs) for IP protocols related to or impacted > by mobility. There has been some discussion on the mailing list > (more@psg.com, usual majordomo subscription procedure) about the > requirements. We are now in the process of planning for a BOF at IETF 51 > in London. If anyone is interested in speaking at the BOF, please send > me email. > > jak > > From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 27 06:43:28 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA05839 for ; Fri, 27 Jul 2001 06:43:28 -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 EAA29515; Fri, 27 Jul 2001 04:44:01 -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 DAA12652; Fri, 27 Jul 2001 03:43:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6RAgQx09346 for mobile-ip-dist; Fri, 27 Jul 2001 03:42:26 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6RAgNY09339 for ; Fri, 27 Jul 2001 03:42:23 -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 DAA12521 for ; Fri, 27 Jul 2001 03:42:36 -0700 (PDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA07646 for ; Fri, 27 Jul 2001 04:44:00 -0600 (MDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f6RAgXN13457 for ; Fri, 27 Jul 2001 12:42:33 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Fri Jul 27 12:42:32 2001 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 27 Jul 2001 12:36:21 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008B64@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Handover Smoothing - What to Do? Date: Fri, 27 Jul 2001 12:42:23 +0200 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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hello Rajeev, There are so many mails I hope no one else made the same comments that I'm about to make. > I don't understand your viewpoint. Just because you have not heard from > buffering advocates does not imply that the alternative is the way to go. There > are at least two things to consider. First, you are proposing to add a > particular smoothing technique to FMIPv6. I am registering my complaint saying > that it is not the right thing to do. > => You're making a statement that is not backed by a reason. See more below. > FMIPv6 must be able to work independently > of bicasting. > => Why ? > I have provided the problems stemming from header compression as > an example to illustrate the added complexity. > => Context transfer for HC is extrermely complex in itself and controversial. Yet if you want it, I don't see how bicasting can make it worse. In fact with bicasting you can establish the down link context earlier since the process happens before the MN attaches to the nAR. Either way, why are we discussing CT and HC again ? Haven't we already agreed that this is out of scope for the MIP WG. > Second, taking up smoothing as a > topic by itself, it is not a foregone conclusion that bicasting/simultaneous > binding are the only means. This is an open area and we need discussion and > *real experimental* evidence. Also, the header compression example hold here as > well. > => Well other proposals are also welcome. But I'm sure you can appreciate that new ideas come up all the time, that doesn't mean we don't make any decisions. We have to decide on what we have now. Unless you've done some experiments on bicasting and saw that it's bad for some reason. Hesham > > >George has also asserted (and speaking for myself personally I also agree > > >with) > > >that implementations in some environments at least can solve this without > > >any kind > > >of protocol support at layer 3. > > > > > > > I agree also. > > > > >Does this seem to summarize everyone's position accurately? Does this > > >answer your question > > >enough, Jim? > > > > > > > Yes, thanx. > > > > >Of course, others contributing to the conversation COULD help, > > > > Agree. > > > > jak From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 27 06:51:06 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA06048 for ; Fri, 27 Jul 2001 06:51:05 -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 EAA02526; Fri, 27 Jul 2001 04:51:35 -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 DAA26119; Fri, 27 Jul 2001 03:51:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6RAo3209399 for mobile-ip-dist; Fri, 27 Jul 2001 03:50:03 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6RAo0Y09392 for ; Fri, 27 Jul 2001 03:50:00 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA13284 for ; Fri, 27 Jul 2001 03:50:13 -0700 (PDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA03634 for ; Fri, 27 Jul 2001 03:50:12 -0700 (PDT) Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f6RAoBO19224 for ; Fri, 27 Jul 2001 12:50:11 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Fri Jul 27 12:50:10 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Fri, 27 Jul 2001 12:50:09 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008B65@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Analysis of Jitter in Bicasting Date: Fri, 27 Jul 2001 12:50:02 +0200 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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: George, > First off, disclaimer: I'm neutral on both > buffering and bicasting. > > My point was simply that we not try to perform any > unnatural acts in the middle of the network to > hide jitter and duplication from the end > hosts. Yes, I agree that that will cause many > TCP's to barf, but the right thing to do is to fix > the TCP, not hide it in the network. In fact, the > effects of bicasting would only affect mobile > nodes, and I'd assume that ones which were the > targets of bicasting would have a fair amount of > incentive to deal with this inevitability. Were it > a possibility toward any random CN, then I'd > probably have a different opinion, but that > doesn't seem to be the case. > > > GT> But it will be towards a random CN...what do you thing the mobiles are > going to be? Definately not only specialized devices...any PC with any OS > may be mobile and thus the potential target of bicasting...BTW, I also thing > that TCP should be fixed...and thus EIFFEL is good work...we just need > experimentation experiance and time for it to be > implemented/tested/deployed...then yes, bicasting may become feasible. > => The MN _requests_ bicasting. If it thinks it's "bad" then it doesn't have to request it. What is the problem here ??? If the MN decides that EIFEL is required to request bicasting and it doesnt have it then it won't request it. If it doesn't have EIFEL and doesn't have TCP connections open then it can request bicasting without any troubles. Only the MN is affected by its request. In fact that is the main reason for the protocol change instead of making ARs just bicast on their own. I don't understand your point. Regards, Hesham From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 27 06:54:22 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA06153 for ; Fri, 27 Jul 2001 06:54:21 -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 DAA09634; Fri, 27 Jul 2001 03:54:56 -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 DAA26527; Fri, 27 Jul 2001 03:54:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6RArAC09437 for mobile-ip-dist; Fri, 27 Jul 2001 03:53:10 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6RAr6Y09429 for ; Fri, 27 Jul 2001 03:53:07 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA21210 for ; Fri, 27 Jul 2001 03:53:19 -0700 (PDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA04514 for ; Fri, 27 Jul 2001 03:53:19 -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.11.0/8.11.0/WIREfire-1.3) with SMTP id f6RArIN18581 for ; Fri, 27 Jul 2001 12:53:18 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Fri Jul 27 12:53:14 2001 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 27 Jul 2001 12:47:03 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008B66@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Analysis of Jitter in Bicasting Date: Fri, 27 Jul 2001 12:53:10 +0200 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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > First off, disclaimer: I'm neutral on both > buffering and bicasting. > > My point was simply that we not try to perform any > unnatural acts in the middle of the network to > hide jitter and duplication from the end > hosts. Yes, I agree that that will cause many > TCP's to barf, but the right thing to do is to fix > the TCP, not hide it in the network. In fact, the > effects of bicasting would only affect mobile > nodes, and I'd assume that ones which were the > targets of bicasting would have a fair amount of > incentive to deal with this inevitability. Were it > a possibility toward any random CN, then I'd > probably have a different opinion, but that > doesn't seem to be the case. > > Mike > => That just makes TOO much sense ! Hesham From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 27 07:09:33 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA06900 for ; Fri, 27 Jul 2001 07:09:33 -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 FAA09416; Fri, 27 Jul 2001 05:09: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 EAA28115; Fri, 27 Jul 2001 04:09:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6RB4ji09574 for mobile-ip-dist; Fri, 27 Jul 2001 04:04:45 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6RB4fY09567 for ; Fri, 27 Jul 2001 04:04:42 -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 EAA27643 for ; Fri, 27 Jul 2001 04:04:54 -0700 (PDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA07610 for ; Fri, 27 Jul 2001 05:04:52 -0600 (MDT) Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f6RB4qO26682 for ; Fri, 27 Jul 2001 13:04:53 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Fri Jul 27 13:04:48 2001 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 27 Jul 2001 12:58:37 +0200 Message-ID: <795A014AF92DD21182AF0008C7A404320C52049E@esealnt117> From: "Karim El-Malki (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Handover Smoothing - What to Do? Date: Fri, 27 Jul 2001 13:04:41 +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: > Well, I don't buy a lot of your response below, but > notwithstanding that, Since you're expressing an opinion against this it would be useful to know the reasons rather than just saying you don't buy my response. > some documentation of how these cases are handled needs to be made so > it's available for scrutiny. It seems that it should discuss > the sizes > of these buffers and the criteria for determining when to > forward and when > to drop packets, and what bicasting doesn't do for you. Perhaps some > guidance > on how the agents involved in the implementation distinguish > between and > handle different types of traffic should be included, because > although the > proposals > are intended to help in the case of realtime traffic, the > implementation > agents > unless otherwise informed are subject to the effects of implementing > the protocols for all traffic? I'm not sure that specifying buffer sizes is something we should do, we can just give some simple explanation of what factors the calculation should be based on. The choice of buffering/bicasting and that calculation should be left up to implementors who know more about the system they're building on. We'll never solve all the problems, but at least we can identify the gaps and supply the tools. Regarding identification of traffic type, this was brought up a while back. It would need some filtering at AR/FA. There is also a proposal to move only certain flows: http://search.ietf.org/internet-drafts/draft-soliman-mobileip-flow-move-00.txt A BU could eventually identify which flows to be bicast and which not. That could be an alternative to filtering traffic at the ARs/FAs. However it will be up to the implementor in the end to balance the complexity, performance of real-time, performance of non-real time against their applications. If someone's top priority is to get max performance for VoIP and other traffic has lower importance then that decision will influence the implementation. If we supply some tools for this (and for the opposite case) it certainly helps. I had interpreted the MAYs in low latency to be these tools, and if there are others all the better. /Karim > > > > -----Original Message----- > > From: Karim El-Malki (ERA) [mailto:Karim.El-Malki@era.ericsson.se] > > Sent: Thursday, July 26, 2001 10:44 AM > > To: 'mobile-ip@sunroof.eng.sun.com' > > Subject: RE: [mobile-ip] Handover Smoothing - What to Do? > > > > > > > They are both receiving packets without any knowledge of what > > > the other > > > has received, or has forwarded to the MN. Might you not have > > > a situation > > > like this? > > > > I agree that there should not be the need for nFA to know what > > oFA has transmitted. What I'm saying is that if you bicast and > > (if needed) have an appropriate (jitter) buffer size at nFA then > > it should be possible to avoid duplicates. More below. > > > > > > > > At a single point in time the MN is no longer reachable from > > > the oFA and is > > > not yet reachable on the nFA. At that point in time a packet > > > arrives at > > > both > > > oFA and nFA and they discard the packet. The MN attaches to > > > the nFA but the > > > packet is gone. (That's in case A you describe). > > > > I would think that this is an effect of L2 (i.e. L2 handoff time) > > and we are mostly aiming to minimise/eliminate effects due to L3. > > Also what I was pointing to is that a buffer is probably needed > > if the handoff time from oFA to nFA is not negligible (your next > > case and this case). That's why packet dropping is a MAY. So this > > case wouldn't happen, unless of course it's not TCP and you don't > > care about dropping some packets. In fact low latency handoffs are > > probably most useful for real-time services (e.g. Voice on UDP) > > in which case, if there's an period of L2 disconnection during > > handoff, the packets should be dropped. > > > > > > > > Or like this? > > > > > > At a single point in time a packet arrives at the oFA and is > > > sent to the MN > > > and > > > at the same time arrives at the nFA and gets buffered. The > > > MN disconnects > > > and then reconnects at the nFA and gets a second copy of > the packet. > > > (That's > > > in case B you describe). > > > > The buffer size should be set such that you don't get duplicates. > > By the time MN connects to nFA, the second copy of the packet > > should be dropped out of the FIFO queue/buffer and the next one > > should be ready for sending to MN. Of course this calculation > > depends on the l2 handoff characteristics and possibly the wired > > connectivity between the bicasting point and oFA/nFA. > > > > > > > > Or like this? > > > The same packet arrives at oFA and is transmitted to the MN > > > which then moves > > > to the > > > nFA and gets the same packet which was delayed on its way > > to the nFA. > > > > That would again need to be handled by a jitter-smoothing > > buffer at nFA. > > > > > > > > Or like this? > > > The MN disconnects from the oFA the packet arrives and is > > > dropped, then the > > > MN comes > > > back to the oFA because of radio conditions and the packet > > > has been lost. > > > > We could devise some temporary oFA buffer for this, but the L2 > > handoff failure is pretty serious so I think that it is > > too much to expect smooth handoffs in this case. If we can > > maintain L3 connectivity then I think that should be good enough. > > > > > > > > It seems like there is some coordination needed between the > > > oFA and the nFA > > > to > > > overcome these problems, perhaps a temporary tunnel? But > > in that case > > > bicasting from > > > an HA or a hierarchical FA wouldn't be adding much to it, > > > would it. > > > > Well, I think that having a local central HA would help. > > Say that oFA and nFA are at an equal distance from the GFA > > which is the aggregation router between the two. That could > > alleviate jitter on the fixed network, as has been already > > mentioned by James. Also, if oFA and nFA happen to be connected > > to each other through the GFA router, then bicasting at the > > GFA would be more efficient. > > > > >At any > > > rate > > > one would think that issues like this need some exploration > > > and explanation > > > somewhere. > > > > OK. Up to now there has been a lot of emphasis on TCP. Although I > > agree that it would be useful to give more detail of how bicasting > > + buffering works with TCP, we are also not considering the > fact that > > a major driver for having faster handoffs at L3 was to support > > real-time services (over UDP). I would think that the > issues above are > > not applicable to this case? If this is so then we should not apply > > these issues to bicasting/buffering in general and make that > > clear too. > > > > Rgds > > /Karim > > > From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 27 07:10:18 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA06974 for ; Fri, 27 Jul 2001 07:10:18 -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 EAA13267; Fri, 27 Jul 2001 04:10:44 -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 EAA28253; Fri, 27 Jul 2001 04:10:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6RB8Zj09666 for mobile-ip-dist; Fri, 27 Jul 2001 04:08:35 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6RB8VY09652 for ; Fri, 27 Jul 2001 04:08:31 -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 EAB13122 for ; Fri, 27 Jul 2001 04:08:44 -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 FAA16611 for ; Fri, 27 Jul 2001 05:10:10 -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 HAA06650; Fri, 27 Jul 2001 07:07:43 -0400 (EDT) Message-Id: <200107271107.HAA06650@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-aaa-key-08.txt Date: Fri, 27 Jul 2001 07:07:42 -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 : AAA Registration Keys for Mobile IP Author(s) : C. Perkins, P. Calhoun Filename : draft-ietf-mobileip-aaa-key-08.txt Pages : 11 Date : 26-Jul-01 AAA servers, such as RADIUS and DIAMETER, are in use within the Internet today to provide authentication and authorization services for dial-up computers. Mobile IP requires strong authentication between the mobile node and its home agent. When the mobile node shares a security association with its home AAA server, however, it is possible to use that security association to create derivative security associations between the mobile node and its home agent, and again between the mobile node and the foreign agent currently offering connectivity to the mobile node. This document specifies extensions to the Mobile IP Registration Reply packet that can be used to create such security information at the mobile node. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-aaa-key-08.txt 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-key-08.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-key-08.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: <20010726170606.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-aaa-key-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-aaa-key-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010726170606.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 27 07:10:21 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA06986 for ; Fri, 27 Jul 2001 07:10:20 -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 EAA13323; Fri, 27 Jul 2001 04:10:49 -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 EAA28269; Fri, 27 Jul 2001 04:10:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6RB8dD09668 for mobile-ip-dist; Fri, 27 Jul 2001 04:08:39 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6RB8YY09660 for ; Fri, 27 Jul 2001 04:08:34 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA22695 for ; Fri, 27 Jul 2001 04:08:47 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA08637 for ; Fri, 27 Jul 2001 04:08:47 -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 HAA06665; Fri, 27 Jul 2001 07:07:47 -0400 (EDT) Message-Id: <200107271107.HAA06665@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-fast-mipv6-02.txt Date: Fri, 27 Jul 2001 07:07:46 -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 : Fast Handovers for Mobile IPv6 Author(s) : G. Dommety, A. Yegin, C. Perkins, G. Tsirtsis, K. Malki, M. Khalil Filename : draft-ietf-mobileip-fast-mipv6-02.txt Pages : 36 Date : 26-Jul-01 This document specifies protocol enhancements to MIPv6 that enable mobile nodes to quickly change their point of attachment to the Internet, i.e., move from one Access Router to another. These protocol enhancements are intended to minimize the time during which a mobile node is unable to send or receive IPv6 packets (i.e., the handover latency). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-fast-mipv6-02.txt 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-fast-mipv6-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-fast-mipv6-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: <20010726170616.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-fast-mipv6-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-fast-mipv6-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010726170616.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 27 07:12:26 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA07134 for ; Fri, 27 Jul 2001 07:12:26 -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 EAA14064; Fri, 27 Jul 2001 04:13:01 -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 EAA28668; Fri, 27 Jul 2001 04:12:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6RBBQC09890 for mobile-ip-dist; Fri, 27 Jul 2001 04:11:26 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6RBBMY09875 for ; Fri, 27 Jul 2001 04:11:22 -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 EAA28507 for ; Fri, 27 Jul 2001 04:11:35 -0700 (PDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA10487 for ; Fri, 27 Jul 2001 05:11:32 -0600 (MDT) Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f6RBBWO29971 for ; Fri, 27 Jul 2001 13:11:32 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Fri Jul 27 13:11:31 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Fri, 27 Jul 2001 13:11:30 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008B68@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Handover Smoothing - What to Do? Date: Fri, 27 Jul 2001 13:11:23 +0200 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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: James, Rajeev and all, IMHO there is absolutely no gain or benefit in discussing whether smoothing should be in draft X or Y. The question was do we want the bicasting technique or not ? putting it in the right draft is something secodary that will not add value to this discussion. It seems like some people are saying we don't care as long as you keep it out of this draft !! what's the point of this argument ? Putting it as MAY (as it is in the MIPv4 draft) will have the same effect. Hesham From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 27 08:08:47 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA10577 for ; Fri, 27 Jul 2001 08:08:46 -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 FAA27036; Fri, 27 Jul 2001 05:09:14 -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 FAA04171; Fri, 27 Jul 2001 05:08:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6RC7Z112228 for mobile-ip-dist; Fri, 27 Jul 2001 05:07:35 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6RC7VY12221 for ; Fri, 27 Jul 2001 05:07:31 -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 FAA18505; Fri, 27 Jul 2001 05:07:44 -0700 (PDT) Received: from telecom.samsung.co.kr ([165.213.221.4]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA01724; Fri, 27 Jul 2001 06:07:41 -0600 (MDT) Received: from metro (a22414 [165.213.224.14]) by telecom.samsung.co.kr (8.9.3/8.9.3) with SMTP id VAA19095; Fri, 27 Jul 2001 21:10:16 +0900 (KST) Message-ID: <04fa01c11694$b08a2960$0ee0d5a5@telecom.samsung.co.kr> From: "junhyuk song" To: Cc: "Pat Calhoun" References: <200107271107.HAA06650@ietf.org> Subject: Re: [mobile-ip] I-D ACTION:draft-ietf-mobileip-aaa-key-08.txt Date: Fri, 27 Jul 2001 21:07:20 +0900 Organization: cdma2000 system MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" 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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by sunroof.eng.sun.com id f6RC7WY12222 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 Hi Pat, I don't see the need for MN-FA shared key while using FAC and MN-AAA authentication. The AAAH will verify Mobile Node for Foreign Agent with MN-AAA authenticatiion defined in RFC3012. It seems to me using MN-FA Auth and FAC with MN-AAA Auth together is somewhat redundant. Besides, I wish you made separate section for RADIUS consideration in your draft. Further more the RADIUS based AAA case must be noted for DOS attack consideration, because HA will blindly procede Mobile IP signalling and AAA message without MN-HA authentication for the initial RRQ. Another approach is clearly defining MN-AAA authentication from HA before AAAH procede to generate "Key Material" and "Mn-HA shared key". It also may be helpful to mandate HA-FA authentication between FA and HA. Regards, JH SONG From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 27 08:57:14 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA14222 for ; Fri, 27 Jul 2001 08:57:13 -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 FAA10539; Fri, 27 Jul 2001 05:57:30 -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 FAA09013; Fri, 27 Jul 2001 05:57:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6RCtlZ12365 for mobile-ip-dist; Fri, 27 Jul 2001 05:55:47 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6RCthY12358 for ; Fri, 27 Jul 2001 05:55:43 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA27736 for ; Fri, 27 Jul 2001 05:55:57 -0700 (PDT) Received: from sonne.darmstadt.gmd.de (sonne.darmstadt.gmd.de [141.12.62.20]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA07939 for ; Fri, 27 Jul 2001 05:55:56 -0700 (PDT) Received: from ipsi.fraunhofer.de (pc-morion [141.12.35.155]) by sonne.darmstadt.gmd.de (8.8.8/8.8.5) with ESMTP id OAA05498; Fri, 27 Jul 2001 14:55:54 +0200 (MET DST) Message-ID: <3B6165D5.8324B195@ipsi.fraunhofer.de> Date: Fri, 27 Jul 2001 15:00:05 +0200 From: Wolfgang Schoenfeld Organization: FhG IPSI X-Mailer: Mozilla 4.7 [de] (WinNT; I) X-Accept-Language: en,de MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] I-D ACTION:draft-ietf-mobileip-fast-mipv6-02.txt References: <200107271107.HAA06665@ietf.org> 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 Thanks for reworking it! But why is it now doubly spaced? In order to be even faster? :-) Wolfgang Internet-Drafts@ietf.org schrieb: > > 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 : Fast Handovers for Mobile IPv6 > Author(s) : G. Dommety, A. Yegin, C. Perkins, G. Tsirtsis, > K. Malki, M. Khalil > Filename : draft-ietf-mobileip-fast-mipv6-02.txt > Pages : 36 > Date : 26-Jul-01 > > This document specifies protocol enhancements to MIPv6 that enable > mobile nodes to quickly change their point of attachment to the > Internet, i.e., move from one Access Router to another. These > protocol enhancements are intended to minimize the time during which > a mobile node is unable to send or receive IPv6 packets (i.e., the > handover latency). > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mobileip-fast-mipv6-02.txt > > 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-fast-mipv6-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-fast-mipv6-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. > > ---------------------------------------------------------------------------------------------------- > Content-Type: text/plain > Content-ID: <20010726170616.I-D@ietf.org> -- Wolfgang Schoenfeld, Fraunhofer IPSI, Dolivostr. 15, D-64293 Darmstadt Office: +49-6151-869-865 FAX: -6847 Mobile: +49-174-7093455 From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 27 08:57:22 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA14248 for ; Fri, 27 Jul 2001 08:57:22 -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 GAA25015; Fri, 27 Jul 2001 06:57:51 -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 FAA09042; Fri, 27 Jul 2001 05:57:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6RCubk12383 for mobile-ip-dist; Fri, 27 Jul 2001 05:56:37 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6RCuXY12376 for ; Fri, 27 Jul 2001 05:56:33 -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 FAA03536 for ; Fri, 27 Jul 2001 05:56:47 -0700 (PDT) Received: from RRMAIL01.RADIOROUTER_NT ([63.103.94.23]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA24361 for ; Fri, 27 Jul 2001 06:56:45 -0600 (MDT) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Fri, 27 Jul 2001 08:56:45 -0400 Message-ID: <8C92E23A3E87FB479988285F9E22BE460546D5@ftmail> From: George Tsirtsis To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Handover Smoothing - What to Do? Date: Fri, 27 Jul 2001 08:56: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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hesham, I think people say: "leave smoothing out of FMIP specs so we can take FMIP specs forward and have more time to debate smoothing which does not enjoy the same consensus FMIP does... Regards George -----Original Message----- From: Hesham Soliman (ERA) [mailto:Hesham.Soliman@era.ericsson.se] Sent: Friday, July 27, 2001 12:11 PM To: 'mobile-ip@sunroof.eng.sun.com' Subject: RE: [mobile-ip] Handover Smoothing - What to Do? James, Rajeev and all, IMHO there is absolutely no gain or benefit in discussing whether smoothing should be in draft X or Y. The question was do we want the bicasting technique or not ? putting it in the right draft is something secodary that will not add value to this discussion. It seems like some people are saying we don't care as long as you keep it out of this draft !! what's the point of this argument ? Putting it as MAY (as it is in the MIPv4 draft) will have the same effect. Hesham From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 27 09:05:46 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA14864 for ; Fri, 27 Jul 2001 09:05: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 HAA29363; Fri, 27 Jul 2001 07:05: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 GAA09913; Fri, 27 Jul 2001 06:04:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6RD3sI12485 for mobile-ip-dist; Fri, 27 Jul 2001 06:03:54 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6RD3pY12478 for ; Fri, 27 Jul 2001 06:03:51 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA28758 for ; Fri, 27 Jul 2001 06:04:05 -0700 (PDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA01334 for ; Fri, 27 Jul 2001 06:04:03 -0700 (PDT) Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f6RD42O27611 for ; Fri, 27 Jul 2001 15:04:02 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Fri Jul 27 15:04:01 2001 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 27 Jul 2001 14:57:50 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008B6D@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Handover Smoothing - What to Do? Date: Fri, 27 Jul 2001 15:03:54 +0200 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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi George, > I think people say: "leave smoothing out of FMIP specs so we can take FMIP > specs forward and have more time to debate smoothing which does not enjoy > the same consensus FMIP does... > => Understood. My point is that this is a waste of time to discuss. We should discuss what smoothing is needed, namely the proposed bicasting in the draft and mentioned in BETH and get consencus: yes or no. If no, then it's no for any draft in MIP. If yes then there is consencus and therefore it shouldn't matter where. Discussing where it should go when we clearly don't have consencus on whether it's good or bad is a complete and utter waste of time IMHO. Cheers, Hesham > -----Original Message----- > From: Hesham Soliman (ERA) [mailto:Hesham.Soliman@era.ericsson.se] > Sent: Friday, July 27, 2001 12:11 PM > To: 'mobile-ip@sunroof.eng.sun.com' > Subject: RE: [mobile-ip] Handover Smoothing - What to Do? > > > James, Rajeev and all, > > IMHO there is absolutely no gain or benefit in discussing whether > smoothing should be in draft X or Y. The question was do we want > the bicasting technique or not ? putting it in the right draft is > something secodary that will not add value to this discussion. > > It seems like some people are saying we don't care as long as you > keep it out of this draft !! what's the point of this argument ? > Putting it as MAY (as it is in the MIPv4 draft) will have the same > effect. > > Hesham From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 27 10:02:46 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19161 for ; Fri, 27 Jul 2001 10:02:45 -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 HAA01534; Fri, 27 Jul 2001 07:03:01 -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 HAA16530; Fri, 27 Jul 2001 07:02:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6RE0o012692 for mobile-ip-dist; Fri, 27 Jul 2001 07:00:50 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6RE0lY12685 for ; Fri, 27 Jul 2001 07:00:47 -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 HAA13669 for ; Fri, 27 Jul 2001 07:00:55 -0700 (PDT) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA07077 for ; Fri, 27 Jul 2001 08:02:16 -0600 (MDT) Received: by megisto-sql1.megisto.com with Internet Mail Service (5.5.2650.21) id ; Fri, 27 Jul 2001 10:00:35 -0400 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Handover Smoothing - What to Do? Date: Fri, 27 Jul 2001 10:00:35 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) 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: Well, actually, the v4 draft seems to say it's MAY for PREREG and MUST for POSTREG. > -----Original Message----- > From: Hesham Soliman (ERA) [mailto:Hesham.Soliman@era.ericsson.se] > Sent: Friday, July 27, 2001 7:11 AM > To: 'mobile-ip@sunroof.eng.sun.com' > Subject: RE: [mobile-ip] Handover Smoothing - What to Do? > > > James, Rajeev and all, > > IMHO there is absolutely no gain or benefit in discussing whether > smoothing should be in draft X or Y. The question was do we want > the bicasting technique or not ? putting it in the right draft is > something secodary that will not add value to this discussion. > > It seems like some people are saying we don't care as long as you > keep it out of this draft !! what's the point of this argument ? > Putting it as MAY (as it is in the MIPv4 draft) will have the same > effect. > > Hesham > > From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 27 10:05:21 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19325 for ; Fri, 27 Jul 2001 10:05:20 -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 IAA05434; Fri, 27 Jul 2001 08:05: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 HAA16959; Fri, 27 Jul 2001 07:05:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6RE4MP12739 for mobile-ip-dist; Fri, 27 Jul 2001 07:04:22 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6RE4GY12727 for ; Fri, 27 Jul 2001 07:04:16 -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 HAA04560 for ; Fri, 27 Jul 2001 07:04:13 -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 IAA08745 for ; Fri, 27 Jul 2001 08:05: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 HAA19861; Fri, 27 Jul 2001 07:03:52 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6RE3pR29088; Fri, 27 Jul 2001 07:03:51 -0700 X-mProtect: Fri, 27 Jul 2001 07:03:51 -0700 Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpd2quoXz; Fri, 27 Jul 2001 07:03:49 PDT Message-ID: <3B6174C5.D107C18F@iprg.nokia.com> Date: Fri, 27 Jul 2001 07:03: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: "Hesham Soliman (EPA)" CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Handover Smoothing - What to Do? References: <034BEFD03799D411A59F00508BDF754603008B68@esealnt448.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, There is a huge difference between putting "MAY" into the fast handover draft, and putting it in a separate draft entirely. If it's in the fast handover draft, we have to try to get it right before the fast handover draft can be finished. If it's in another draft, we can work on that draft later, which is in my opinion much more appropriate. I would appreciate taking it out of the IPv4 draft, but I haven't had time to study that document so I have not made any comments. Regards, Charlie P. "Hesham Soliman (ERA)" wrote: > > James, Rajeev and all, > > IMHO there is absolutely no gain or benefit in discussing whether > smoothing should be in draft X or Y. The question was do we want > the bicasting technique or not ? putting it in the right draft is > something secodary that will not add value to this discussion. > > It seems like some people are saying we don't care as long as you > keep it out of this draft !! what's the point of this argument ? > Putting it as MAY (as it is in the MIPv4 draft) will have the same > effect. > > Hesham From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 27 10:07:56 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19529 for ; Fri, 27 Jul 2001 10:07:55 -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 HAA04018; Fri, 27 Jul 2001 07:08:02 -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 HAA17126; Fri, 27 Jul 2001 07:06:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6RE4pO12761 for mobile-ip-dist; Fri, 27 Jul 2001 07:04:51 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6RE4jY12754 for ; Fri, 27 Jul 2001 07:04:45 -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 HAA16871 for ; Fri, 27 Jul 2001 07:04:59 -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 IAA04485 for ; Fri, 27 Jul 2001 08:04:57 -0600 (MDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f6RE57329895 for ; Fri, 27 Jul 2001 07:05:07 -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 AAY00327; Fri, 27 Jul 2001 07:04:56 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA11428; Fri, 27 Jul 2001 07:04:56 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15201.29959.850333.678281@thomasm-u1.cisco.com> Date: Fri, 27 Jul 2001 07:04:55 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] New authentication scheme in Mobile IPv6 draft revision...-14 In-Reply-To: <3B60F367.1136AAE9@iprg.nokia.com> References: <200107262053.f6QKrjT28860@locked.eng.sun.com> <3B60F367.1136AAE9@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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Charlie Perkins writes: > Hello Mohan, > > I thought that the use of AH and the use of the authentication > data within the Binding Update were to be logically independent [...], Can you please point to the thread where the consensus for moving the authentication data to the BU was achieved? Thanks. Mike From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 27 10:09:52 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19646 for ; Fri, 27 Jul 2001 10:09:51 -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 HAA04967; Fri, 27 Jul 2001 07:10:12 -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 HAA04303; Fri, 27 Jul 2001 07:08:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6RE7OV12838 for mobile-ip-dist; Fri, 27 Jul 2001 07:07:24 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6RE7JY12828 for ; Fri, 27 Jul 2001 07:07:19 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA04128 for ; Fri, 27 Jul 2001 07:07:34 -0700 (PDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA29975 for ; Fri, 27 Jul 2001 07:07:32 -0700 (PDT) Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f6RE7VO28373 for ; Fri, 27 Jul 2001 16:07:31 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Fri Jul 27 16:07:20 2001 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 27 Jul 2001 16:01:09 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008B73@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Handover Smoothing - What to Do? Date: Fri, 27 Jul 2001 16:07:12 +0200 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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > Well, actually, the v4 draft seems to say it's MAY for PREREG and MUST > for POSTREG. > => Yes I think that was a slip. We should fix that (MAY for both). Karim you mentioned this last week was it MAY for both ? I think the rest of the authors agreed with that. Hesham > > -----Original Message----- > > From: Hesham Soliman (ERA) [mailto:Hesham.Soliman@era.ericsson.se] > > Sent: Friday, July 27, 2001 7:11 AM > > To: 'mobile-ip@sunroof.eng.sun.com' > > Subject: RE: [mobile-ip] Handover Smoothing - What to Do? > > > > > > James, Rajeev and all, > > > > IMHO there is absolutely no gain or benefit in discussing whether > > smoothing should be in draft X or Y. The question was do we want > > the bicasting technique or not ? putting it in the right draft is > > something secodary that will not add value to this discussion. > > > > It seems like some people are saying we don't care as long as you > > keep it out of this draft !! what's the point of this argument ? > > Putting it as MAY (as it is in the MIPv4 draft) will have the same > > effect. > > > > Hesham > > > > From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 27 10:21:45 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20924 for ; Fri, 27 Jul 2001 10:21:45 -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 IAA16941; Fri, 27 Jul 2001 08:22: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 HAA05766; Fri, 27 Jul 2001 07:21:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6REK7t13049 for mobile-ip-dist; Fri, 27 Jul 2001 07:20:07 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6REK3Y13042 for ; Fri, 27 Jul 2001 07:20:03 -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 HAA05664 for ; Fri, 27 Jul 2001 07:20:15 -0700 (PDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id IAA07915 for ; Fri, 27 Jul 2001 08:20:23 -0600 (MDT) Received: (qmail 16462 invoked by uid 500); 27 Jul 2001 13:51:12 -0000 Date: Fri, 27 Jul 2001 06:51:12 -0700 From: Pat Calhoun To: mobile-ip@sunroof.eng.sun.com Cc: Pat Calhoun Subject: Re: [mobile-ip] I-D ACTION:draft-ietf-mobileip-aaa-key-08.txt Message-ID: <20010727065112.L13541@charizard.diameter.org> References: <200107271107.HAA06650@ietf.org> <04fa01c11694$b08a2960$0ee0d5a5@telecom.samsung.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <04fa01c11694$b08a2960$0ee0d5a5@telecom.samsung.co.kr>; from junhyuk@metro.telecom.samsung.co.kr on Fri, Jul 27, 2001 at 09:07:20PM +0900 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 Fri, Jul 27, 2001 at 09:07:20PM +0900, junhyuk song wrote: > Hi Pat, > > I don't see the need for MN-FA shared key while using FAC and MN-AAA authentication. > The AAAH will verify Mobile Node for Foreign Agent with MN-AAA authenticatiion defined in RFC3012. It seems to me using MN-FA Auth and FAC with MN-AAA Auth together is somewhat redundant. It isn't redundant since the AAA and the FA may be owned by separate administrative domains. Having said that, no where in the draft does it state that the MN-FA is to be present if the MN-AAA is present. > Besides, I wish you made separate section for RADIUS consideration in your draft. why? This draft discusses how the keys are sent to the mobile node, not to a RADIUS and/or Diameter device. The AAA software used is completely irrelevant to this draft (unless I missed something). > Further more the RADIUS based AAA case must be noted for DOS attack consideration, because HA will blindly procede Mobile IP signalling and AAA message without MN-HA authentication for the initial RRQ. Another approach is clearly defining MN-AAA authentication from HA before AAAH procede to generate "Key Material" and "Mn-HA shared key". Right, and this was one of the reasons why we decided to allow the FA to forward the messages to the AAA infrastructure in Diameter. 3GPP2 decided to let the HA to the work, and that is simply the wrong approach, and will lead to DoS attacks. I've brought this up numerous times, and the real fix is to change how 3GPP2 handles AAA (not necessarily the protocol, but rather the way it uses RADIUS). > It also may be helpful to mandate HA-FA authentication between FA and HA. If keys are generated, yes, but this is not covered by this draft. It seems like what you are requesting is really in the Diameter Mobile IP application, and not in this one. PatC From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 27 10:22:31 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20986 for ; Fri, 27 Jul 2001 10:22:30 -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 HAA09870; Fri, 27 Jul 2001 07:22:42 -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 HAA05749; Fri, 27 Jul 2001 07:21:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6REJcV13037 for mobile-ip-dist; Fri, 27 Jul 2001 07:19:38 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6REJYY13030 for ; Fri, 27 Jul 2001 07:19:35 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA19156 for ; Fri, 27 Jul 2001 07:19:47 -0700 (PDT) Received: from EXCHANGE01.domain.ecutel.com ([65.201.154.134]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA05984 for ; Fri, 27 Jul 2001 07:19:46 -0700 (PDT) content-class: urn:content-classes:message Subject: RE: [mobile-ip] Relation between IPv6 and MIP MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Date: Fri, 27 Jul 2001 10:19:43 -0400 Message-ID: Thread-Topic: [mobile-ip] Relation between IPv6 and MIP Thread-Index: AcEWd2Vo4IEPnTG3TD2mqQEvLjsFkQAODTrg From: "Qiang Zhang" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f6REJZY13031 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, There is no doubt that any IPv6 node needs to support the Home addr option, otherwise... My intention asking this was that I feel like there should be a doc in IPng to enforce this option if it is going to be a REQUIREMENT. -----Original Message----- From: Jiwoong Lee [mailto:porce@ktf.com] Sent: Friday, July 27, 2001 3:25 AM To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Relation between IPv6 and MIP Vijay, I doubt it. Please see section 7.1 of mobileip-ipv6-14. 7.1. Requirements for All IPv6 Hosts and Routers Since any IPv6 node may at any time be a correspondent node of a mobile node, either sending a packet to a mobile node or receiving a packet from a mobile node, the following requirements apply to ALL IPv6 nodes (whether host or router, whether mobile or stationary): - Every IPv6 node MUST be able to process a Home Address option received in any IPv6 packet. blah blah.. Jiwoong ----- Original Message ----- From: "Vijay Devarapalli" To: Sent: Friday, July 27, 2001 3:13 AM Subject: Re: [mobile-ip] Relation between IPv6 and MIP > Qiang Zhang wrote: > > > > Hello, I've always thought that MIP is an addon protocol for IPv6, so it > > is a SHOULD not a MUST implementation, is this correct? > > If MIP is optional, then a node doesn't have to maintain all binding > > signaling, but REALLY has to support home address option, is this an > > valid requirement imposed from MIP? > > > > Please clarify, thank you > > that is correct. the minimum requirement is " any node should be able > to process the home address option ". > > vijay From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 27 10:25:57 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA21316 for ; Fri, 27 Jul 2001 10:25: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 IAA20278; Fri, 27 Jul 2001 08:26: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 HAA06419; Fri, 27 Jul 2001 07:26:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6REP6B13144 for mobile-ip-dist; Fri, 27 Jul 2001 07:25:06 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6REP2Y13137 for ; Fri, 27 Jul 2001 07:25:02 -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 HAA20444 for ; Fri, 27 Jul 2001 07:25:15 -0700 (PDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA19427 for ; Fri, 27 Jul 2001 08:25:12 -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.11.0/8.11.0/WIREfire-1.3) with SMTP id f6REPCN04182 for ; Fri, 27 Jul 2001 16:25:12 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Fri Jul 27 16:25:11 2001 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 27 Jul 2001 16:19:00 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008B74@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Handover Smoothing - What to Do? Date: Fri, 27 Jul 2001 16:24:59 +0200 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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hello Charlie, > There is a huge difference between putting "MAY" into > the fast handover draft, and putting it in a separate > draft entirely. > > If it's in the fast handover draft, we have to try to get > it right before the fast handover draft can be finished. > > If it's in another draft, we can work on that draft > later, which is in my opinion much more appropriate. > => I appreciate your logic, but, I believe whatever we do the solution has to be good enough to meet our initial targets. In this case there are two issues: - We've introduced a new concept in the v6 draft (and the v4 one) and that is anticipation. This can have negative impacts if not treated carefully. Right now it isn't treated carefully in the v6 draft so I don't believe the draft can go ahead with a gap in it because some of us are not sure about the fix. I say we wait until we're sure. Anyway the FMIPv6 draft will not become an RFC before MIPv6 I hope. So what are we so rushed for ? - A solution for the problem has been around for nearly 2 years. How much more time is needed ? We don't need every single one to set up experiments. This rule was never followed in other drafts. Many people are accepting the approach and it is suggested as an option. Furthermore, the option is already in RFC2002 for MIPv4 why is v6 any different ? I think we should be consistent with this because there is nothing v6 specific here. > I would appreciate taking it out of the IPv4 draft, > but I haven't had time to study that document so I > have not made any comments. > => Sure. I look forward to your comments, but the question on the agenda will be whether the draft should go for last call and I sincerely hope that we don't have an answer like " this needs further study" (I'm not referring to you but a general comment). We need something concrete as to whether a solution is good or bad and why. Finally, as I tried to convey many times on the list, the energy wasted in discussing which document this should go in can be better used to identify whether a solution is good enough (for any document) or not. Deciding which doc it should go in is not important now if we can't agree on whether a solution is good enough or not. I hope folks would try to concentrate on getting some agreement on this important issue first. Regards, Hesham > "Hesham Soliman (ERA)" wrote: > > > > James, Rajeev and all, > > > > IMHO there is absolutely no gain or benefit in discussing whether > > smoothing should be in draft X or Y. The question was do we want > > the bicasting technique or not ? putting it in the right draft is > > something secodary that will not add value to this discussion. > > > > It seems like some people are saying we don't care as long as you > > keep it out of this draft !! what's the point of this argument ? > > Putting it as MAY (as it is in the MIPv4 draft) will have the same > > effect. > > > > Hesham From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 27 10:29:44 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA21750 for ; Fri, 27 Jul 2001 10:29:43 -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 HAA12898; Fri, 27 Jul 2001 07:30: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 HAA06934; Fri, 27 Jul 2001 07:29:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6RESdA13216 for mobile-ip-dist; Fri, 27 Jul 2001 07:28:39 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6RESZY13208 for ; Fri, 27 Jul 2001 07:28:35 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA06782 for ; Fri, 27 Jul 2001 07:28:43 -0700 (PDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA11024 for ; Fri, 27 Jul 2001 07:28:42 -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.11.0/8.11.0/WIREfire-1.3) with SMTP id f6RESfN05619 for ; Fri, 27 Jul 2001 16:28:41 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Fri Jul 27 16:28:40 2001 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 27 Jul 2001 16:22:29 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008B75@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Relation between IPv6 and MIP Date: Fri, 27 Jul 2001 16:28:27 +0200 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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > There is no doubt that any IPv6 node needs to support the Home addr > option, otherwise... > My intention asking this was that I feel like there should be a doc in > IPng to enforce > this option if it is going to be a REQUIREMENT. > => This is not the current practice. For example I haven't seen a doc in IPng that says IPsec is mandated for all IPv6 hosts (maye I missed it but I don't think RFC 2460 says it). The IPsec RFCs do. Anyway for an attempt to capture the cellular hosts reqts see : http://standards.ericsson.net/Hesham/draft-manyfolks-ipv6-cellular-host-00.txt Note: This is only for cellular hosts Hesham > -----Original Message----- > From: Jiwoong Lee [mailto:porce@ktf.com] > Sent: Friday, July 27, 2001 3:25 AM > To: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Relation between IPv6 and MIP > > > Vijay, > > I doubt it. Please see section 7.1 of mobileip-ipv6-14. > > > 7.1. Requirements for All IPv6 Hosts and Routers > > Since any IPv6 node may at any time be a correspondent node of a > mobile node, either sending a packet to a mobile node or receiving a > packet from a mobile node, the following requirements apply to ALL > IPv6 nodes (whether host or router, whether mobile or stationary): > > - Every IPv6 node MUST be able to process a Home Address option > received in any IPv6 packet. > > blah blah.. > > > Jiwoong > > > > > ----- Original Message ----- > From: "Vijay Devarapalli" > To: > Sent: Friday, July 27, 2001 3:13 AM > Subject: Re: [mobile-ip] Relation between IPv6 and MIP > > > > Qiang Zhang wrote: > > > > > > Hello, I've always thought that MIP is an addon protocol for IPv6, > so it > > > is a SHOULD not a MUST implementation, is this correct? > > > If MIP is optional, then a node doesn't have to maintain all binding > > > signaling, but REALLY has to support home address option, is this an > > > valid requirement imposed from MIP? > > > > > > Please clarify, thank you > > > > that is correct. the minimum requirement is " any node should be able > > to process the home address option ". > > > > vijay From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 27 10:37:21 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA22324 for ; Fri, 27 Jul 2001 10:37:20 -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 HAA15563; Fri, 27 Jul 2001 07:37: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 HAA07816; Fri, 27 Jul 2001 07:34:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6REXVL13311 for mobile-ip-dist; Fri, 27 Jul 2001 07:33:31 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6REXRY13304 for ; Fri, 27 Jul 2001 07:33:27 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA19350 for ; Fri, 27 Jul 2001 07:33:40 -0700 (PDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id HAA13157 for ; Fri, 27 Jul 2001 07:33:35 -0700 (PDT) Received: (qmail 16961 invoked by uid 500); 27 Jul 2001 14:19:08 -0000 Date: Fri, 27 Jul 2001 07:19:08 -0700 From: Pat Calhoun To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile Operators REquirements (MORE) BOF Message-ID: <20010727071907.T13541@charizard.diameter.org> References: <200107161656.JAA23654@heliopolis.eng.sun.com> <019e01c11677$8135a3a0$af0a060a@words> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <019e01c11677$8135a3a0$af0a060a@words>; from porce@ktf.com on Fri, Jul 27, 2001 at 05:38:24PM +0900 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 Fri, Jul 27, 2001 at 05:38:24PM +0900, Jiwoong Lee wrote: > James, > > Did you succeed in acquiring time slot for MORE BOF ? > I counldn't find it in the current agenda. yes, it is during the first hour of Monday's seamoby WG meeting. PatC From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 27 10:46:46 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA23232 for ; Fri, 27 Jul 2001 10:46:44 -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 HAA18754; Fri, 27 Jul 2001 07:45: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 HAA08645; Fri, 27 Jul 2001 07:42:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6REfHd13380 for mobile-ip-dist; Fri, 27 Jul 2001 07:41:17 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6REfDY13373 for ; Fri, 27 Jul 2001 07:41: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 HAA08524 for ; Fri, 27 Jul 2001 07:41:26 -0700 (PDT) Received: from zcars0m9.ca.nortel.com ([47.129.242.157]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA27891 for ; Fri, 27 Jul 2001 08:42:46 -0600 (MDT) Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f6REel924756 for ; Fri, 27 Jul 2001 10:40:47 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.ca.nortel.com; Fri, 27 Jul 2001 10:40:53 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 27 Jul 2001 10:40:54 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5E9B@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Analysis of Jitter in Bicasting Date: Fri, 27 Jul 2001 10:40:52 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C116AA.22CBFD90" X-Orig: 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_01C116AA.22CBFD90 Content-Type: text/plain; charset="iso-8859-1" James: Sounds like we are reading from the same page. I realize I opened up a can of worms with my comment on diversity combining and packet data. As you said, I think we will have to take the conversation off line, perhaps over coffee in London. Just to summarize, the purpose behind my comments on comparison to 2G, etc., and delay budgets was that it is my view we have much less then 100 ms for handover. Probably more like 20 ms - 40 ms. If we can agree upon this rough range, then we can avoid a very difficult requirements analysis problem. Gary > -----Original Message----- > From: James Kempf [mailto:James.Kempf@Sun.COM] > Sent: July 26, 2001 17:56 > To: mobile-ip; 'mobile-ip@sunroof.eng.sun.com' > Subject: RE: [mobile-ip] Analysis of Jitter in Bicasting > > > Hi Gary, > > > > I'm not sure that comparing handover latencies with 2, 2.5, or 3G > >is all that relevant. With soft handover, there is theoretically, > >no latency, although I suspect that there are exceptions - > I'm checking > >to see if there are published numbers. I have heard some atrociously > >poor numbers for packet data, but I won't repeat them here because > >they are not verifiable. > > > > My point is that users have a given level of service with 2.5G. If we > come to the 3Gs and say "we've got mobile IP handover figured > out, but hard > handover times are 1.5 sec instead of 200 ms, so users are going to > notice when a hard handover occurs" they are less likely to > be interested > in deploying VoIP to the handset. > > > The issue with packet data, and the reason that the > latency starts to > >look bad, is that soft handover is extremely difficult to do > with shared > >channels, datagrams and a routed network (i.e. the issues > are not all > >that different from the issues being discussed with respect > to bicasting). > > Well, after having spent the last year looking at soft > handover in IP RANs, > I am not convinced that this is the case. Soft handover is an > L2 issue, > once the packet pops out of the macrodiversity combiner (or goes in), > it's exactly like getting it out of or putting it into a router that's > connected to an optical network or any other L2. Sure, there > are issues > of isochrony w.r.t. getting the radio frames from the macrodiversity > combining point to the radio access points, but these need to > be handled > by properly designing the L1/L2 in the RAN, regardless of > whether IP or ATM is used > as the transport. > > But we should probably take this to a separate thread. > > >IMHO 2-3G networks are not well suited to IP services > because they were not > >designed to switch packets fast across the channel (by fast > I mean ms, not > >10s or 100s of ms). Ultimately, this channel access delay may be the > >real pacer for handover, not the mobility solution. > > > > The PDSN/GGSN designs seem a bit on the heavy weight side. If/when we > get this handover story straigtened out, perhaps we can move the > routing point at least as far as the RAN controller. > > > Enough doom and gloom. In anticipation of a different > approach in 4G, > >there is little information on how to allocate an > appropriate "latency > >budget" across the network. I know that the transit delays for North > >America for single operator networks have been dropping > steadily, and are > >well below 100 ms (I've heard numbers as low as 50 ms, but I > haven't had > >a chance to check the latest). > > > > So, if its 50 ms transit delay, that leaves approximately > 30 ms for each > >access network for one leg of a two way conversation. Not a > heck of a lot > >of time. Of course, it is arguable that you can > asymmetrically allocate > >the budget between access networks, as it is unlikely that > they will both > >need the maximum budget at the same instant (e.g. if both > access networks > >are wireless, it is unlikely that both will be in the > process of handing > >over > >at the same time). > > > > Agreed. > > > BTW: I did not checked the ITU spec, but 300 ms is as good > as 250 ms, > >certainly > >as far as these discussions are concerned. End to end > latency bounds are > >determined by the desired quality of the voice service, and > usually are > >based upon empirical measurements from subjective quality > tests (the ITU > >numbers are). > >The numbers from these tests, called Mean Opinion Scores, > have a very high > >variance, and the real quality difference caused by an > increase in latency > >from > >250 to 300 ms is not easily detected (which means you > probably can drop > >the 0.5 from 112.5 ;^} ). One has to be careful in some > respects, because > >there > >are thresholds where a majority of listeners can detect > significant changes > >in > >quality (humans being largely non-linear systems), but if I > believe the > >first > >threshold is upwards towards 500 ms, as someone else has mentioned. > > > > > > I've heard the upper threshold is around 600 ms when the conversation > really starts to sound half duplex. > > One thing concerns me though: should we be using RTT or > single leg? I've > been using RTT in my calculations, because if the mobile is > out of contact > or busy downloading a buffer, then it would be so for both directions. > > In any event, I think we need to use the delay budget for the > access network > alone, which removes the delay across the backbone and in the > other access > network. > > jak > > ------_=_NextPart_001_01C116AA.22CBFD90 Content-Type: text/html; charset="iso-8859-1" RE: [mobile-ip] Analysis of Jitter in Bicasting

James:

  Sounds like we are reading from the same page. I realize I opened
up a can of worms with my comment on diversity combining and packet
data. As you said, I think we will have to take the conversation off
line, perhaps over coffee in London.

  Just to summarize, the purpose behind my comments on comparison
to 2G, etc., and delay budgets was that it is my view we have much
less then 100 ms for handover. Probably more like 20 ms - 40 ms.
If we can agree upon this rough range, then we can avoid a very difficult
requirements analysis problem.

Gary

> -----Original Message-----
> From: James Kempf [mailto:James.Kempf@Sun.COM]
> Sent: July 26, 2001 17:56
> To: mobile-ip; 'mobile-ip@sunroof.eng.sun.com'
> Subject: RE: [mobile-ip] Analysis of Jitter in Bicasting
>
>
> Hi Gary,
>
>
> >  I'm not sure that comparing handover latencies with 2, 2.5, or 3G
> >is all that relevant. With soft handover, there is theoretically,
> >no latency, although I suspect that there are exceptions -
> I'm checking
> >to see if there are published numbers. I have heard some atrociously
> >poor numbers for packet data, but I won't repeat them here because
> >they are not verifiable.
> >
>
> My point is that users have a given level of service with 2.5G. If we
> come to the 3Gs and say "we've got mobile IP handover figured
> out, but hard
> handover times are 1.5 sec instead of 200 ms, so users are going to
> notice when a hard handover occurs" they are less likely to
> be interested
> in deploying VoIP to the handset.
>
> >  The issue with packet data, and the reason that the
> latency starts to
> >look bad, is that soft handover is extremely difficult to do
> with shared
> >channels, datagrams and a routed network (i.e. the issues
> are not all
> >that different from the issues being discussed with respect
> to bicasting).
>
> Well, after having spent the last year looking at soft
> handover in IP RANs,
> I am not convinced that this is the case. Soft handover is an
> L2 issue,
> once the packet pops out of the macrodiversity combiner (or goes in),
> it's exactly like getting it out of or putting it into a router that's
> connected to an optical network or any other L2. Sure, there
> are issues
> of isochrony w.r.t. getting the radio frames from the macrodiversity
> combining point to the radio access points, but these need to
> be handled
> by properly designing the L1/L2 in the RAN, regardless of
> whether IP or ATM is used
> as the transport.
>
> But we should probably take this to a separate thread.
>
> >IMHO 2-3G networks are not well suited to IP services
> because they were not
> >designed to switch packets fast across the channel (by fast
> I mean ms, not
> >10s or 100s of ms). Ultimately, this channel access delay may be the
> >real pacer for handover, not the mobility solution.
> >
>
> The PDSN/GGSN designs seem a bit on the heavy weight side. If/when we
> get this handover story straigtened out, perhaps we can move the
> routing point at least as far as the RAN controller.
>
> >  Enough doom and gloom. In anticipation of a different
> approach in 4G,
> >there is little information on how to allocate an
> appropriate "latency
> >budget" across the network. I know that the transit delays for North
> >America for single operator networks have been dropping
> steadily, and are
> >well below 100 ms (I've heard numbers as low as 50 ms, but I
> haven't had
> >a chance to check the latest).
> >
> >  So, if its 50 ms transit delay, that leaves approximately
> 30 ms for each
> >access network for one leg of a two way conversation. Not a
> heck of a lot
> >of time. Of course, it is arguable that you can
> asymmetrically allocate
> >the budget between access networks, as it is unlikely that
> they will both
> >need the maximum budget at the same instant (e.g. if both
> access networks
> >are wireless, it is unlikely that both will be in the
> process of handing
> >over
> >at the same time).
> >
>
> Agreed.
>
> >  BTW: I did not checked the ITU spec, but 300 ms is as good
> as 250 ms,
> >certainly
> >as far as these discussions are concerned. End to end
> latency bounds are
> >determined by the desired quality of the voice service, and
> usually are
> >based upon empirical measurements from subjective quality
> tests (the ITU
> >numbers are).
> >The numbers from these tests, called Mean Opinion Scores,
> have a very high
> >variance, and the real quality difference caused by an
> increase in latency
> >from
> >250 to 300 ms is not easily detected (which means you
> probably can drop
> >the 0.5 from 112.5 ;^} ). One has to be careful in some
> respects, because
> >there
> >are thresholds where a majority of listeners can detect
> significant changes
> >in
> >quality (humans being largely non-linear systems), but if I
> believe the
> >first
> >threshold is upwards towards 500 ms, as someone else has mentioned.
> >
> >
>
> I've heard the upper threshold is around 600 ms when the conversation
> really starts to sound half  duplex.
>
> One thing concerns me though: should we be using RTT or
> single leg? I've
> been using RTT in my calculations, because if the mobile is
> out of contact
> or busy downloading a buffer, then it would be so for both directions.
>
> In any event, I think we need to use the delay budget for the
> access network
> alone, which removes the delay across the backbone and in the
> other access
> network.
>
>               jak
>
>

------_=_NextPart_001_01C116AA.22CBFD90-- From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 27 10:51:01 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA23707 for ; Fri, 27 Jul 2001 10:51:00 -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 IAA09739; Fri, 27 Jul 2001 08:51: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 HAA09829; Fri, 27 Jul 2001 07:51:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6REnrn13473 for mobile-ip-dist; Fri, 27 Jul 2001 07:49:53 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6REnnY13466 for ; Fri, 27 Jul 2001 07:49:50 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA09718 for ; Fri, 27 Jul 2001 07:50:02 -0700 (PDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA20066 for ; Fri, 27 Jul 2001 07:50:02 -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.11.0/8.11.0/WIREfire-1.3) with SMTP id f6REo1N14120 for ; Fri, 27 Jul 2001 16:50:01 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Fri Jul 27 16:50:00 2001 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 27 Jul 2001 16:43:49 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008B76@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] Agenda confusion Date: Fri, 27 Jul 2001 16:49:55 +0200 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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Raj and Phil, I'm a bit confused. When I add up the time slots in the agenda I find that we have one meeting, but the MIP WG seems to have two meetings according to the IETF agenda. Have I missed something ? Cheers, Hesham From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 27 10:55:30 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA24181 for ; Fri, 27 Jul 2001 10:55:28 -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 IAA12805; Fri, 27 Jul 2001 08:55: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 HAA10502; Fri, 27 Jul 2001 07:55:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6REs1513507 for mobile-ip-dist; Fri, 27 Jul 2001 07:54:01 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6RErvY13500 for ; Fri, 27 Jul 2001 07:53:58 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA28174 for ; Fri, 27 Jul 2001 07:54:11 -0700 (PDT) Received: from zcars0m9.ca.nortel.com ([47.129.242.157]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA23978 for ; Fri, 27 Jul 2001 07:54:05 -0700 (PDT) Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f6RErc900547 for ; Fri, 27 Jul 2001 10:53:38 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.ca.nortel.com; Fri, 27 Jul 2001 10:53:34 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 27 Jul 2001 10:53:35 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5E9C@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Handover Smoothing - What to Do? Date: Fri, 27 Jul 2001 10:53:33 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C116AB.E7FA8C20" X-Orig: 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_01C116AB.E7FA8C20 Content-Type: text/plain; charset="iso-8859-1" James: Just a point of clarification: the scenario you are describing only applies to digitized voice with voice activity detection. The delay you add with jitter buffering still translates to end-to-end delay of the voice. Probably the only big advantage you get is that you don't have to worry about de-jittering the silence periods, and thus have less packets to buffer. Gary > -----Original Message----- > From: James Kempf [mailto:James.Kempf@Sun.COM] > Sent: July 26, 2001 21:32 > To: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Handover Smoothing - What to Do? > > > Hi again Rajeev, > > > >The actual process depends however on the end-to-end network > dynamics. For > example, > >if there is a talkspurt during handover followed by an idle > time, then you > could > >drain the buffer without actually propagating the delay per > se. You might > affect the > >start time of the *next* talkspurt however, in the sense > that the idle time is > not > >exactly the same as that of the sener's. However, this is > not a big deal in > packet > >networks with jitter buffers and smart playback adjustment. > > > > It doesn't have anything to do with the network dynamics. If > I buffer during > time T(0), then it takes me T(1) to download, so I must buffer during > that period. I download the T(1) buffer during time T(2), during > which time I have to download, etc. It's a simple geometric series. > Look in Appendix B of draft-kempf-beth-ipv6-01.txt for the math. > > On second thought, maybe I ought to just post a summary of > the analysis, > since we seem to be talking around it. > > jak > > ------_=_NextPart_001_01C116AB.E7FA8C20 Content-Type: text/html; charset="iso-8859-1" RE: [mobile-ip] Handover Smoothing - What to Do?

James:

  Just a point of clarification: the scenario you are describing
only applies to digitized voice with voice activity detection.
The delay you add with jitter buffering still translates to
end-to-end delay of the voice. Probably the only big advantage
you get is that you don't have to worry about de-jittering the
silence periods, and thus have less packets to buffer.


Gary

> -----Original Message-----
> From: James Kempf [mailto:James.Kempf@Sun.COM]
> Sent: July 26, 2001 21:32
> To: mobile-ip@sunroof.eng.sun.com
> Subject: Re: [mobile-ip] Handover Smoothing - What to Do?
>
>
> Hi again Rajeev,
>
>
> >The actual process depends however on the end-to-end network
> dynamics. For
> example,
> >if there is a talkspurt during handover followed by an idle
> time, then you
> could
> >drain the buffer without actually propagating the delay per
> se. You might
> affect the
> >start time of the *next* talkspurt however, in the sense
> that the idle time is
> not
> >exactly the same as that of the sener's. However, this is
> not a big deal in
> packet
> >networks with jitter buffers and smart playback adjustment.
> >
>
> It doesn't have anything to do with the network dynamics. If
> I buffer during
> time T(0), then it takes me T(1) to download, so I must buffer during
> that period. I download the T(1) buffer during time T(2), during
> which time I have to download, etc. It's a simple geometric series.
> Look in Appendix B of draft-kempf-beth-ipv6-01.txt for the math.
>
> On second thought, maybe I ought to just post a summary of
> the analysis,
> since we seem to be talking around it.
>
>               jak
>
>

------_=_NextPart_001_01C116AB.E7FA8C20-- From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 27 11:15:51 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA26157 for ; Fri, 27 Jul 2001 11:15:50 -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 IAA00833; Fri, 27 Jul 2001 08:16:14 -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 IAA13908; Fri, 27 Jul 2001 08:15:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6RFE8a13614 for mobile-ip-dist; Fri, 27 Jul 2001 08:14:08 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6RFE4Y13607 for ; Fri, 27 Jul 2001 08:14:04 -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 IAA03378 for ; Fri, 27 Jul 2001 08:14:17 -0700 (PDT) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA13748 for ; Fri, 27 Jul 2001 09:15:42 -0600 (MDT) Received: by megisto-sql1.megisto.com with Internet Mail Service (5.5.2650.21) id ; Fri, 27 Jul 2001 11:14:12 -0400 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Agenda confusion Date: Fri, 27 Jul 2001 11:14:12 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) 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: Nope, your addition is correct. > -----Original Message----- > From: Hesham Soliman (ERA) [mailto:Hesham.Soliman@era.ericsson.se] > Sent: Friday, July 27, 2001 10:50 AM > To: 'mobile-ip@sunroof.eng.sun.com' > Subject: [mobile-ip] Agenda confusion > > > Hi Raj and Phil, > > I'm a bit confused. When I add up the time slots in the > agenda I find that we have one meeting, but the > MIP WG seems to have two meetings according to > the IETF agenda. Have I missed something ? > > Cheers, > Hesham > From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 27 11:42:58 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA28693 for ; Fri, 27 Jul 2001 11:42:58 -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 IAA12311; Fri, 27 Jul 2001 08:43:14 -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 IAA17985; Fri, 27 Jul 2001 08:41:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6RFeW213697 for mobile-ip-dist; Fri, 27 Jul 2001 08:40:32 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6RFeTY13690 for ; Fri, 27 Jul 2001 08:40:29 -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 IAA04140 for ; Fri, 27 Jul 2001 08:40:42 -0700 (PDT) Received: from netmail.alcatel.com (netmail.alcatel.com [128.251.168.50]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA19710 for ; Fri, 27 Jul 2001 09:40:40 -0600 (MDT) Received: from auds952.usa.alcatel.com (auds952.usa.alcatel.com [143.209.238.7]) by netmail.alcatel.com (8.9.1/8.9.1) with ESMTP id KAA28718 for ; Fri, 27 Jul 2001 10:40:40 -0500 (CDT) Received: from usa.alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f6RFeck19984 for ; Fri, 27 Jul 2001 10:40:38 -0500 (CDT) Message-ID: <3B618BD5.F5E4D05F@usa.alcatel.com> Date: Fri, 27 Jul 2001 10:42:13 -0500 From: Behcet Sarikaya Organization: Alcatel USA X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] agenda 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 I wonder what will happen in the second session of mobile ip WG on Tuesday between 1700-1800. Maybe time for the social event? Phil Roberts wrote: > Folks, > > here's what we'd like to ship. The only change since the last version > is a 10 minute slot for "handover smoothing." This is based on the > discussion generated from the draft on simultaneous bindings. I put > myself as the placeholder presenter for this but we'll determine how to > handle this as the discussion unfolds. > > Phil and Raj > > -------------------------------- > > Agenda Phil 5 minutes > Update on WG docs Phil 10 minutes > > This slot is for last minute updates. Here is the current status of docs > that are in last call or submitted to Abha. > > draft-ietf-mobileip-mier-07.txt (submitted) > draft-ietf-mobileip-gnaie-04.txt (submitted) > draft-ietf-mobileip-3g wireless-ext-06.txt (being updated based on IESG > feedback) > draft-ietf-mobileip-rfc2002-bis-06.txt (being updated based on IESG > feedback) > draft-ietf-mobileip-gen-key-00.txt (wg last call expires Friday 7/20 > hopefully submitted) > draft-ietf-mobileip-aaa-key-07.txt (to be submitted Friday 7/20) > draft-ietf-mobileip-qos-requirements-00.txt (wg last call expires 7/25) > draft-ietf-mobileip-reg-tunnel-04.txt (being updated) > draft-ietf-mobileip-optim-10.txt (past wg last call, sitting on it until > MIP v6 > issues resolved) > > Moving MIPv4 to draft standard Charlie 10 minutes > > Mobile IP v6 security update ? draft-team-mobileip-mipv6-sec-reqts-00.txt > 15 minutes > Mobile IP v6 other changes in -14 Charlie 5 minutes > draft-ietf-mobileip-ipv6-14.txt > > v4 Low Latency Handover Karim 5 minutes > draft-ietf-mobileip-lowlatency-handoffs-v4-01.txt > Is there anyone who can share implementation experiences? > Is this doc ready for last call? > > v6 Fast Handover draft-ietf-mobileip-fast-mipv6-01.txt > BETH addition? James 10 minutes draft-kempf-beth-ipv6-01.txt > Implementation experience report Rajeev Koodli 10 minutes > > Handover Smoothing Phil 10 minutes > > Mobile Network Support Thierry Ernst 15 minutes > Mobile IP Component Redundancy Gopal 10 minutes > > LMM Requirements Carl Williams 15 minutes > (draft-ietf-mobileip-lmm-requirements-00.txt) > > Issues from the list Raj 15 minutes -- Behcet From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 27 11:52:15 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA29607 for ; Fri, 27 Jul 2001 11:52:14 -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 JAA29310; Fri, 27 Jul 2001 09:52: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 IAA19787; Fri, 27 Jul 2001 08:52:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6RFpCH13780 for mobile-ip-dist; Fri, 27 Jul 2001 08:51:13 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6RFp9Y13773 for ; Fri, 27 Jul 2001 08:51:09 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA07017 for ; Fri, 27 Jul 2001 08:51:22 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA24017 for ; Fri, 27 Jul 2001 08:51:22 -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 IAA28638; Fri, 27 Jul 2001 08:51:21 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6RFpKl18771; Fri, 27 Jul 2001 08:51:20 -0700 X-mProtect: Fri, 27 Jul 2001 08:51:20 -0700 Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdSekkHR; Fri, 27 Jul 2001 08:51:18 PDT Message-ID: <3B618DF7.EB49F108@iprg.nokia.com> Date: Fri, 27 Jul 2001 08:51:19 -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: "Hesham Soliman (EPA)" CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Handover Smoothing - What to Do? References: <034BEFD03799D411A59F00508BDF754603008B74@esealnt448.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 again Hesham, > => I appreciate your logic, but, I believe whatever we do the > solution has to be good enough to meet our initial targets. In this case > there are two issues: > > - We've introduced a new concept in the v6 draft (and > the v4 one) and that is anticipation. This can have > negative impacts if not treated carefully. Right now it > isn't treated carefully in the v6 draft so I don't believe > the draft can go ahead with a gap in it because some > of us are not sure about the fix. I say we wait until we're > sure. Anyway the FMIPv6 draft will not become an RFC before > MIPv6 I hope. So what are we so rushed for ? I agree that there isn't a big timing issue until Mobile IPv6 can become Proposed Standard. As an aside, I've been taught that it's more appropriate to be specific here, because using the "RFC status" of a document is highly ambiguous and thus not directly germane to the issue you raise. > - A solution for the problem has been around for nearly > 2 years. How much more time is needed ? We don't > need every single one to set up experiments. This rule was never > followed in other drafts. Many people are accepting > the approach and it is suggested as an option. > Furthermore, the option is already in RFC2002 for > MIPv4 why is v6 any different ? > I think we should be consistent with this because there is > nothing v6 specific here. A lot of solutions have been around for more than two years, and still not standardized. That is almost totally irrelevant. Some of them have engendered dozens or even hundreds (?) of research papers and many implementations, and still no action by the working group. I hope you wouldn't continue to use that as any relevant criterion. The existence of the 'S' bit in RFC 2002 has never (to my knowledge) been tested for interoperability. My guess is that the same issues which in my opinion plague bicasting would also plague the use of the 'S' bit from RFC 2002. Also, as you have certainly noticed, there are other features of RFC 2002 which are not present within any specification for Mobile IPv6. For instance, there isn't any Prefix Information option, even though the feature was vehemently defended for Mobile IPv4. Thus, I do not believe that your point about the 'S' bit needs very much consideration. What is specific about IPv6 is that it has been specified for use with 3G telephony standards as the appropriate network-layer protocol and address space. That makes a lot of things matter in a way that was not true for IPv4. In fact, it has motivated a lot of the work on fast handovers. We have published work showing that duplicate packets CAN harm TCP connections if the interference is done systemically, or if it is done too often. I still have it as a work item to reconcile your claims otherwise with our experience. However, given the volume of fires that need to be put out right away, not to mention the volume of mail on these lists (!!), I've been unable to make that study. So I can only rely on our previous work and my strong intuition to continue to suggest extreme caution when proceeding to introduce systemic duplication in IP-based network connectivity. >> I would appreciate taking it out of the IPv4 draft, >> but I haven't had time to study that document so I >> have not made any comments. > > > => Sure. I look forward to your comments, but the question > on the agenda will be whether the draft should go for last > call .............. > We need something concrete as to whether a solution is > good or bad and why. What I might consider to be concrete may still be considered vague or inconclusive by you or anyone else, and vice versa. > Deciding which doc it should go in is not > important now if we can't agree on whether a solution > is good enough or not. If a solution isn't good enough, it doesn't belong in any standards- track document. If the solution's characteristics are debatable, then so is its inclusion in the standards document. In the case of smoothing techniques the debate can and should proceed independently. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 27 12:21:43 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02825 for ; Fri, 27 Jul 2001 12:21: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 KAA22161; Fri, 27 Jul 2001 10:22: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 JAA25125; Fri, 27 Jul 2001 09:21:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6RGKft13922 for mobile-ip-dist; Fri, 27 Jul 2001 09:20:41 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6RGKbY13915 for ; Fri, 27 Jul 2001 09:20: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 JAA24944 for ; Fri, 27 Jul 2001 09:20:51 -0700 (PDT) Received: from mail.verizonwireless.com ([199.74.158.61]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA13408 for ; Fri, 27 Jul 2001 10:22:10 -0600 (MDT) Received: from mail.verizonwireless.com by mail.verizonwireless.com (414/1100) with ESMTP id f6RG9nk12566 for ; Fri, 27 Jul 2001 12:09:49 -0400 (EDT) Received: by hqbedigwy2.corp.bam.com with Internet Mail Service (5.5.2653.19) id ; Fri, 27 Jul 2001 12:18:36 -0400 Message-ID: <43E8CCEAF148D211854C00805FA72E5808318F27@rhqnneex1.corp.bam.com> From: "Carroll, Christopher X" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] I-D ACTION:draft-ietf-mobileip-aaa-key-08.txt Date: Fri, 27 Jul 2001 12:20: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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Pat and Junhyuk, Just a few comments regarding Junhyuk's observations: The MN-FA key need not be used for MIP registration authentication only. The MN-FA key is a security association which can be used to enable other security services such as message encryption or authentication between the MN and FA. Junhyuk raises an interesting question that I alluded to in earlier e-mails: "Does the MN always possess only one MN-HA key or can it possess a series of MN-HA keys, one associated with each HA that it interfaces with?" Stated differently, "Does the AAA potentially pass the same MN-HA key to each HA when the MN is dynamically assigned a new HAs?" Finally, "Should the AAAh generate a new MN-HA key for each dynamic HA assignment?" In 3GPP2, the MN appears to possess one MN-HA key. Thus, when the MN is dynamically assigned to a new HA and registers, it uses the previously generated MN-HA key (also stored in the AAAh server) to generate the Mobile-Home Authentication Ext. When the new HA receives the RRQ and has no MN-HA key, it requests the MN-HA key from the AAAh and then checks the Mobile-Home Auth. Ext. Therefore, Junhyuk's comment that the HA must accept the initial registration without checking the MN-HA Auth. Ext. is not completely accurate in the 3GPP2 environment. His scenario only applies to the situation (within 3GPP2) in which the MN has no MN-HA key (when the MN is initially provisioned). Note: this may never occur where a service provider bootstraps the MN-HA key (using an out-of-band method) during initial provisioning. If the MN and HA have different MN-HA keys, the MN-HA key update process is inefficient, but should rarely occur. Verizon Wireless will never allow the HA to accept an RRQ that is not authenticated. Is it acceptable to allow the AAAh to pass the MN-HA key to a new HA? Yes, at least in the 3GPP2 environment where the network service provider will control and trust all of the HAs. It is extremely unlikely (at least until Diameter is available) that Verizon Wireless would allow HAs under a private company or individual's control. In the 3GPP2 environment, it is likely unnecessary to update the MN-HA key for every new HA assignment. From one perspective, the purpose of the MN-HA key, derived from the MN-AAA key using a one-way function, is to protect the root MN-AAA key. If, as Junhyuk proposes, the MN-AAA auth. Ext. is passed to the HA, the HA must check the extension using the MN-AAA key - not a good idea. The MN-AAA key is the root secret for the system and must reside in one, well-protected location - the AAA server (also in the MN). I realize that RADIUS AAA is an add-on to the original MIPv4 and is somewhat inefficient. However, I would rather protect the MN-AAA key and allow the AAAh to pass a modifiable MN-HA key to a new HA. If the MN-HA key is compromised, the AAAh can update it. If the MN-AAA key is compromised, then the service provider must distribute a new MN-AAA key to potentially millions of MNs. As an alternative to using the Foreign-Home Auth. Ext., 3GPP2 service providers will use IPsec between the PDSN/FA and the HA. I don't beleive it is necessary to mandate HA-FA authentication especially since other alternatives exist to protect that link. regards, chris On Fri, Jul 27, 2001 at 09:07:20PM +0900, junhyuk song wrote: > Hi Pat, > > I don't see the need for MN-FA shared key while using FAC and MN-AAA authentication. > The AAAH will verify Mobile Node for Foreign Agent with MN-AAA authenticatiion defined in RFC3012. It seems to me using MN-FA Auth and FAC with MN-AAA Auth together is somewhat redundant. It isn't redundant since the AAA and the FA may be owned by separate administrative domains. Having said that, no where in the draft does it state that the MN-FA is to be present if the MN-AAA is present. > Besides, I wish you made separate section for RADIUS consideration in your draft. why? This draft discusses how the keys are sent to the mobile node, not to a RADIUS and/or Diameter device. The AAA software used is completely irrelevant to this draft (unless I missed something). > Further more the RADIUS based AAA case must be noted for DOS attack consideration, because HA will blindly procede Mobile IP signalling and AAA message without MN-HA authentication for the initial RRQ. Another approach is clearly defining MN-AAA authentication from HA before AAAH procede to generate "Key Material" and "Mn-HA shared key". Right, and this was one of the reasons why we decided to allow the FA to forward the messages to the AAA infrastructure in Diameter. 3GPP2 decided to let the HA to the work, and that is simply the wrong approach, and will lead to DoS attacks. I've brought this up numerous times, and the real fix is to change how 3GPP2 handles AAA (not necessarily the protocol, but rather the way it uses RADIUS). > It also may be helpful to mandate HA-FA authentication between FA and HA. If keys are generated, yes, but this is not covered by this draft. It seems like what you are requesting is really in the Diameter Mobile IP application, and not in this one. PatC From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 27 12:21:44 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02839 for ; Fri, 27 Jul 2001 12:21:43 -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 JAA29014; Fri, 27 Jul 2001 09:22: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 JAA25112; Fri, 27 Jul 2001 09:21:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6RGKLm13913 for mobile-ip-dist; Fri, 27 Jul 2001 09:20:21 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6RGKHY13906 for ; Fri, 27 Jul 2001 09:20: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 JAA12505 for ; Fri, 27 Jul 2001 09:20:31 -0700 (PDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA20731 for ; Fri, 27 Jul 2001 10:20:28 -0600 (MDT) Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f6RGKTO09450 for ; Fri, 27 Jul 2001 18:20:29 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Fri Jul 27 18:20:28 2001 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 27 Jul 2001 18:14:17 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008B77@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Handover Smoothing - What to Do? Date: Fri, 27 Jul 2001 18:20:24 +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: Hello Charlie, > > - A solution for the problem has been around for nearly > > 2 years. How much more time is needed ? We don't > > need every single one to set up experiments. This rule was never > > followed in other drafts. Many people are accepting > > the approach and it is suggested as an option. > > Furthermore, the option is already in RFC2002 for > > MIPv4 why is v6 any different ? > > I think we should be consistent with this because there is > > nothing v6 specific here. > > A lot of solutions have been around for more than two years, and > still not standardized. That is almost totally irrelevant. > Some of them have engendered dozens or even hundreds (?) of research > papers and many implementations, and still no action by the > working group. I hope you wouldn't continue to use that as any > relevant criterion. > => The point is that there has been time to assess the solution. There are certainly many solutions that never get used but reasons would be great. That's what I'd like to focus on. > The existence of the 'S' bit in RFC 2002 has never (to my knowledge) > been tested for interoperability. My guess is that the same issues > which in my opinion plague bicasting would also plague the use of > the 'S' bit from RFC 2002. > => I disagree, it was never used because there was no use for it up until the low latency draft proposed a use. I'm sure it will be more popular now. In fact I know of an implementation that used it and I pointed a reference in a previous mail. > What is specific about IPv6 is that it has been specified for use > with 3G telephony standards as the appropriate network-layer protocol > and address space. That makes a lot of things matter in a way that > was not true for IPv4. In fact, it has motivated a lot of the work > on fast handovers. > => That's a deployment issue not a technical one. The 3G telephone standards that use IPv6 have not even specified a use for MIPv6. My point is there are no technical reasons for allowing it in one version and not the other. If I interpret what you're saying above I think it tells me "there are more people who care about IPv6 now and therefore not considering the IPv4 low laetncy draft". That pleases me a lot but it's still not a technical reason. > We have published work showing that duplicate packets CAN harm > TCP connections if the interference is done systemically, or > if it is done too often. I still have it as a work item to reconcile > your claims otherwise with our experience. > => Great, I'd be very interested in a pointer. > However, given the volume > of fires that need to be put out right away, not to mention the volume > of mail on these lists (!!), I've been unable to make that study. > So I can only rely on our previous work and my strong intuition to > continue to suggest extreme caution when proceeding to introduce > systemic duplication in IP-based network connectivity. > => Duplication is not new to the Internet. If you're basing this on your studies I'd appreciate a pointer to a paper or a report. I might find that our claims are completely bogus, but some proof would be good. > >> I would appreciate taking it out of the IPv4 draft, > >> but I haven't had time to study that document so I > >> have not made any comments. > > > > > => Sure. I look forward to your comments, but the question > > on the agenda will be whether the draft should go for last > > call .............. > > We need something concrete as to whether a solution is > > good or bad and why. > > What I might consider to be concrete may still be considered > vague or inconclusive by you or anyone else, and vice versa.> > => Hence the beauty of concensus. It doesn't matter what I think if enough people agree. I'll continue to disagree though till I find a proof for being wrong and would then be happy to withdraw my support for the proposal. Regards, Hesham From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 27 12:35:00 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04426 for ; Fri, 27 Jul 2001 12:34:59 -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 KAA02428; Fri, 27 Jul 2001 10:35:17 -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 JAA20861; Fri, 27 Jul 2001 09:35:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6RGXeO14164 for mobile-ip-dist; Fri, 27 Jul 2001 09:33:40 -0700 (PDT) Received: from locked.eng.sun.com (locked [129.146.85.189]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6RGXaY14157 for ; Fri, 27 Jul 2001 09:33:36 -0700 (PDT) Received: (from mohanp@localhost) by locked.eng.sun.com (8.11.2+Sun/8.11.2) id f6RGWNc29235 for mobile-ip@sunroof.eng.sun.com; Fri, 27 Jul 2001 09:32:23 -0700 (PDT) From: Mohan Parthasarathy Message-Id: <200107271632.f6RGWNc29235@locked.eng.sun.com> Subject: Re: [mobile-ip] New authentication scheme in Mobile IPv6 draft revision...-14 In-Reply-To: <3B60F367.1136AAE9@iprg.nokia.com> from Charlie Perkins at "Jul 26, 2001 09:51:51 pm" To: mobile-ip@sunroof.eng.sun.com Date: Fri, 27 Jul 2001 09:32:23 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL66 (25)] 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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > Hello Mohan, > > I thought that the use of AH and the use of the authentication > data within the Binding Update were to be logically independent, > so that the presence of one would not affect the presence of > the other (except insofar as the AH data would be computed > over the Binding Update option fields). So I don't see why > any of the fields would have to be zero if AH were present. > The AH could theoretically be computed using an algorithm > that was less secure than the Binding Update authentication > algorithm. > I don't have a problem with that. But it is not clear when IPsec would be used, whether IPsec would be used at all etc. reading the draft. If BU has auth data in it, reader would first assume that IPsec is not used at all. First of all i don't remember this being discussed on the mailing list before. So, it took most of us by surprise. -mohan > Regards, > Charlie P. > > > > Mohan Parthasarathy wrote: > > > Charlie, > > > > You still want to have the possibility of using IPsec between MN and > > HA. In that case the i would assume that some of the fields mentioned > > in section 4.4. will be zero. In Section 4.4 Authentication requirements, > > it does not talk about IPsec at all. It will be needed if we still > > think that we may allow IPsec between MN and HA. Section 10.2 still > > talks about Outbound IPsec processing. It looks a bit confusing to me. > > > > -mohan > > > > > Hello folks, > > > > > > Somehow, the e-mail address on this note got truncated, so > > > I am resending to this list. > > > > > > Regards, > > > Charlie P. > > > > > > > > > -------- Original Message -------- > > > Subject: New authentication scheme in Mobile IPv6 draft revision ...-14 > > > Date: Thu, 26 Jul 2001 12:28:13 -0700 > > > From: "Charles E. Perkins" > > > Organization: Nokia Research Center > > > To: Bill Sommerfeld > > > CC: mobile-ip@sunroof.eng.sun.co > > > References: <200107251556.f6PFuTS21588@thunk.east.sun.com> > > > > > > > > > Hello Bill, > > > > > > Draft revision ...-14 incorporates the authentication data as part of > > > the Binding Update option itself. I thought that this modification > > > was essentially mandated by Jeff Schiller's comments at the last IETF, > > > and the surrounding discussion about use of IPsec vs. various > > > destination options. > > > > > > One good thing about this arrangement is that it allows the verification > > > of the Binding Update authentication data to happen independently of > > > any IPsec requirement between the mobile node and the recipient of the > > > Binding Update. To me, this seems like a good thing, and I am hoping > > > that you would agree. > > > > > > > This is a *consequence* of the issue I pointed out yesterday: namely, > > > > that if you allow for traffic on a connection/flow to contain a mix of > > > > encrypted and unencrypted packets, you open yourself up to various > > > > nasty denial of service attacks, and IPsec cannot provide useful > > > > guarantees to upper layers. > > > > > > Could you make a small description about how the attacks work? > > > > > > I would have thought that IPsec should be applied depending on the > > > kind of socket opened by the application, but maybe not... > > > > > > >> if piggybacking a BU was the problem, we could have solved > > > >> it long back. just disallow piggybacking. anyway its a 'MAY' > > > >> in the current draft. you dont lose much by not piggybacking > > > >> the BU. > > > > > > > > I disagree. If it's a "MAY", then folks will build implementations > > > > which always piggyback, which will cause interoperabilty problems with > > > > IPsec implementations (such as Solaris's) which do per-connection > > > > policy checks. > > > > > > Doesn't this problem go away entirely in draft ...-14? > > > > > > > > > > > > Regards, > > > Charlie P. > From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 27 12:36:19 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04552 for ; Fri, 27 Jul 2001 12:36:18 -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 JAA01956; Fri, 27 Jul 2001 09:28: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 JAA25454; Fri, 27 Jul 2001 09:23:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6RGMPX13972 for mobile-ip-dist; Fri, 27 Jul 2001 09:22:25 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6RGMLY13961 for ; Fri, 27 Jul 2001 09:22:21 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA01750 for ; Fri, 27 Jul 2001 09:22:35 -0700 (PDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id JAA10212 for ; Fri, 27 Jul 2001 09:22:34 -0700 (PDT) Received: (qmail 21439 invoked by uid 500); 27 Jul 2001 16:11:26 -0000 Date: Fri, 27 Jul 2001 09:11:26 -0700 From: Pat Calhoun To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Handover Smoothing - What to Do? Message-ID: <20010727091126.C13541@charizard.diameter.org> References: <034BEFD03799D411A59F00508BDF754603008B74@esealnt448.al.sw.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: <034BEFD03799D411A59F00508BDF754603008B74@esealnt448.al.sw.ericsson.se>; from Hesham.Soliman@era.ericsson.se on Fri, Jul 27, 2001 at 04:24:59PM +0200 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: > - We've introduced a new concept in the v6 draft (and > the v4 one) and that is anticipation. This can have > negative impacts if not treated carefully. Right now it > isn't treated carefully in the v6 draft so I don't believe > the draft can go ahead with a gap in it because some > of us are not sure about the fix. I say we wait until we're > sure. Anyway the FMIPv6 draft will not become an RFC before > MIPv6 I hope. So what are we so rushed for ? That fine, but we cannot postpone the low latency v4 draft just because the v6 one isn't ready to go. PatC From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 27 12:42:16 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05282 for ; Fri, 27 Jul 2001 12:42:15 -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 JAA07735; Fri, 27 Jul 2001 09:42:28 -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 JAA20158; Fri, 27 Jul 2001 09:32:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6RGUSY14094 for mobile-ip-dist; Fri, 27 Jul 2001 09:30:28 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6RGUPY14087 for ; Fri, 27 Jul 2001 09:30:25 -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 JAA19831 for ; Fri, 27 Jul 2001 09:30:39 -0700 (PDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA18219 for ; Fri, 27 Jul 2001 10:32:03 -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.11.0/8.11.0/WIREfire-1.3) with SMTP id f6RGUWN09891 for ; Fri, 27 Jul 2001 18:30:32 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Fri Jul 27 18:30:32 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Fri, 27 Jul 2001 18:30:32 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008B79@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Handover Smoothing - What to Do? Date: Fri, 27 Jul 2001 18:30:22 +0200 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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > - We've introduced a new concept in the v6 draft (and > > the v4 one) and that is anticipation. This can have > > negative impacts if not treated carefully. Right now it > > isn't treated carefully in the v6 draft so I don't believe > > the draft can go ahead with a gap in it because some > > of us are not sure about the fix. I say we wait until we're > > sure. Anyway the FMIPv6 draft will not become an RFC before > > MIPv6 I hope. So what are we so rushed for ? > > That fine, but we cannot postpone the low latency v4 draft just because > the v6 one isn't ready to go. > => I didn't suggest that. I'd like it to go to last call after London and I thought we (the authors) agreed on that. It's fine as it is and we got no comments suggesting anything was missing. I guess that's why we have this question on the agenda Hesham From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 27 12:46:06 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05658 for ; Fri, 27 Jul 2001 12:46:06 -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 JAA09317; Fri, 27 Jul 2001 09:46:10 -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 JAA21750; Fri, 27 Jul 2001 09:38:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6RGbZo14365 for mobile-ip-dist; Fri, 27 Jul 2001 09:37:35 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6RGbVY14353 for ; Fri, 27 Jul 2001 09:37:31 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA21561 for ; Fri, 27 Jul 2001 09:37:44 -0700 (PDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id JAA06233 for ; Fri, 27 Jul 2001 09:37:44 -0700 (PDT) Received: (qmail 21543 invoked by uid 500); 27 Jul 2001 16:26:37 -0000 Date: Fri, 27 Jul 2001 09:26:37 -0700 From: Pat Calhoun To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] I-D ACTION:draft-ietf-mobileip-aaa-key-08.txt Message-ID: <20010727092637.F13541@charizard.diameter.org> References: <43E8CCEAF148D211854C00805FA72E5808318F27@rhqnneex1.corp.bam.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <43E8CCEAF148D211854C00805FA72E5808318F27@rhqnneex1.corp.bam.com>; from Christopher.Carroll@VerizonWireless.com on Fri, Jul 27, 2001 at 12:20:48PM -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: Christopher, I think you missed my original point. In the Diameter model, the absence of the MN-HA is acceptable because there is inherent trust between the AAAH and the HA. So, if the mobile is authenticated on the AAAH, and an authenticated message is sent from the AAAH to the HA, then the HA will use that as a replacement to the MN-HA. The issue is how 3GPP2 decided to make use of RADIUS. They didn't have alot of choices due to the protocol's inability for servers to send unsolicited messages to clients (but I believe this has been added anyways since then). So, this is really a RADIUS deficiency, and I see no reason for Mobile IP to design a secure network for 3GPP2, when the RADIUS (the IETF version, not w/ 3GPP2's extensions) cannot provide that. PatC On Fri, Jul 27, 2001 at 12:20:48PM -0400, Carroll, Christopher X wrote: > Hi Pat and Junhyuk, > > Just a few comments regarding Junhyuk's observations: > > The MN-FA key need not be used for MIP registration authentication only. > The MN-FA key is a security association which can be used to enable other > security services such as message encryption or authentication between the > MN and FA. > > Junhyuk raises an interesting question that I alluded to in earlier e-mails: > "Does the MN always possess only one MN-HA key or can it possess a series of > MN-HA keys, one associated with each HA that it interfaces with?" Stated > differently, "Does the AAA potentially pass the same MN-HA key to each HA > when the MN is dynamically assigned a new HAs?" Finally, "Should the AAAh > generate a new MN-HA key for each dynamic HA assignment?" > > In 3GPP2, the MN appears to possess one MN-HA key. Thus, when the MN is > dynamically assigned to a new HA and registers, it uses the previously > generated MN-HA key (also stored in the AAAh server) to generate the > Mobile-Home Authentication Ext. When the new HA receives the RRQ and has no > MN-HA key, it requests the MN-HA key from the AAAh and then checks the > Mobile-Home Auth. Ext. > > Therefore, Junhyuk's comment that the HA must accept the initial > registration without checking the MN-HA Auth. Ext. is not completely > accurate in the 3GPP2 environment. His scenario only applies to the > situation (within 3GPP2) in which the MN has no MN-HA key (when the MN is > initially provisioned). Note: this may never occur where a service provider > bootstraps the MN-HA key (using an out-of-band method) during initial > provisioning. If the MN and HA have different MN-HA keys, the MN-HA key > update process is inefficient, but should rarely occur. Verizon Wireless > will never allow the HA to accept an RRQ that is not authenticated. > > Is it acceptable to allow the AAAh to pass the MN-HA key to a new HA? Yes, > at least in the 3GPP2 environment where the network service provider will > control and trust all of the HAs. It is extremely unlikely (at least until > Diameter is available) that Verizon Wireless would allow HAs under a private > company or individual's control. In the 3GPP2 environment, it is likely > unnecessary to update the MN-HA key for every new HA assignment. > > From one perspective, the purpose of the MN-HA key, derived from the MN-AAA > key using a one-way function, is to protect the root MN-AAA key. If, as > Junhyuk proposes, the MN-AAA auth. Ext. is passed to the HA, the HA must > check the extension using the MN-AAA key - not a good idea. The MN-AAA key > is the root secret for the system and must reside in one, well-protected > location - the AAA server (also in the MN). I realize that RADIUS AAA is an > add-on to the original MIPv4 and is somewhat inefficient. However, I would > rather protect the MN-AAA key and allow the AAAh to pass a modifiable MN-HA > key to a new HA. If the MN-HA key is compromised, the AAAh can update it. > If the MN-AAA key is compromised, then the service provider must distribute > a new MN-AAA key to potentially millions of MNs. > > As an alternative to using the Foreign-Home Auth. Ext., 3GPP2 service > providers will use IPsec between the PDSN/FA and the HA. I don't beleive it > is necessary to mandate HA-FA authentication especially since other > alternatives exist to protect that link. > > regards, > > chris > > > > On Fri, Jul 27, 2001 at 09:07:20PM +0900, junhyuk song wrote: > > Hi Pat, > > > > I don't see the need for MN-FA shared key while using FAC and MN-AAA > authentication. > > The AAAH will verify Mobile Node for Foreign Agent with MN-AAA > authenticatiion defined in RFC3012. It seems to me using MN-FA Auth and FAC > with MN-AAA Auth together is somewhat redundant. > > It isn't redundant since the AAA and the FA may be owned by separate > administrative domains. Having said that, no where in the draft does it > state that the MN-FA is to be present if the MN-AAA is present. > > > Besides, I wish you made separate section for RADIUS consideration in your > draft. > > why? This draft discusses how the keys are sent to the mobile node, not > to a RADIUS and/or Diameter device. > > The AAA software used is completely irrelevant to this draft (unless I > missed > something). > > > > Further more the RADIUS based AAA case must be noted for DOS attack > consideration, because HA will blindly procede Mobile IP signalling and AAA > message without MN-HA authentication for the initial RRQ. Another approach > is clearly defining MN-AAA authentication from HA before AAAH procede to > generate "Key Material" and "Mn-HA shared key". > > Right, and this was one of the reasons why we decided to allow the FA to > forward the messages to the AAA infrastructure in Diameter. 3GPP2 decided > to let the HA to the work, and that is simply the wrong approach, and will > lead to DoS attacks. I've brought this up numerous times, and the real fix > is to change how 3GPP2 handles AAA (not necessarily the protocol, but rather > the way it uses RADIUS). > > > It also may be helpful to mandate HA-FA authentication between FA and HA. > > If keys are generated, yes, but this is not covered by this draft. It seems > like what you are requesting is really in the Diameter Mobile IP > application, > and not in this one. > > PatC From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 27 12:49:26 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05995 for ; Fri, 27 Jul 2001 12:49:25 -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 JAA10023; Fri, 27 Jul 2001 09:47:48 -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 JAA20153; Fri, 27 Jul 2001 09:32:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6RGUW914103 for mobile-ip-dist; Fri, 27 Jul 2001 09:30:32 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6RGUSY14096 for ; Fri, 27 Jul 2001 09:30: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 JAA03387 for ; Fri, 27 Jul 2001 09:30:42 -0700 (PDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id KAA28549 for ; Fri, 27 Jul 2001 10:30:40 -0600 (MDT) Received: (qmail 21508 invoked by uid 500); 27 Jul 2001 16:19:35 -0000 Date: Fri, 27 Jul 2001 09:19:35 -0700 From: Pat Calhoun To: mobile-ip@sunroof.eng.sun.com Cc: "Hesham Soliman \(EPA\)" Subject: Re: [mobile-ip] Handover Smoothing - What to Do? Message-ID: <20010727091935.D13541@charizard.diameter.org> References: <034BEFD03799D411A59F00508BDF754603008B74@esealnt448.al.sw.ericsson.se> <3B618DF7.EB49F108@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: <3B618DF7.EB49F108@iprg.nokia.com>; from charliep@iprg.nokia.com on Fri, Jul 27, 2001 at 08:51:19AM -0700 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 existence of the 'S' bit in RFC 2002 has never (to my knowledge) > been tested for interoperability. My guess is that the same issues > which in my opinion plague bicasting would also plague the use of > the 'S' bit from RFC 2002. Also, as you have certainly noticed, there > are other features of RFC 2002 which are not present within any > specification for Mobile IPv6. For instance, there isn't any > Prefix Information option, even though the feature was vehemently > defended for Mobile IPv4. Thus, I do not believe that your point > about the 'S' bit needs very much consideration. In my personal opinion (having been to the interops), most folks hadn't tested (or even implemented) the 'S' bit because no one knew how it would ever be used in the real world. I believe that folks now have a reason for implementing it. > What is specific about IPv6 is that it has been specified for use > with 3G telephony standards as the appropriate network-layer protocol > and address space. That makes a lot of things matter in a way that > was not true for IPv4. In fact, it has motivated a lot of the work > on fast handovers. hmmmm..... v4 fast handoff was done prior to the v6 work, so I'm not sure why you seem to claim that v6 is the one used by telephony standards. In fact, the cdma2000 folks will be using v4, including Mobile IP, well before the v6 proponents. Perhaps I missed your point. > We have published work showing that duplicate packets CAN harm > TCP connections if the interference is done systemically, or > if it is done too often. I still have it as a work item to reconcile > your claims otherwise with our experience. However, given the volume > of fires that need to be put out right away, not to mention the volume > of mail on these lists (!!), I've been unable to make that study. > So I can only rely on our previous work and my strong intuition to > continue to suggest extreme caution when proceeding to introduce > systemic duplication in IP-based network connectivity. Yes, and there are known fixes to the problem you mention. We cannot live in perpetual darkness just because some folks don't have an OS with the necessary fix. Let's move forward. People interested in fast handoffs will have their stacks fixed. I, like you, am too busy, but I don't want the work to stall in the WG until I have the time to catch up. Thanks, PatC From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 27 12:51:43 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA06292 for ; Fri, 27 Jul 2001 12:51:42 -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 KAA14942; Fri, 27 Jul 2001 10:52:15 -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 JAA25603; Fri, 27 Jul 2001 09:51:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6RGogG14627 for mobile-ip-dist; Fri, 27 Jul 2001 09:50:42 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6RGocY14620 for ; Fri, 27 Jul 2001 09:50:38 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA01805 for ; Fri, 27 Jul 2001 09:50:52 -0700 (PDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id JAA11462 for ; Fri, 27 Jul 2001 09:50:51 -0700 (PDT) Received: (qmail 21669 invoked by uid 500); 27 Jul 2001 16:39:45 -0000 Date: Fri, 27 Jul 2001 09:39:45 -0700 From: Pat Calhoun To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Handover Smoothing - What to Do? Message-ID: <20010727093945.K13541@charizard.diameter.org> References: <034BEFD03799D411A59F00508BDF754603008B7B@esealnt448.al.sw.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: <034BEFD03799D411A59F00508BDF754603008B7B@esealnt448.al.sw.ericsson.se>; from Hesham.Soliman@era.ericsson.se on Fri, Jul 27, 2001 at 06:44:42PM +0200 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 Fri, Jul 27, 2001 at 06:44:42PM +0200, Hesham Soliman (ERA) wrote: > > Not a technical reason, as well as completely false. Please remember > > that there are two (2) 3G organizations. Both of you seem to be ignoring > > the one that's actually using the stacks developed in this WG. > > > => Pat, do I have a sign today saying "Pat please misunderstand me" :)) At least I'd know your intentions :) :) > I know there are two and was only referring to the "one" mandating > IPv6 for telephony. That was not 3GPP2 last time I checked. > Things might have changed though... I hope I was wrong. I may have misunderstood all of your e-mails today, and if so, please accept my appologies. 3GPP2 is planning on using IP for telephony, but v4 will be supported (given that they already have Mobile IPv4 trials and some limited deployments already). They are planning on moving towards v6, but prior to doing so, need some reassurances that Mobile IPv6 will move forward. So far, they haven't had any such reassurances :( PatC From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 27 12:55:23 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA06833 for ; Fri, 27 Jul 2001 12:55:22 -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 JAA13711; Fri, 27 Jul 2001 09:55:40 -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 JAA25783; Fri, 27 Jul 2001 09:52:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6RGp0b14636 for mobile-ip-dist; Fri, 27 Jul 2001 09:51:00 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6RGotY14629 for ; Fri, 27 Jul 2001 09:50:55 -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 JAA25452 for ; Fri, 27 Jul 2001 09:51:08 -0700 (PDT) Received: from netmail2.alcatel.com (netmail2.alcatel.com [128.251.168.51]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA28586 for ; Fri, 27 Jul 2001 10:52:34 -0600 (MDT) Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80]) by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id LAA03640 for ; Fri, 27 Jul 2001 11:51:04 -0500 (CDT) Received: from usa.alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f6RGp4l27899 for ; Fri, 27 Jul 2001 11:51:04 -0500 (CDT) Message-ID: <3B619C56.1164ED54@usa.alcatel.com> Date: Fri, 27 Jul 2001 11:52:38 -0500 From: Behcet Sarikaya Organization: Alcatel USA X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] I-D ACTION:draft-ietf-mobileip-fast-mipv6-02.txt References: <200107271107.HAA06665@ietf.org> <3B6165D5.8324B195@ipsi.fraunhofer.de> 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 Could someone please correct the formating and repost this draft? Wolfgang Schoenfeld wrote: > Thanks for reworking it! > But why is it now doubly spaced? > In order to be even faster? :-) > > Wolfgang > > Internet-Drafts@ietf.org schrieb: > > > > 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 : Fast Handovers for Mobile IPv6 > > Author(s) : G. Dommety, A. Yegin, C. Perkins, G. Tsirtsis, > > K. Malki, M. Khalil > > Filename : draft-ietf-mobileip-fast-mipv6-02.txt > > Pages : 36 > > Date : 26-Jul-01 > > > > This document specifies protocol enhancements to MIPv6 that enable > > mobile nodes to quickly change their point of attachment to the > > Internet, i.e., move from one Access Router to another. These > > protocol enhancements are intended to minimize the time during which > > a mobile node is unable to send or receive IPv6 packets (i.e., the > > handover latency). > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-mobileip-fast-mipv6-02.txt > > > > 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-fast-mipv6-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-fast-mipv6-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. > > > > ---------------------------------------------------------------------------------------------------- > > Content-Type: text/plain > > Content-ID: <20010726170616.I-D@ietf.org> > > -- > Wolfgang Schoenfeld, Fraunhofer IPSI, Dolivostr. 15, D-64293 Darmstadt > Office: +49-6151-869-865 FAX: -6847 Mobile: +49-174-7093455 -- Behcet From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 27 12:58:08 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07135 for ; Fri, 27 Jul 2001 12:58:07 -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 JAA09952; Fri, 27 Jul 2001 09:47:36 -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 JAA24127; Fri, 27 Jul 2001 09:46:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6RGieJ14475 for mobile-ip-dist; Fri, 27 Jul 2001 09:44:40 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6RGiaY14468 for ; Fri, 27 Jul 2001 09:44:37 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA00329 for ; Fri, 27 Jul 2001 09:44:50 -0700 (PDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA20577 for ; Fri, 27 Jul 2001 09:44:49 -0700 (PDT) Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f6RGimO13145 for ; Fri, 27 Jul 2001 18:44:48 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Fri Jul 27 18:44:48 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Fri, 27 Jul 2001 18:44:48 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008B7B@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Handover Smoothing - What to Do? Date: Fri, 27 Jul 2001 18:44:42 +0200 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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > => That's a deployment issue not a technical one. The 3G telephone > > standards that use IPv6 have not even specified a use for MIPv6. > > My point is there are no technical reasons for allowing it in > > one version and not the other. If I interpret what you're > > saying above I think it tells me "there are more people who > > care about IPv6 now and therefore not considering the IPv4 > > low laetncy draft". That pleases me a lot but it's still not > > a technical reason. > > Not a technical reason, as well as completely false. Please remember > that there are two (2) 3G organizations. Both of you seem to be ignoring > the one that's actually using the stacks developed in this WG. > => Pat, do I have a sign today saying "Pat please misunderstand me" :)) I know there are two and was only referring to the "one" mandating IPv6 for telephony. That was not 3GPP2 last time I checked. Things might have changed though... I hope I was wrong. Hesham From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 27 13:01:20 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA07493 for ; Fri, 27 Jul 2001 13:01:20 -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 KAA15773; Fri, 27 Jul 2001 10:00:10 -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 JAA20599; Fri, 27 Jul 2001 09:34:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6RGX6814146 for mobile-ip-dist; Fri, 27 Jul 2001 09:33:06 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6RGX3Y14139 for ; Fri, 27 Jul 2001 09:33: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 JAA15136 for ; Fri, 27 Jul 2001 09:33:17 -0700 (PDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id KAA19552 for ; Fri, 27 Jul 2001 10:34:38 -0600 (MDT) Received: (qmail 21518 invoked by uid 500); 27 Jul 2001 16:22:01 -0000 Date: Fri, 27 Jul 2001 09:22:01 -0700 From: Pat Calhoun To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Handover Smoothing - What to Do? Message-ID: <20010727092201.E13541@charizard.diameter.org> References: <034BEFD03799D411A59F00508BDF754603008B77@esealnt448.al.sw.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: <034BEFD03799D411A59F00508BDF754603008B77@esealnt448.al.sw.ericsson.se>; from Hesham.Soliman@era.ericsson.se on Fri, Jul 27, 2001 at 06:20:24PM +0200 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: > => That's a deployment issue not a technical one. The 3G telephone > standards that use IPv6 have not even specified a use for MIPv6. > My point is there are no technical reasons for allowing it in > one version and not the other. If I interpret what you're > saying above I think it tells me "there are more people who > care about IPv6 now and therefore not considering the IPv4 > low laetncy draft". That pleases me a lot but it's still not > a technical reason. Not a technical reason, as well as completely false. Please remember that there are two (2) 3G organizations. Both of you seem to be ignoring the one that's actually using the stacks developed in this WG. PatC From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 27 13:01:35 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA07566 for ; Fri, 27 Jul 2001 13:01:34 -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 KAA16249; Fri, 27 Jul 2001 10:01:06 -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 JAA25333; Fri, 27 Jul 2001 09:50:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6RGnoc14601 for mobile-ip-dist; Fri, 27 Jul 2001 09:49:50 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6RGnlY14594 for ; Fri, 27 Jul 2001 09:49: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 JAA07483 for ; Fri, 27 Jul 2001 09:50:00 -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 KAA28003 for ; Fri, 27 Jul 2001 10:51: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 JAA05320 for ; Fri, 27 Jul 2001 09:49:57 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6RGnvu15361 for ; Fri, 27 Jul 2001 09:49:57 -0700 X-mProtect: Fri, 27 Jul 2001 09:49:57 -0700 Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdmNtpWS; Fri, 27 Jul 2001 09:49:55 PDT Message-ID: <3B619BB3.8078D7B8@iprg.nokia.com> Date: Fri, 27 Jul 2001 09:49:55 -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: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Handover Smoothing - What to Do? References: <200107270131.SAA16062@heliopolis.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 Hi, James Kempf wrote: > Hi again Rajeev, > > >The actual process depends however on the end-to-end network dynamics. For > example, > >if there is a talkspurt during handover followed by an idle time, then you > could > >drain the buffer without actually propagating the delay per se. You might > affect the > >start time of the *next* talkspurt however, in the sense that the idle time is > not > >exactly the same as that of the sener's. However, this is not a big deal in > packet > >networks with jitter buffers and smart playback adjustment. > > > > It doesn't have anything to do with the network dynamics. If I buffer during > time T(0), then it takes me T(1) to download, so I must buffer during > that period. I download the T(1) buffer during time T(2), during > which time I have to download, etc. It's a simple geometric series. > Look in Appendix B of draft-kempf-beth-ipv6-01.txt for the math. > > Perhaps I am missing something (or did a poor job of explaining what I had in mind).. However, in your above illustration, during T(1) when you are downloading, what if there is nothing to buffer ? Regards, -Rajeev > On second thought, maybe I ought to just post a summary of the analysis, > since we seem to be talking around it. > > jak From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 27 13:09:59 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08452 for ; Fri, 27 Jul 2001 13:09:59 -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 KAA17496; Fri, 27 Jul 2001 10:03:28 -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 JAA24637; Fri, 27 Jul 2001 09:48:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6RGl9W14560 for mobile-ip-dist; Fri, 27 Jul 2001 09:47:09 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6RGl4Y14553 for ; Fri, 27 Jul 2001 09:47: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 JAA18009 for ; Fri, 27 Jul 2001 09:47:18 -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 KAA26465 for ; Fri, 27 Jul 2001 10:48:43 -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 JAA05040 for ; Fri, 27 Jul 2001 09:47:07 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6RGl7f06443 for ; Fri, 27 Jul 2001 09:47:07 -0700 X-mProtect: Fri, 27 Jul 2001 09:47:07 -0700 Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdB6JK1v; Fri, 27 Jul 2001 09:47:05 PDT Message-ID: <3B619B09.BCE5904B@iprg.nokia.com> Date: Fri, 27 Jul 2001 09:47:05 -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: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Handover Smoothing - What to Do? References: <200107270128.SAA15910@heliopolis.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 James Kempf wrote: > Hello James, > > >Actually, we have defined a "New-IP-Address" extension that a MN sends right > after it > >attaches to the new-AR. [In FMIPv6, the new CoA acquisition happens before the > MN > >attaches to the new-AR.] This would be an extension to a compressed rohc packet > that > >updates the state at the new-AR. Note that there is a framework defined in > rohc-rtp > >draft (now an RFC) to carry extensions. > > > > I am really skeptical of the MN doing any signalling over the air when it > gets to new AR on 3G-like links. I frankly don't think there will be time for > all the stuff in the FMIPv6 draft (FBU,FBACK, etc.) if there is > a 6-8 kbps real time stream coming at the mobile and the uplink > is 9.6 kbps. To say nothing of additional extensions. Hence > the BETH proposal. > I agree that it can be "customized". The reason for keeping the control to the MN is a) it is a general-purpose solution, b) you never know if the MN will actuall use the new IP address for sure until the MN actually arrives at the new-AR, and c) this extension would fit right into the existing [rohc] framework so that no modifications to the compression method on the MN is necessary. Perhaps in the next revision, we will define how to optimize the signaling while also taking the above reasons (esp c)) into account. Regards, -Rajeev > > I think there needs to be an option in fast handover where there > is absolutely no L3 signalling between the MN and network, for > those cases where the radio uplink is slow and the incoming data > stream is about using up the uplink capacity. > > jak From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 27 13:36:54 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11377 for ; Fri, 27 Jul 2001 13:36:53 -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 KAA04162; Fri, 27 Jul 2001 10:37:15 -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 KAA13088; Fri, 27 Jul 2001 10:35:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6RHYLt15124 for mobile-ip-dist; Fri, 27 Jul 2001 10:34:21 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6RHYIY15117 for ; Fri, 27 Jul 2001 10:34:18 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id KAA14064 for ; Fri, 27 Jul 2001 10:34:33 -0700 (PDT) Message-Id: <200107271734.KAA14064@heliopolis.eng.sun.com> Date: Fri, 27 Jul 2001 10:34:30 -0700 (PDT) From: James Kempf Subject: RE: [mobile-ip] Handover Smoothing - What to Do? To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: mFLDGDUC7qgVekeFugj7xA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 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: Hesham, I like Pat's solution; - Mention that smoothing MAY be required, depending on implementation and deployment considerations. - Mention that there are two proposed techniques, neither of which is yet well enough understood to make a recommendation. - Mention that work is underway to understand the techniques and leave it at that. Then continue working on bicasting and buffering, including implementation and design, until they are well enough understood to advance a smoothing draft (and I think there should be only one smoothing draft) to last call. jak >From: "Hesham Soliman (ERA)" >To: "'mobile-ip@sunroof.eng.sun.com'" >Subject: RE: [mobile-ip] Handover Smoothing - What to Do? >Date: Fri, 27 Jul 2001 13:11:23 +0200 > >James, Rajeev and all, > >IMHO there is absolutely no gain or benefit in discussing whether >smoothing should be in draft X or Y. The question was do we want >the bicasting technique or not ? putting it in the right draft is >something secodary that will not add value to this discussion. > >It seems like some people are saying we don't care as long as you >keep it out of this draft !! what's the point of this argument ? >Putting it as MAY (as it is in the MIPv4 draft) will have the same >effect. > >Hesham > > From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 27 13:42:14 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12079 for ; Fri, 27 Jul 2001 13:42: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 LAA22718; Fri, 27 Jul 2001 11:40: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 KAA14582; Fri, 27 Jul 2001 10:40:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6RHd0o15190 for mobile-ip-dist; Fri, 27 Jul 2001 10:39:00 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6RHcuY15182 for ; Fri, 27 Jul 2001 10:38:56 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id KAA14361 for ; Fri, 27 Jul 2001 10:39:11 -0700 (PDT) Message-Id: <200107271739.KAA14361@heliopolis.eng.sun.com> Date: Fri, 27 Jul 2001 10:39:09 -0700 (PDT) From: James Kempf Subject: Re: [mobile-ip] Handover Smoothing - What to Do? To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: csT7r0eU8z/xgl+cjv3pnQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 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: > >Perhaps I am missing something (or did a poor job of explaining what I had in >mind).. However, in your above illustration, during T(1) when you are downloading, >what if there is nothing to buffer ? > > Sure, but you can't design a network based on the premise that sometimes there won't be anything to buffer. What happens if there is? I think both smoothing techniques have a lot of problems and need lots more study. jak From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 27 13:50:06 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12880 for ; Fri, 27 Jul 2001 13:50:05 -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 KAA11167; Fri, 27 Jul 2001 10:50:18 -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 KAA14603; Fri, 27 Jul 2001 10:40:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6RHd4015201 for mobile-ip-dist; Fri, 27 Jul 2001 10:39:04 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6RHd0Y15191 for ; Fri, 27 Jul 2001 10:39:00 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA07889 for ; Fri, 27 Jul 2001 10:39:13 -0700 (PDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA03295 for ; Fri, 27 Jul 2001 10:39:13 -0700 (PDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f6RHdN326676 for ; Fri, 27 Jul 2001 10:39:23 -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 AAY04783; Fri, 27 Jul 2001 10:39:11 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA11446; Fri, 27 Jul 2001 10:39:11 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15201.42815.24761.107860@thomasm-u1.cisco.com> Date: Fri, 27 Jul 2001 10:39:11 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Handover Smoothing - What to Do? In-Reply-To: <200107271734.KAA14064@heliopolis.eng.sun.com> References: <200107271734.KAA14064@heliopolis.eng.sun.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 This seems eminently reasonable to me too. Mike James Kempf writes: > Hesham, > > I like Pat's solution; > > - Mention that smoothing MAY be required, depending on > implementation and deployment considerations. > > - Mention that there are two proposed techniques, neither > of which is yet well enough understood to make a recommendation. > > - Mention that work is underway to understand the techniques > and leave it at that. > > Then continue working on bicasting and buffering, including implementation > and design, until they are well enough understood to advance a > smoothing draft (and I think there should be only one smoothing > draft) to last call. > > jak > > >From: "Hesham Soliman (ERA)" > >To: "'mobile-ip@sunroof.eng.sun.com'" > >Subject: RE: [mobile-ip] Handover Smoothing - What to Do? > >Date: Fri, 27 Jul 2001 13:11:23 +0200 > > > >James, Rajeev and all, > > > >IMHO there is absolutely no gain or benefit in discussing whether > >smoothing should be in draft X or Y. The question was do we want > >the bicasting technique or not ? putting it in the right draft is > >something secodary that will not add value to this discussion. > > > >It seems like some people are saying we don't care as long as you > >keep it out of this draft !! what's the point of this argument ? > >Putting it as MAY (as it is in the MIPv4 draft) will have the same > >effect. > > > >Hesham > > > > > From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 27 14:20:08 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15873 for ; Fri, 27 Jul 2001 14:20:07 -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 MAA23938; Fri, 27 Jul 2001 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 LAA13440; Fri, 27 Jul 2001 11:20:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6RIJAO15466 for mobile-ip-dist; Fri, 27 Jul 2001 11:19:10 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6RIJ7Y15459 for ; Fri, 27 Jul 2001 11:19:07 -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 LAA13179 for ; Fri, 27 Jul 2001 11:19:19 -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 MAA23123 for ; Fri, 27 Jul 2001 12:19:17 -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 LAA15203 for ; Fri, 27 Jul 2001 11:19:18 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6RIJIl21213 for ; Fri, 27 Jul 2001 11:19:18 -0700 X-mProtect: Fri, 27 Jul 2001 11:19:18 -0700 Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdEEUaCN; Fri, 27 Jul 2001 11:19:16 PDT Message-ID: <3B61B0A4.27C36D52@iprg.nokia.com> Date: Fri, 27 Jul 2001 11:19: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: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Handover Smoothing - What to Do? References: <200107271739.KAA14361@heliopolis.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 James Kempf wrote: > > > >Perhaps I am missing something (or did a poor job of explaining what I had in > >mind).. However, in your above illustration, during T(1) when you are > downloading, > >what if there is nothing to buffer ? > > > > > > Sure, but you can't design a network based on the premise that > sometimes there won't be anything to buffer. What happens if there > is? > Well, if you design it assuming that there will always be something to buffer, you have a worst-case bound, which in a statistically multiplexed network (such as an IP network), is an overkill. I brought up the case of talkspurt and idle periods to elucidate this. The network dynamics, i.e., how the queuing in a tandem network affects the inter-packet separation, clearly plays into this. Given the complexity, what folks typically do is to size up client buffers based on what is tolerable for each application. For instance, real-time voice has fewer buffers compared to streaming. This is bit of an art, not exact science. > > I think both smoothing techniques have a lot of problems and need > lots more study. > Sure. Until then, let's work towards moving FMIP forward! Regards, -Rajeev > > jak From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 27 14:30:47 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA17162 for ; Fri, 27 Jul 2001 14:30:46 -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 MAA01992; Fri, 27 Jul 2001 12:31: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 LAA16729; Fri, 27 Jul 2001 11:30:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6RITCN15563 for mobile-ip-dist; Fri, 27 Jul 2001 11:29:12 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6RIT8Y15556 for ; Fri, 27 Jul 2001 11:29:08 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA16217 for ; Fri, 27 Jul 2001 11:29:21 -0700 (PDT) Received: from mail.verizonwireless.com ([199.74.158.61]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA14119 for ; Fri, 27 Jul 2001 11:29:20 -0700 (PDT) Received: from mail.verizonwireless.com by mail.verizonwireless.com (414/1100) with ESMTP id f6RIIOk01059 for ; Fri, 27 Jul 2001 14:18:25 -0400 (EDT) Received: by hqbedigwy2.corp.bam.com with Internet Mail Service (5.5.2653.19) id ; Fri, 27 Jul 2001 14:27:12 -0400 Message-ID: <43E8CCEAF148D211854C00805FA72E5808318F2A@rhqnneex1.corp.bam.com> From: "Carroll, Christopher X" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] I-D ACTION:draft-ietf-mobileip-aaa-key-08.txt Date: Fri, 27 Jul 2001 14:29: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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Pat, Thanks. I agree that an authenticated message between the AAAh to the HA is an acceptable alternative to the MN-HA Auth. Ext. from a security perspective. chris -----Original Message----- From: Pat Calhoun [mailto:pcalhoun@diameter.org] Sent: Friday, July 27, 2001 12:27 PM To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] I-D ACTION:draft-ietf-mobileip-aaa-key-08.txt Christopher, I think you missed my original point. In the Diameter model, the absence of the MN-HA is acceptable because there is inherent trust between the AAAH and the HA. So, if the mobile is authenticated on the AAAH, and an authenticated message is sent from the AAAH to the HA, then the HA will use that as a replacement to the MN-HA. The issue is how 3GPP2 decided to make use of RADIUS. They didn't have alot of choices due to the protocol's inability for servers to send unsolicited messages to clients (but I believe this has been added anyways since then). So, this is really a RADIUS deficiency, and I see no reason for Mobile IP to design a secure network for 3GPP2, when the RADIUS (the IETF version, not w/ 3GPP2's extensions) cannot provide that. PatC On Fri, Jul 27, 2001 at 12:20:48PM -0400, Carroll, Christopher X wrote: > Hi Pat and Junhyuk, > > Just a few comments regarding Junhyuk's observations: > > The MN-FA key need not be used for MIP registration authentication only. > The MN-FA key is a security association which can be used to enable other > security services such as message encryption or authentication between the > MN and FA. > > Junhyuk raises an interesting question that I alluded to in earlier e-mails: > "Does the MN always possess only one MN-HA key or can it possess a series of > MN-HA keys, one associated with each HA that it interfaces with?" Stated > differently, "Does the AAA potentially pass the same MN-HA key to each HA > when the MN is dynamically assigned a new HAs?" Finally, "Should the AAAh > generate a new MN-HA key for each dynamic HA assignment?" > > In 3GPP2, the MN appears to possess one MN-HA key. Thus, when the MN is > dynamically assigned to a new HA and registers, it uses the previously > generated MN-HA key (also stored in the AAAh server) to generate the > Mobile-Home Authentication Ext. When the new HA receives the RRQ and has no > MN-HA key, it requests the MN-HA key from the AAAh and then checks the > Mobile-Home Auth. Ext. > > Therefore, Junhyuk's comment that the HA must accept the initial > registration without checking the MN-HA Auth. Ext. is not completely > accurate in the 3GPP2 environment. His scenario only applies to the > situation (within 3GPP2) in which the MN has no MN-HA key (when the MN is > initially provisioned). Note: this may never occur where a service provider > bootstraps the MN-HA key (using an out-of-band method) during initial > provisioning. If the MN and HA have different MN-HA keys, the MN-HA key > update process is inefficient, but should rarely occur. Verizon Wireless > will never allow the HA to accept an RRQ that is not authenticated. > > Is it acceptable to allow the AAAh to pass the MN-HA key to a new HA? Yes, > at least in the 3GPP2 environment where the network service provider will > control and trust all of the HAs. It is extremely unlikely (at least until > Diameter is available) that Verizon Wireless would allow HAs under a private > company or individual's control. In the 3GPP2 environment, it is likely > unnecessary to update the MN-HA key for every new HA assignment. > > From one perspective, the purpose of the MN-HA key, derived from the MN-AAA > key using a one-way function, is to protect the root MN-AAA key. If, as > Junhyuk proposes, the MN-AAA auth. Ext. is passed to the HA, the HA must > check the extension using the MN-AAA key - not a good idea. The MN-AAA key > is the root secret for the system and must reside in one, well-protected > location - the AAA server (also in the MN). I realize that RADIUS AAA is an > add-on to the original MIPv4 and is somewhat inefficient. However, I would > rather protect the MN-AAA key and allow the AAAh to pass a modifiable MN-HA > key to a new HA. If the MN-HA key is compromised, the AAAh can update it. > If the MN-AAA key is compromised, then the service provider must distribute > a new MN-AAA key to potentially millions of MNs. > > As an alternative to using the Foreign-Home Auth. Ext., 3GPP2 service > providers will use IPsec between the PDSN/FA and the HA. I don't beleive it > is necessary to mandate HA-FA authentication especially since other > alternatives exist to protect that link. > > regards, > > chris > > > > On Fri, Jul 27, 2001 at 09:07:20PM +0900, junhyuk song wrote: > > Hi Pat, > > > > I don't see the need for MN-FA shared key while using FAC and MN-AAA > authentication. > > The AAAH will verify Mobile Node for Foreign Agent with MN-AAA > authenticatiion defined in RFC3012. It seems to me using MN-FA Auth and FAC > with MN-AAA Auth together is somewhat redundant. > > It isn't redundant since the AAA and the FA may be owned by separate > administrative domains. Having said that, no where in the draft does it > state that the MN-FA is to be present if the MN-AAA is present. > > > Besides, I wish you made separate section for RADIUS consideration in your > draft. > > why? This draft discusses how the keys are sent to the mobile node, not > to a RADIUS and/or Diameter device. > > The AAA software used is completely irrelevant to this draft (unless I > missed > something). > > > > Further more the RADIUS based AAA case must be noted for DOS attack > consideration, because HA will blindly procede Mobile IP signalling and AAA > message without MN-HA authentication for the initial RRQ. Another approach > is clearly defining MN-AAA authentication from HA before AAAH procede to > generate "Key Material" and "Mn-HA shared key". > > Right, and this was one of the reasons why we decided to allow the FA to > forward the messages to the AAA infrastructure in Diameter. 3GPP2 decided > to let the HA to the work, and that is simply the wrong approach, and will > lead to DoS attacks. I've brought this up numerous times, and the real fix > is to change how 3GPP2 handles AAA (not necessarily the protocol, but rather > the way it uses RADIUS). > > > It also may be helpful to mandate HA-FA authentication between FA and HA. > > If keys are generated, yes, but this is not covered by this draft. It seems > like what you are requesting is really in the Diameter Mobile IP > application, > and not in this one. > > PatC From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 27 15:04:11 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA20457 for ; Fri, 27 Jul 2001 15:04:10 -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 NAA25677; Fri, 27 Jul 2001 13:04: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 MAA24074; Fri, 27 Jul 2001 12:04:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6RJ3Am15864 for mobile-ip-dist; Fri, 27 Jul 2001 12:03:10 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6RJ36Y15857 for ; Fri, 27 Jul 2001 12:03:06 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA23842 for ; Fri, 27 Jul 2001 12:03:19 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA11458 for ; Fri, 27 Jul 2001 12:03:19 -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 MAA19799 for ; Fri, 27 Jul 2001 12:03:19 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6RJ3It01873 for ; Fri, 27 Jul 2001 12:03:18 -0700 X-mProtect: Fri, 27 Jul 2001 12:03:18 -0700 Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdWcQjGh; Fri, 27 Jul 2001 12:03:16 PDT Message-ID: <3B61BAF4.29B2932A@iprg.nokia.com> Date: Fri, 27 Jul 2001 12:03: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: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Handover Smoothing - What to Do? References: <034BEFD03799D411A59F00508BDF754603008B64@esealnt448.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: > There are so many mails I hope no one else made the same > comments that I'm about to make. > > > I don't understand your viewpoint. Just because you have not heard from > > buffering advocates does not imply that the alternative is the way to go. There > > are at least two things to consider. First, you are proposing to add a > > particular smoothing technique to FMIPv6. I am registering my complaint saying > > that it is not the right thing to do. > > > => You're making a statement that is not backed by a reason. See more below. > > On the contrary, I was reasoning that when FMIP can progress without having to rely on any particular smoothing technique. > > FMIPv6 must be able to work independently > > of bicasting. > > > => Why ? > > Why not ? FMIP can work without any dependency. Besides, the smoothing techniques by themselves are not well-understood to be part of a standard. I mentioned this (in the same thread somewhere) didn't I ? > > I have provided the problems stemming from header compression as > > an example to illustrate the added complexity. > > > => Context transfer for HC is extrermely complex in itself and controversial. > Yet if you want it, I don't see how bicasting can make it worse. In fact > with bicasting you can establish the down link context earlier since > the process happens before the MN attaches to the nAR. Either way, > why are we discussing CT and HC again ? Haven't we already agreed > that this is out of scope for the MIP WG. > It is not as simple as you seem to imply, or else I would like you to educate me. The context at old-AR and new-AR is not the same if you do this, and special actions are needed to handle the complexity. The additional complexity must not be coupled to FMIP. > > > Second, taking up smoothing as a > > topic by itself, it is not a foregone conclusion that bicasting/simultaneous > > binding are the only means. This is an open area and we need discussion and > > *real experimental* evidence. Also, the header compression example hold here as > > well. > > > => Well other proposals are also welcome. But I'm sure you can appreciate > that new ideas come up all the time, that doesn't mean we don't make > any decisions. We have to decide on what we have now. Unless you've > done some experiments on bicasting and saw that it's bad for some > reason. > We are now talking about handling smoothing techniques on their own. As I mentioned above, this topic by itself needs a lot of discussion before we can make decisions. I am not convinced that we can draw definitive conclusions on smoothing techniques to progress them on a standardization path. Regards, -Rajeev > > Hesham > > > > >George has also asserted (and speaking for myself personally I also agree > > > >with) > > > >that implementations in some environments at least can solve this without > > > >any kind > > > >of protocol support at layer 3. > > > > > > > > > > I agree also. > > > > > > >Does this seem to summarize everyone's position accurately? Does this > > > >answer your question > > > >enough, Jim? > > > > > > > > > > Yes, thanx. > > > > > > >Of course, others contributing to the conversation COULD help, > > > > > > Agree. > > > > > > jak From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 27 15:42:55 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24551 for ; Fri, 27 Jul 2001 15:42: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 MAA06033; Fri, 27 Jul 2001 12:43: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 MAA13818; Fri, 27 Jul 2001 12:40:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6RJYt515993 for mobile-ip-dist; Fri, 27 Jul 2001 12:34:55 -0700 (PDT) Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6RJYqY15986 for ; Fri, 27 Jul 2001 12:34:52 -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 PAA20497 for ; Fri, 27 Jul 2001 15:35:04 -0400 (EDT) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id PAA22682 for mobile-ip@sunroof.eng.sun.com; Fri, 27 Jul 2001 15:35:29 -0400 (EDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6RIsjY15845 for ; Fri, 27 Jul 2001 11:54:46 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA22137 for ; Fri, 27 Jul 2001 11:54:58 -0700 (PDT) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA08125 for ; Fri, 27 Jul 2001 11:54:57 -0700 (PDT) Received: by megisto-sql1.megisto.com with Internet Mail Service (5.5.2650.21) id ; Fri, 27 Jul 2001 14:54:49 -0400 Message-ID: From: Phil Roberts To: "'sommerfeld@east.sun.com'" , mobile-ip@sunroof.eng.sun.com Cc: Alexis , Phil Roberts , "Basavaraj Patil (NTC/Dallas)" , Abha Ahuja , Thomas Narten , Dave Johnson , Jeff Schiller , Marcus Leech , Pekka Nikander Subject: RE: [Fwd: [mobile-ip] Mobile IPv6 clarifications] Date: Fri, 27 Jul 2001 14:54:49 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) 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: Hi Bill, I appreciate your comments and welcome your involvement. But I'd like to repeat that we've been saying it's premature to determine specific changes to make to the protocol. We've just published a security requirements draft which we're still waiting for significant feedback on. Until we have some sense of what needs to stay there and what is superfluous it's hard to make a determination about what needs to be done. It's probably not unfair to say that a lot of work has been done on this protocol and a lot of design decisions have been around for some time. There is plenty of sweat shed in implementation. That is not to say that if something doesn't work it won't be fixed, it has to, but it is to say that people would prefer to do so without significant changes. Phil > -----Original Message----- > From: Bill Sommerfeld [mailto:sommerfeld@east.sun.com] > Sent: Wednesday, July 25, 2001 3:36 PM > To: mobile-ip@sunroof.eng.sun.com > Cc: Alexis; Phil Roberts; Basavaraj Patil (NTC/Dallas); Abha Ahuja; > Thomas Narten; Dave Johnson; Jeff Schiller; Marcus Leech; > Pekka Nikander > Subject: Re: [Fwd: [mobile-ip] Mobile IPv6 clarifications] > > > > I think you two are actually in violent agreement, as I read Vijay's > > comment as meaning that killing piggybacking in the spec if that > > were necessary wouldn't be any huge loss. > > I didn't read his comment that way. > > Oh, by the way... > > Once you've thrown out piggybacking, why not also throw out the whole > binding-update, home-address, etc., etc, option scheme and just go to > a much simpler ipvN-in-ipvN tunneling scheme in conjunction with a > tunnel setup/update protocol? Yes, the packets get slightly bigger, > but header compression can deal with that over low bit-rate links. > > > However, your comment about mixed traffic bothers me quite a bit. > > Good, it was supposed to ;-) > > > A very ordinary mix of traffic for mobile nodes will probably be > > SRTP (secure RTP) media probably over ROHC header compression, but > > using IPsec for most other signaling. This is an extremely appealing > > combination since the high bandwidth media is heavily optimized, but > > the relatively low bandwidth signaling is fully protected. > > As always, you need someone to do a security analysis of the > proposed combination before you can say with any confidence that a > particular combination looks secure. > > You have to look for weaknesses not only in the protocols themselves, > but also in exactly how they're stapled together. As a good example > of a flaw of this form, early versions of the GSSAPI authentication > scheme for IKE (draft-ietf-ipsec-isakmp-gss-auth-07.txt) allowed the > GSSAPI tokens to be cut & pasted between IKE sessions, allowing for a > man-in-the-middle attack. > > Note that I'm not volunteering to do the analysis for this protocol.. > > - Bill > From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 27 16:00:42 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA26330 for ; Fri, 27 Jul 2001 16:00:41 -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 NAA14541; Fri, 27 Jul 2001 13:01: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 NAA21482; Fri, 27 Jul 2001 13:00:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6RJx9Y16147 for mobile-ip-dist; Fri, 27 Jul 2001 12:59:09 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6RJx5Y16140 for ; Fri, 27 Jul 2001 12:59:05 -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 MAA10034 for ; Fri, 27 Jul 2001 12:59:18 -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 NAA29654 for ; Fri, 27 Jul 2001 13:59:11 -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 MAA24652 for ; Fri, 27 Jul 2001 12:59:12 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6RJxC422171 for ; Fri, 27 Jul 2001 12:59:12 -0700 X-mProtect: Fri, 27 Jul 2001 12:59:12 -0700 Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdvDBWBx; Fri, 27 Jul 2001 12:59:10 PDT Message-ID: <3B61C80D.4DA456B0@iprg.nokia.com> Date: Fri, 27 Jul 2001 12:59:09 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Mobile IP Working Group Subject: [mobile-ip] Concern over draft-team-mobileip-mipv6-sec-reqts-00.txt 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, It seems to me that an engineer, unfamiliar with Mobile IPv6, would form some very bad impressions after reading this draft. This is because it is declared several times in the draft that mobility opens security vulnerabilities when home agents and correspondent nodes accept Binding Updates without any authentication. However, the Mobile IPv6 specification does not in any way permit such behavior, and thus DOES NOT open the declared vulnerability. One can understand that the document needs to list all the possible threats that are important to understand, and the acceptance of unauthenticated remote redirects is certainly an error that needs to be prevented. However, the document COULD be misinterpreted to mean that the stated vulnerability is a current problem with Mobile IPv6. I would earnestly request that every such instance within the Requirements document should be repaired to make it clear that the threat has been countered within the Mobile IPv6 specification. More generally, I would suggest that every scenario should have an additional "STATUS" subtopic heading. That is, for each of the scenarios, the current status of the threat should be listed. So, for instance, each of the remote redirect scenarios (in addition to being reworded) could contain the following paragraph: STATUS: prevented within Mobile IPv6 by the requirement that all Binding Updates MUST be validated using the unforgeable Authentication Data provided along with the Binding Update. That is my major comment. In addition, I have the following issues, in varying degrees of importance. 1) All scenario subtopics should occur in the same order: - Scenario description - Threat - Result - Requirement - Status (I sneaked the new one in here...) 2) The table in section 6 should cross reference the relevant sections 3) On page 11, second paragraph of Effect B.3, the words "ownership of the home address" should be "... care-of address", right? 4) The document seems to be missing all the page feed characters. 5) The second paragraph of Requirement E.1 seems to be trying to outline threats that might exist if someone tried to create a new challenge-based protocol. This is not a scenario inherent to Mobile IPv6, nor to mobility in general I don't think. 6) Masquerade is misspelled. 7) In the first sentence of section 6.6, the words "the link" should be "a link", correct? 8) The requirement generated from section B.3 (on page 21) is really a requirement for address autoconfiguration, not a mobility problem. 9) The problem described for the Home Agent discovery mechanism is actually a problem for ALL anycast messages that are served by routers. Furthermore, it's not always a problem! For many domains, perhaps the network administrator would not care. We should allow network administrators not to care if they would not otherwise care. Thus, the requirement H.1 on page 21 should be a SHOULD not a MUST. 10) In section 7.1, the concept of Identity Authentication is introduced, but (unless I missed it) not explained earlier. Furthermore, it's not shown earlier why it is _always_ needed -- and, in fact, I don't think it is always needed. Maybe the whole requirement C in section 7.1 should be deleted. 11) In Result H.1, on page 18, the last sentence should actually be the start of the next scenario. 12) On page 2, section 2, the first "off" should be "from". 13) In section 3, it is plainly stated that MIPv6 "introduces" a threat from bogus redirection. This is wrong, as I explained above. 14) In section 5, first bullet, "gainst" should be "against". 15) Every occurences of "it's" should be "its". I checked. 16) On page 18, there are two occurrences of "Threat H.2". I think the second one should be "Result H.2". 17) Perhaps [Ref1] should be updated to cite revision 14? Thanks for your consideration of these suggestions. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 27 16:13:10 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA28069 for ; Fri, 27 Jul 2001 16:13:09 -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 NAA20173; Fri, 27 Jul 2001 13:13:39 -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 NAA24097; Fri, 27 Jul 2001 13:13:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6RKC6u16240 for mobile-ip-dist; Fri, 27 Jul 2001 13:12:06 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6RKC2Y16233 for ; Fri, 27 Jul 2001 13:12:02 -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 NAA09378 for ; Fri, 27 Jul 2001 13:12:06 -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 OAA07322 for ; Fri, 27 Jul 2001 14:12:04 -0600 (MDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f6RKCE309039 for ; Fri, 27 Jul 2001 13:12:14 -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 AAY09051; Fri, 27 Jul 2001 13:12:02 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA11455; Fri, 27 Jul 2001 13:12:02 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15201.51986.555615.673177@thomasm-u1.cisco.com> Date: Fri, 27 Jul 2001 13:12:02 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Concern over draft-team-mobileip-mipv6-sec-reqts-00.txt In-Reply-To: <3B61C80D.4DA456B0@iprg.nokia.com> References: <3B61C80D.4DA456B0@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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit I don't get it. The current -14 draft does not contain a complete specification, nor does what little is in there have consensus. As such, somebody interpreting the spec as incomplete and vulnerable would be correct. Rather than shooting the messenger, maybe we should ignore tender sensibilities and get down to the job of getting consensus on what's broken, and the choose an approach to fix it in the mipv6 spec. Mike Charles E. Perkins writes: > Hello folks, > > It seems to me that an engineer, unfamiliar with Mobile IPv6, would > form some very bad impressions after reading this draft. > > This is because it is declared several times in the draft that mobility > opens security vulnerabilities when home agents and correspondent > nodes accept Binding Updates without any authentication. > > However, the Mobile IPv6 specification does not in any way permit > such behavior, and thus DOES NOT open the declared vulnerability. > > One can understand that the document needs to list all the possible > threats that are important to understand, and the acceptance of > unauthenticated remote redirects is certainly an error that needs > to be prevented. However, the document COULD be misinterpreted to > mean that the stated vulnerability is a current problem with > Mobile IPv6. I would earnestly request that every such instance > within the Requirements document should be repaired to make it > clear that the threat has been countered within the Mobile IPv6 > specification. > > More generally, I would suggest that every scenario should have > an additional "STATUS" subtopic heading. That is, for each of > the scenarios, the current status of the threat should be listed. > So, for instance, each of the remote redirect scenarios (in addition > to being reworded) could contain the following paragraph: > > STATUS: prevented within Mobile IPv6 by the requirement that > all Binding Updates MUST be validated using the > unforgeable Authentication Data provided along with > the Binding Update. > > That is my major comment. In addition, I have the following > issues, in varying degrees of importance. > > 1) All scenario subtopics should occur in the same order: > - Scenario description > - Threat > - Result > - Requirement > - Status (I sneaked the new one in here...) > > 2) The table in section 6 should cross reference the relevant sections > > 3) On page 11, second paragraph of Effect B.3, the words > "ownership of the home address" should be "... care-of address", > right? > > 4) The document seems to be missing all the page feed characters. > > 5) The second paragraph of Requirement E.1 seems to be trying to > outline threats that might exist if someone tried to create a > new challenge-based protocol. This is not a scenario inherent > to Mobile IPv6, nor to mobility in general I don't think. > > 6) Masquerade is misspelled. > > 7) In the first sentence of section 6.6, the words "the link" should > be "a link", correct? > > 8) The requirement generated from section B.3 (on page 21) is > really a requirement for address autoconfiguration, not a mobility > problem. > > 9) The problem described for the Home Agent discovery mechanism is > actually a problem for ALL anycast messages that are served by > routers. Furthermore, it's not always a problem! For many domains, > perhaps the network administrator would not care. We should allow > network administrators not to care if they would not otherwise care. > Thus, the requirement H.1 on page 21 should be a SHOULD not a MUST. > > 10) In section 7.1, the concept of Identity Authentication is introduced, > but (unless I missed it) not explained earlier. Furthermore, it's > not shown earlier why it is _always_ needed -- and, in fact, I don't > think it is always needed. Maybe the whole requirement C in > section 7.1 should be deleted. > > 11) In Result H.1, on page 18, the last sentence should actually be > the start of the next scenario. > > 12) On page 2, section 2, the first "off" should be "from". > > 13) In section 3, it is plainly stated that MIPv6 "introduces" a > threat from bogus redirection. This is wrong, as I explained > above. > > 14) In section 5, first bullet, "gainst" should be "against". > > 15) Every occurences of "it's" should be "its". I checked. > > 16) On page 18, there are two occurrences of "Threat H.2". I think > the second one should be "Result H.2". > > 17) Perhaps [Ref1] should be updated to cite revision 14? > > > > Thanks for your consideration of these suggestions. > > Regards, > Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 27 16:51:53 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA02385 for ; Fri, 27 Jul 2001 16:51:51 -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 NAA07858; Fri, 27 Jul 2001 13:52:17 -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 NAA02332; Fri, 27 Jul 2001 13:49:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6RKmbG16395 for mobile-ip-dist; Fri, 27 Jul 2001 13:48:37 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6RKmXY16388 for ; Fri, 27 Jul 2001 13:48:33 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA17285 for ; Fri, 27 Jul 2001 13:48:47 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA13372 for ; Fri, 27 Jul 2001 13:48:45 -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 NAA29217; Fri, 27 Jul 2001 13:48:03 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6RKm2K27387; Fri, 27 Jul 2001 13:48:02 -0700 X-mProtect: Fri, 27 Jul 2001 13:48:02 -0700 Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpd1qBQ58; Fri, 27 Jul 2001 13:47:58 PDT Message-ID: <3B61D37F.A75CF9B4@iprg.nokia.com> Date: Fri, 27 Jul 2001 13:47:59 -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 Working Group , Pat Calhoun Subject: Re: [mobile-ip] Re: mobile-ip] WG last call: draft-ietf-mobileip-gen-key-00.txt References: <20010718115752.A689@cisco.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, I submitted a version of the genkey draft, but I turned off my laptop before the mail had gone out and so I missed last week's deadline. It turns out that I had forgotten to cite RFC 2119 anyway, and so it might have been rejected by the IESG. I have re-revised the draft, and I will resubmit it at the next opportunity. The new draft is available at: http://people.nokia.net/charliep/txt/genkey/genkey.txt Here are some additional comments. "Madhavi W. Chandra" wrote: > > Hi Charlie and Pat, > > We've just started following this draft and are trying to grasp its > intent. We have a few questions/comments: > > 1. Since it is not specified, can the 'Reply' Key extensions be > appended to both RPYs and RRQs? As Pat noted, there should be restrictions. I have added text to that effect near the end of the Introduction. > 2. Section 7, 'FA-FA Key Reply Subtype Data' sounds like a > description for MN-HA Reply. Fixed. > 7. We would like a mobility agent, say MA-1, to pass key to MA-2 for > MA-2 to use with MN. If MAs are FAs, then probably the FA-FA Key > Reply Extension would be used...appended to what MIP message? What if > the MAs are HAs? I agree with Pat's comments about hierarchical FAs being the motivation for this extension, which seems to belong here. For the case of home agents, no one ever made such a request, and I haven't seen any protocol that would use such a thing as part of any Mobile IPv4 registration message. Even though it's a bit late, it's not completely impossible to add such a feature. However, I reckon the burden of proof would be on you to make the case. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 27 17:01:29 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA03339 for ; Fri, 27 Jul 2001 17:01: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 PAA09947; Fri, 27 Jul 2001 15:01: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 OAA04941; Fri, 27 Jul 2001 14:01:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6RL0Yn16499 for mobile-ip-dist; Fri, 27 Jul 2001 14:00:34 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6RL0UY16492 for ; Fri, 27 Jul 2001 14:00:30 -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 OAA04799 for ; Fri, 27 Jul 2001 14:00:45 -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 PAA03518 for ; Fri, 27 Jul 2001 15:02: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 OAA00489; Fri, 27 Jul 2001 14:00:42 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6RL0gC01090; Fri, 27 Jul 2001 14:00:42 -0700 X-mProtect: Fri, 27 Jul 2001 14:00:42 -0700 Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdcaFM7c; Fri, 27 Jul 2001 14:00:40 PDT Message-ID: <3B61D678.CA0C67AB@iprg.nokia.com> Date: Fri, 27 Jul 2001 14:00:40 -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: Michael Thomas CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Concern over draft-team-mobileip-mipv6-sec-reqts-00.txt References: <3B61C80D.4DA456B0@iprg.nokia.com> <15201.51986.555615.673177@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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Michael Thomas wrote: > I don't get it. The current -14 draft does not > contain a complete specification, nor does what > little is in there have consensus. What incompleteness are you referring to? I think it is complete except that it cites a working group document on key establishment that does not exist. I thought it was far better to send out the document for further comment rather than wait for the finalization of the key establishment draft, which is likely to take a while. Furthermore, varying parts of the draft have varying degrees of consensus. Perhaps you were thinking of some particular part of the draft for your comment. Could you be more specific? We need to have as much discussion as possible on it so that we can generate ideas for making sure it satisfies the requirements. > As such, > somebody interpreting the spec as incomplete and > vulnerable would be correct. Rather than shooting > the messenger, maybe we should ignore tender > sensibilities and get down to the job of getting > consensus on what's broken, and the choose an > approach to fix it in the mipv6 spec. You must be reading a different specification than I was. Perhaps you had something uncomplimentary in mind when you referred to tender sensibilities. If so, obviously whoever the target was probably wouldn't derive as much benefit as might be possible from the rest of your good ideas. I'd be curious to find out whether you have any comments on my suggestions on how to improve the requirements draft. I didn't see anything useful in your message in response to my comments. When it comes to getting down to the job, I have been doing my best to do exactly that for a long time. Thus, I _have_ made my best judgment on how to respond to many comments made during discussions about Mobile IPv6. See the "Changes" section for details. If you have some suggestions on how I can be more effective for the task of incorporating the changes needed as a result of working group discussion, please let me know either on the list or in private e-mail. Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 27 17:19:13 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA04965 for ; Fri, 27 Jul 2001 17:19:12 -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 PAA21402; Fri, 27 Jul 2001 15:19:47 -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 OAA08798; Fri, 27 Jul 2001 14:19:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6RLIEv16579 for mobile-ip-dist; Fri, 27 Jul 2001 14:18:14 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6RLIBY16572 for ; Fri, 27 Jul 2001 14:18:11 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id OAA25125 for ; Fri, 27 Jul 2001 14:18:26 -0700 (PDT) Message-Id: <200107272118.OAA25125@heliopolis.eng.sun.com> Date: Fri, 27 Jul 2001 14:18:23 -0700 (PDT) From: James Kempf Subject: [mobile-ip] Analysis of Latency Propagation with Buffering To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=US-ASCII Content-MD5: PT7SQ0RdRFhVZfq1nzJnAw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by sunroof.eng.sun.com id f6RLIBY16573 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 Most of the criticisms over the past few days have focussed on bicasting. In the interests of equal time, this note is focussed on problems with buffering. I've exchanged email with people a couple on this, and it is discussed in detail in draft-kempf-beth-ipv6-00.txt. Apologies for reposting it here, but nobody seems to be initiating a note about problems with buffering. The point of this note is that *both* smoothing techniques will require more work until they are ready for prime time. The model for the analysis is a buffer at the AR sized to buffer incoming traffic in the time period during handover when the MN is unable to receive real time traffic due to handover-related signalling on L2 and L3. An incoming real-time stream is assumed that delivers packets at a constant rate. The analysis is completely irrelevant for nonrealtime data, since there are no constraints on how much of a gap is tolerable before the user notices (well, there are constraints, they are just not very tight). The radio uplink is also assumed to have a constant, and relatively slow data rate. The analysis is also not relevant for WLAN-style networks with aggregate bandwidth at 10 Mbps with a few MNs in microcells. With this model, the AR buffers traffic during the handover, T(0) in the analysis, then downloads that buffer during a time interval of T(1). During the download, the AR needs to buffer again, and download during the time interval of T(2)...etc. Obviously, if the incoming data rate is equal to or larger than the uplink radio data rate, the process never converges and the AR fails to catch up. If the incoming data rate is less than the uplink rate, the AR eventually catches up, but if it takes too long the user will notice because the stream will lose its real time characteristic. It is possible to bound handover latency for a given incoming and uplink data rate with a more formal analysis. Let: A = incoming data rate of the real time stream B= outgoing data rate of the radio link T(i) = time interval of the ith buffering In these notation, T(0) is the initial latency delay incurred during handover, T(1) is the delay incurred downloading the buffered traffic from handover, etc. The initial amount of data accumulated in the buffer during handover is A*T(0). The amount of time it will take to download this data to the MN over the radio link is (A*T(0))/B. This is equivalent to T1. Continuing the process results in a series: T1 = (A*T(0))/B T2 = (A*T(1))/B = (A*((A*T(0))/B))/B = ((A/B)**2)*T(0) ... Which can be represented as: R = limit (n->infinity) sum (i = 0,n) ((A/B)**i)*T(0) The above is a simple geometric series, which converges to: R = T(0)/(1 - (A/B)) In Appendix B of the paper, I used a figure of 300 ms for an upper limit before people start noticing. Subsequently, Gary Kenward and Michael Mahalo have recommended 125 ms or even 40 ms, suggesting 300 ms to be too generous. Suppose we take 125 ms provisionally, and see what handover time would work for a 6 kbps real time stream (== A) and a 9.6 kbps radio uplink (== B). VoIP streams generally run about 6 kbps and 2.5 G systems use 9.6 kbps radio uplinks for voice, so the networking rate is about what we have now and what we would have to match to have a competitive 4G system. Calculating T(0) results in a handover bound of: T(0) < 46 ms So if the initial handover latency is less that 46 ms, the buffering latency will propagate until the user notices. There are a couple of conclusions I think one can draw from this: - Buffering won't work very well for real time data unless the initial handover latency is really tiny. You might do better by simply dropping the real time packets. - Since the analysis is irrelevent for nonrealtime data, buffering should be fine if there is no hard upper limit on the amount of propagated latency the user will tolerate. For TCP streams, for example, it will probably work better than bicasting because there is no chance of dropped or duplicated packets. - With the exception of BETH, most of the FMIPv4 and FMIPv6 handover scenerios have L2 + L3 handover latencies far in excess of this figure, suggesting that buffering won't work for them if real time data streams are the primary consideration. Comments? jak From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 27 17:56:57 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA07782 for ; Fri, 27 Jul 2001 17:56:56 -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 OAA05723; Fri, 27 Jul 2001 14:57: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 OAA03667; Fri, 27 Jul 2001 14:56:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6RLthN17065 for mobile-ip-dist; Fri, 27 Jul 2001 14:55:43 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6RLteY17058 for ; Fri, 27 Jul 2001 14:55:40 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA17720 for ; Fri, 27 Jul 2001 14:55:54 -0700 (PDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA11568 for ; Fri, 27 Jul 2001 14:55:54 -0700 (PDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f6RLu1313510; Fri, 27 Jul 2001 14:56:01 -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 AAY11924; Fri, 27 Jul 2001 14:55:50 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA11461; Fri, 27 Jul 2001 14:55:50 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15201.58214.80975.246707@thomasm-u1.cisco.com> Date: Fri, 27 Jul 2001 14:55:50 -0700 (PDT) To: "Charles E. Perkins" Cc: Michael Thomas , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Concern over draft-team-mobileip-mipv6-sec-reqts-00.txt In-Reply-To: <3B61D678.CA0C67AB@iprg.nokia.com> References: <3B61C80D.4DA456B0@iprg.nokia.com> <15201.51986.555615.673177@thomasm-u1.cisco.com> <3B61D678.CA0C67AB@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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Charles E. Perkins writes: > Michael Thomas wrote: > > > I don't get it. The current -14 draft does not > > contain a complete specification, nor does what > > little is in there have consensus. > > What incompleteness are you referring to? > I think it is complete except that it cites a > working group document on key establishment that > does not exist. I thought it was far better to > send out the document for further comment rather > than wait for the finalization of the key establishment > draft, which is likely to take a while. Even if key establishment weren't a definition of "incomplete" -- which I most assuredly do not agree with; indeed we've take a giant step backward if we can't use IKE to key SA's -- what is currently defined is a length and an unspecified value for the bits in the vector. That is not my idea of "complete". How are replays, for example, prevented? > Furthermore, varying parts of the draft have varying > degrees of consensus. Perhaps you were thinking of > some particular part of the draft for your comment. > Could you be more specific? We need to have as much > discussion as possible on it so that we can generate > ideas for making sure it satisfies the requirements. Yes. You moved the authentication data to the BU, and as far as I can tell, that was a) never discussed on the list, b) pre-supposes that IPsec is a non-starter, c) doesn't have any consensus, and d) surprised quite a few of us. I've already discussed in a number of posts why it is premature to declare IPsec dead. Thus far you have as yet to respond to any of them. > > As such, > > somebody interpreting the spec as incomplete and > > vulnerable would be correct. Rather than shooting > > the messenger, maybe we should ignore tender > > sensibilities and get down to the job of getting > > consensus on what's broken, and the choose an > > approach to fix it in the mipv6 spec. > > You must be reading a different specification than I > was. Perhaps you had something uncomplimentary in > mind when you referred to tender sensibilities. If > so, obviously whoever the target was probably wouldn't > derive as much benefit as might be possible from the > rest of your good ideas. I read both the -14 spec and the security analysis. I agree with the conclusions of the security analysis, as I assume the authors did as well. As far as I can tell, you seem to be asking anybody who agrees with that analysis to either downplay its conclusions or sweep them under the rug. If you want marketing spin, I suggest you contact your marketing department instead of asking the participants of this forum to participate in whatever your idea of damage control is. > I'd be curious to find out whether you have any comments > on my suggestions on how to improve the requirements > draft. I didn't see anything useful in your message > in response to my comments. I have already sent out my own comments on the requirements draft. There are archives if you missed them. Mike From owner-mobile-ip@sunroof.eng.sun.com Sat Jul 28 20:12:18 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA04796 for ; Sat, 28 Jul 2001 20:12:13 -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 SAA24190; Fri, 27 Jul 2001 18:36:49 -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 RAA14395; Fri, 27 Jul 2001 17:36:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6S0ZUs17980 for mobile-ip-dist; Fri, 27 Jul 2001 17:35:31 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6S0ZRY17973 for ; Fri, 27 Jul 2001 17:35:27 -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 RAA01042 for ; Fri, 27 Jul 2001 17:35:41 -0700 (PDT) Received: from mailrelay2.lge.com ([156.147.1.148]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA20965 for ; Fri, 27 Jul 2001 18:37:06 -0600 (MDT) Received: from lgekrhqmh01.lge.com (localhost [127.0.0.1]) by mailrelay2.lge.com (8.11.3/8.11.3) with ESMTP id f6S0Yt914733 for ; Sat, 28 Jul 2001 09:34:55 +0900 (KST) Received: from aeb099w ([150.150.60.99]) by lgekrhqmh01.lge.com (Lotus Domino Release 5.07a) with SMTP id 2001072809354441:248094 ; Sat, 28 Jul 2001 09:35:44 +0900 Message-ID: <008701c116fc$846f2250$633c9696@aeb099w> From: "Kim Taeyong" To: References: <476F91F7CFDBD41182E000D0B7E7E693B9ACF6@U9JM7> <3B60235F.1DE13A77@usa.alcatel.com> <000b01c1162f$6aeaa0c0$633c9696@aeb099w> <004501c116f5$d0a35c10$10e0d5a5@cychong> Subject: Re: [mobile-ip] A question about 'traceroute' Date: Sat, 28 Jul 2001 09:30:35 +0900 MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-MIMETrack: Itemize by SMTP Server on LGEKRHQMH01/LGE/LG Group(Release 5.07a |May 14, 2001) at 07/28/2001 09:35:44 AM, Serialize by Router on LGEKRHQMH01/LGE/LG Group(Release 5.07a |May 14, 2001) at 07/28/2001 09:35:45 AM, Serialize complete at 07/28/2001 09:35:45 AM Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by sunroof.eng.sun.com id f6S0ZRY17974 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 Dear Chae-yong. >> ex) >> CN send ICMP packet by incrementing TTL=1, 2, 3, ....(TTL decrease ) >> Then HA encapsulate ICMP message do not decrease TTL, and send the packet >> through the tunnel between HA and FA(TTL decrease ) >> >Some confusion. "encapsulate ICMP message do not decrease TTL" What does it mean? >Does it mean that HA does not decrease the TTL value of original packet?(ICMP echo request) >RFC2003 said that the encapsulator decrease the TTL value of inner packet. Yes. It's correct. HA encapsulate the packet with reduce TTL of inner packet. Then, encapsulated packet is sended to FA with not reducing TTL of inner packet but outer packet. fugure. Assume Initial TTL is 4 for inner, outer packet. MN -- FA --node A -- node B -- HA -- CN TTL of inner packet : 1 2 2 2 3 4 TTL of outer packet : 3 3 4 Although, there are some node between HA and FA, more than 1hop, CN knows there is no more node between HA and FA, because TTL of inner packet is decreased by 1. Tae-yong From owner-mobile-ip@sunroof.eng.sun.com Sat Jul 28 20:19:48 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA06665 for ; Sat, 28 Jul 2001 20:19:47 -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 XAA27826; Fri, 27 Jul 2001 23:32: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 XAA13061; Fri, 27 Jul 2001 23:32:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6S6VVc19662 for mobile-ip-dist; Fri, 27 Jul 2001 23:31:31 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6S6VSY19655 for ; Fri, 27 Jul 2001 23:31: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 XAA00861 for ; Fri, 27 Jul 2001 23:31:43 -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 AAA10118 for ; Sat, 28 Jul 2001 00:31: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 XAA08283; Fri, 27 Jul 2001 23:31:42 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6S6Vfa20433; Fri, 27 Jul 2001 23:31:41 -0700 X-mProtect: Fri, 27 Jul 2001 23:31:41 -0700 Nokia Silicon Valley Messaging Protection Received: from Icharliep-1.iprg.nokia.com (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdpIFHS7; Fri, 27 Jul 2001 23:31:38 PDT Message-ID: <3B625B5B.37D83B7D@iprg.nokia.com> Date: Fri, 27 Jul 2001 23:27:39 -0700 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Michael Thomas CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Concern over draft-team-mobileip-mipv6-sec-reqts-00.txt References: <3B61C80D.4DA456B0@iprg.nokia.com> <15201.51986.555615.673177@thomasm-u1.cisco.com> <3B61D678.CA0C67AB@iprg.nokia.com> <15201.58214.80975.246707@thomasm-u1.cisco.com> <3B621A1B.EECE6DAE@iprg.nokia.com> <15202.13525.495386.619084@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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > > > I didn't go back and check the archives, but during the last > > two IETFs, in various meetings including the mobileip > > working group meetings, it seemed pretty clear to me that > > we were being told that IPsec wasn't appropriate for > > authenticating Binding Updates. Given that, I didn't see > > any alternatives for how to proceed except to make the > > authentication data into one of the fields of the Binding > > Update option. > > Operative words: me, and I. I use these when I am speaking for myself and trying to counter your personal accusations. I used 'we' to describe cases where (to my understanding) the working group was being informed about something. As co-author of the specification, which was in Last Call, it is my job to try to fix problems with the specification, and since it is a working group document, I follow working group consensus when determining a solution. If something needs to be changed, let's change it. I think over the last year, and long before your involvement, I have demonstrated my willingness and ability to follow working group consensus, and respond to all the comments that have been presented. I'll happily do it again, if it is decided to use IPsec for authenticating Binding Updates. > Note that this isn't > the same as working group consensus. In fact, I > haven't heard _anybody_ say that they don't > want to IPsec for some parts of the solution > other than you, and this draft that got foisted > on the working group. Well, that was my understanding from the last working group meeting in Minneapolis, and it seems to have been shared by other people too. You are saying there is disagreement. That means the discussion isn't over. > > You seem to be dead set on discrediting this work, and > > of course I wish you could take a more constructive > > approach. You should acknowledge that I argued quite > > vociferously in various meetings and venues to retain the > > IPsec AH mechanism. You didn't voice any support for > > that effort before. Now that another approach has been > > proposed, you seem more willing to support IPsec AH. > > I don't know what to expect, but I guess it will not be > > support from you. > > I have made literally dozens of posts on this subject > and if this is your simplistic take on my view of this > matter you are either unwilling or unable to grasp > what is at issue here. I have *never* said that I > think that IPsec is inappropriate in all circumstances > and I challenge you to find where I have said so. I didn't put those words in your mouth. I just said that I don't remember you offering any support for keeping IPsec last year. That does not at all mean that I knew what your real position was. > I have said that I'd prefer ESP over AH, but again if > that leads you to believe that I don't support use > of IPsec in some situations, then you are clearly > not grasping the subtleties here. bzzt. > > I did send out the proposed format for Binding Update > > to a number of people for sanity checking before revising > > the draft. Then I had to leave town for almost three > > weeks. The work was done (aka getting down to work) > > to the best of my understanding of what was needed, and > > with as much input as I could gather in the time available. > > If consensus indicates another approach, that will be very > > fine with me. > > Yet, and there was no list consensus to do so, and this > is the result. ...? > > Plus, authenticating payloads might need a different > > algorithm than authenticating the Binding Update -- > > so separation is advisable. > > What leads you to this conclusion? If a Binding Update needs to be authenticated using algorithm X, and AH says to use algorithm Y, then there would be a problem. I don't view this as serious. > > > I read both the -14 spec and the security > > > analysis. I agree with the conclusions of the > > > security analysis, as I assume the authors > > > did as well. > > > > As should have been obvious from what I posted, > > I largely agree with the conclusions of the work > > also -- except that it gives the false impression that > > the existing Mobile IPv6 specification opens up > > a vulnerability from remote redirection which is > > false. > > That is yet to be seen, and from what I've > read, there is no reason whatsoever for them > to tone down their message. This is a very > serious issue even if it is inconvenience to > your standards track uber-alles schedule. The reqs draft says that Mobile IPv6 is vulnerable to misuse from unauthenticated Binding Updates. Mobile IPv6 says that unauthenticated Binding Updates have to be ignored. The claimed vulnerability does not exist by the rules of the the Mobile IPv6 spec. It would exist by other rules, sure. This is a very serious issue. > > > As far as I can tell, you seem > > > to be asking anybody who agrees with that > > > analysis to either downplay its conclusions > > > or sweep them under the rug. If you want > > > marketing spin, I suggest you contact your > > > marketing department instead of asking the > > > participants of this forum to participate in > > > whatever your idea of damage control is. > > > > This is totally wrong, unconstructive, and very > > annoying. I ask you to stop it right away. Your > > accusations are unfounded and cause for alarm, > > making the entire rest of your points suspect also. > > So do tell, Charlie: what *was* the purpose of > your "please tone it down" request? You are the > *only* person who has disputed their findings. My purpose was to suggest improvements to the draft. I believe that the draft is misleading insofar as it might lead one to believe that Mobile IPv6 has a problem with allowing nodes to accept unauthenticated Binding Updates. Mobile IPv6 specifies that such behavior is illegal, thus avoiding the vulnerability. I made many other positive suggestions which you don't seem interested in considering. > Also: it is rather disingenuous to argue with them > after the fact since their analysis was made on the > -13 draft. The -14 draft, until a week ago or so, was not > available to them or anybody else to comment on. > Their analysis of the -13 draft was pretty spot > on from what I can tell, and it's completely unclear > whether -14 -- which hasn't incorporated any > feedback from the working group -- is any > better. Their analysis is equally valid for drafts 13 and 14. Draft 14 is not appreciably better from the standpoint of specifying any way of establishing keys. > > > I have already sent out my own comments on the > > > requirements draft. There are archives if you > > > missed them. > > > > Did you have any comments to make on my suggestions for > > improvement? I don't see why your comment was in the > > least relevant to what I said. > > Yes: the unvarnished truth is far better than > putting some idiotic market spin on the > security problem with mipv6. It's appalling > that you'd ask the working group to soft peddle > the reality, and is insulting to those who have > spent a lot of time trying to make an honest > evaluation of the current state of affairs. One unvarnished truth is that Binding Updates have to be authenticated, and the honest evaluation is that Mobile IPv6 doesn't currently suffer from the claimed vulnerabililty. Another unvarnished truth is that we have been given the task of finding a way to set up security associations that can be used to enable verification of authentication data supplied with Binding Updates. Another unvarnished truth is that your postings to this mailing list are insulting, unconstructive, ignore or twist my words, and lately have been a waste of my time. I have never asked the working group to soft-peddle reality. I have not insulted anyone for championing IPsec (or for any other reason), and I will be just as happy one way or the other. You are wrong to suggest otherwise. Further, as much as I dislike your way of insulting me, I have not intentionally insulted you. Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Sat Jul 28 20:22:41 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA08377 for ; Sat, 28 Jul 2001 20:22:41 -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 IAA06022; Fri, 27 Jul 2001 08:06:26 -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 HAA17100; Fri, 27 Jul 2001 07:06:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6RE4KK12738 for mobile-ip-dist; Fri, 27 Jul 2001 07:04:20 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6RE4FY12721 for ; Fri, 27 Jul 2001 07:04:15 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA04559 for ; Fri, 27 Jul 2001 07:04:13 -0700 (PDT) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA27664 for ; Fri, 27 Jul 2001 07:04:05 -0700 (PDT) Received: by megisto-sql1.megisto.com with Internet Mail Service (5.5.2650.21) id ; Fri, 27 Jul 2001 10:02:59 -0400 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Handover Smoothing - What to Do? Date: Fri, 27 Jul 2001 10:02:59 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) 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: Karim El-Malki (ERA) [mailto:Karim.El-Malki@era.ericsson.se] > Sent: Friday, July 27, 2001 7:05 AM > To: 'mobile-ip@sunroof.eng.sun.com' > Subject: RE: [mobile-ip] Handover Smoothing - What to Do? > > > > Well, I don't buy a lot of your response below, but > > notwithstanding that, > > Since you're expressing an opinion against this it would > be useful to know the reasons rather than just saying you > don't buy my response. This is a fair request. Will try to send out something detailed later today. > > > some documentation of how these cases are handled needs to > be made so > > it's available for scrutiny. It seems that it should discuss > > the sizes > > of these buffers and the criteria for determining when to > > forward and when > > to drop packets, and what bicasting doesn't do for you. > Perhaps some > > guidance > > on how the agents involved in the implementation distinguish > > between and > > handle different types of traffic should be included, because > > although the > > proposals > > are intended to help in the case of realtime traffic, the > > implementation > > agents > > unless otherwise informed are subject to the effects of implementing > > the protocols for all traffic? > > I'm not sure that specifying buffer sizes is something we should do, > we can just give some simple explanation of what factors the > calculation should be based on. The choice of buffering/bicasting > and that calculation should be left up to implementors who know more > about the system they're building on. We'll never solve all > the problems, > but at least we can identify the gaps and supply the tools. Regarding > identification of traffic type, this was brought up a while back. It > would need some filtering at AR/FA. There is also a proposal to move > only certain flows: > http://search.ietf.org/internet-drafts/draft-soliman-mobileip- > flow-move-00.txt > A BU could eventually identify which flows to be bicast and which > not. That could be an alternative to filtering traffic at the ARs/FAs. > > However it will be up to the implementor in the end to balance the > complexity, performance of real-time, performance of non-real time > against their applications. If someone's top priority is to get max > performance for VoIP and other traffic has lower importance then that > decision will influence the implementation. If we supply some tools > for this (and for the opposite case) it certainly helps. I had > interpreted the MAYs in low latency to be these tools, and if there > are others all the better. > > /Karim > > > > > > > > > -----Original Message----- > > > From: Karim El-Malki (ERA) [mailto:Karim.El-Malki@era.ericsson.se] > > > Sent: Thursday, July 26, 2001 10:44 AM > > > To: 'mobile-ip@sunroof.eng.sun.com' > > > Subject: RE: [mobile-ip] Handover Smoothing - What to Do? > > > > > > > > > > They are both receiving packets without any knowledge of what > > > > the other > > > > has received, or has forwarded to the MN. Might you not have > > > > a situation > > > > like this? > > > > > > I agree that there should not be the need for nFA to know what > > > oFA has transmitted. What I'm saying is that if you bicast and > > > (if needed) have an appropriate (jitter) buffer size at nFA then > > > it should be possible to avoid duplicates. More below. > > > > > > > > > > > At a single point in time the MN is no longer reachable from > > > > the oFA and is > > > > not yet reachable on the nFA. At that point in time a packet > > > > arrives at > > > > both > > > > oFA and nFA and they discard the packet. The MN attaches to > > > > the nFA but the > > > > packet is gone. (That's in case A you describe). > > > > > > I would think that this is an effect of L2 (i.e. L2 handoff time) > > > and we are mostly aiming to minimise/eliminate effects due to L3. > > > Also what I was pointing to is that a buffer is probably needed > > > if the handoff time from oFA to nFA is not negligible (your next > > > case and this case). That's why packet dropping is a MAY. So this > > > case wouldn't happen, unless of course it's not TCP and you don't > > > care about dropping some packets. In fact low latency handoffs are > > > probably most useful for real-time services (e.g. Voice on UDP) > > > in which case, if there's an period of L2 disconnection during > > > handoff, the packets should be dropped. > > > > > > > > > > > Or like this? > > > > > > > > At a single point in time a packet arrives at the oFA and is > > > > sent to the MN > > > > and > > > > at the same time arrives at the nFA and gets buffered. The > > > > MN disconnects > > > > and then reconnects at the nFA and gets a second copy of > > the packet. > > > > (That's > > > > in case B you describe). > > > > > > The buffer size should be set such that you don't get duplicates. > > > By the time MN connects to nFA, the second copy of the packet > > > should be dropped out of the FIFO queue/buffer and the next one > > > should be ready for sending to MN. Of course this calculation > > > depends on the l2 handoff characteristics and possibly the wired > > > connectivity between the bicasting point and oFA/nFA. > > > > > > > > > > > Or like this? > > > > The same packet arrives at oFA and is transmitted to the MN > > > > which then moves > > > > to the > > > > nFA and gets the same packet which was delayed on its way > > > to the nFA. > > > > > > That would again need to be handled by a jitter-smoothing > > > buffer at nFA. > > > > > > > > > > > Or like this? > > > > The MN disconnects from the oFA the packet arrives and is > > > > dropped, then the > > > > MN comes > > > > back to the oFA because of radio conditions and the packet > > > > has been lost. > > > > > > We could devise some temporary oFA buffer for this, but the L2 > > > handoff failure is pretty serious so I think that it is > > > too much to expect smooth handoffs in this case. If we can > > > maintain L3 connectivity then I think that should be good enough. > > > > > > > > > > > It seems like there is some coordination needed between the > > > > oFA and the nFA > > > > to > > > > overcome these problems, perhaps a temporary tunnel? But > > > in that case > > > > bicasting from > > > > an HA or a hierarchical FA wouldn't be adding much to it, > > > > would it. > > > > > > Well, I think that having a local central HA would help. > > > Say that oFA and nFA are at an equal distance from the GFA > > > which is the aggregation router between the two. That could > > > alleviate jitter on the fixed network, as has been already > > > mentioned by James. Also, if oFA and nFA happen to be connected > > > to each other through the GFA router, then bicasting at the > > > GFA would be more efficient. > > > > > > >At any > > > > rate > > > > one would think that issues like this need some exploration > > > > and explanation > > > > somewhere. > > > > > > OK. Up to now there has been a lot of emphasis on TCP. Although I > > > agree that it would be useful to give more detail of how bicasting > > > + buffering works with TCP, we are also not considering the > > fact that > > > a major driver for having faster handoffs at L3 was to support > > > real-time services (over UDP). I would think that the > > issues above are > > > not applicable to this case? If this is so then we should > not apply > > > these issues to bicasting/buffering in general and make that > > > clear too. > > > > > > Rgds > > > /Karim > > > > > > From owner-mobile-ip@sunroof.eng.sun.com Sat Jul 28 20:23:11 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA08727 for ; Sat, 28 Jul 2001 20:23:10 -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 VAA16394; Fri, 27 Jul 2001 21:21:29 -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 VAA06569; Fri, 27 Jul 2001 21:21:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6S4KIR19134 for mobile-ip-dist; Fri, 27 Jul 2001 21:20:18 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6S4KEY19127 for ; Fri, 27 Jul 2001 21:20:14 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA03007 for ; Fri, 27 Jul 2001 21:20:28 -0700 (PDT) Received: from ms.samsung.com ([211.45.29.136]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA18321 for ; Fri, 27 Jul 2001 21:20:27 -0700 (PDT) Received: from cychong ([127.0.0.1]) by ms.samsung.com (Netscape Messaging Server 4.15 ms Jul 11 2001 16:32:57) with SMTP id GH617L00.UXP for ; Sat, 28 Jul 2001 13:16:33 +0900 Message-ID: <001101c1171d$098b0240$10e0d5a5@cychong> From: "Chae-yong Chong" To: References: <200107271107.HAA06650@ietf.org> <04fa01c11694$b08a2960$0ee0d5a5@telecom.samsung.co.kr> <20010727065112.L13541@charizard.diameter.org> <000901c1171b$71ccfd60$10e0d5a5@cychong> Subject: Re: [mobile-ip] I-D ACTION:draft-ietf-mobileip-aaa-key-08.txt Date: Sat, 28 Jul 2001 13:23:22 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" 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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by sunroof.eng.sun.com id f6S4KFY19128 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 Oops. sorry for typo.. In the last paragraph I mean "unavoidable" not "avoidable" ----- Original Message ----- From: "Chae-yong Chong" To: Sent: Saturday, July 28, 2001 1:11 PM Subject: Re: [mobile-ip] I-D ACTION:draft-ietf-mobileip-aaa-key-08.txt > Hi PatC > Here are some comments about your message. > > ----- Original Message ----- > From: "Pat Calhoun" > To: > Cc: "Pat Calhoun" > Sent: Friday, July 27, 2001 10:51 PM > Subject: Re: [mobile-ip] I-D ACTION:draft-ietf-mobileip-aaa-key-08.txt > > > > On Fri, Jul 27, 2001 at 09:07:20PM +0900, junhyuk song wrote: > > > Hi Pat, > > > > > > I don't see the need for MN-FA shared key while using FAC and MN-AAA authentication. > > > The AAAH will verify Mobile Node for Foreign Agent with MN-AAA authenticatiion defined in RFC3012. It seems to me using MN-FA Auth and FAC with MN-AAA Auth together is somewhat redundant. > > > > It isn't redundant since the AAA and the FA may be owned by separate > > administrative domains. Having said that, no where in the draft does it > > state that the MN-FA is to be present if the MN-AAA is present. > > > > Okay, let's assume the FA and AAAF are controlled by what you called, "separate administrative domain". > But there must be a security association between FA and AAAF. > FAC extension itself does not provide any securicy. However MN-AAA extension with FAC extension provides > some level of securicy. Isn't it the purpose of RFC3012 ? RFC3012 states: > > If the Mobile Node does not have a security association with the > Foreign Agent, the Mobile Node MUST include the MN-AAA Authentication > extension as defined in section 6. > > Does that mean the MN-AAA extension provide equivalent level of securicy of MN-FA? > > > > > > > Besides, I wish you made separate section for RADIUS consideration in your draft. > > > > why? This draft discusses how the keys are sent to the mobile node, not > > to a RADIUS and/or Diameter device. > > > > The AAA software used is completely irrelevant to this draft (unless I missed > > something). > > > > > Further more the RADIUS based AAA case must be noted for DOS attack consideration, because HA will blindly procede Mobile IP signalling and AAA message without MN-HA authentication for the initial RRQ. Another approach is clearly defining MN-AAA authentication from HA before AAAH procede to generate "Key Material" and "Mn-HA shared key". > > > > Right, and this was one of the reasons why we decided to allow the FA to > > forward the messages to the AAA infrastructure in Diameter. 3GPP2 decided > > to let the HA to the work, and that is simply the wrong approach, and will > > lead to DoS attacks. I've brought this up numerous times, and the real fix > > is to change how 3GPP2 handles AAA (not necessarily the protocol, but rather > > the way it uses RADIUS). > > As you know currently Diameter is not the RFC state, so 3GPP2 should have > a way to use this draft with RADIUS. It's not the wrong approach, it is just for an avoidable > situation. You know it takes a long time for Diameter to be prevailed. That means > 3GPP2 should have a interim solution which cooperate this draft with RADIUS. > > > > > > It also may be helpful to mandate HA-FA authentication between FA and HA. > > > > If keys are generated, yes, but this is not covered by this draft. It seems > > like what you are requesting is really in the Diameter Mobile IP application, > > and not in this one. > > > > PatC > > > > Regards > Chae-yong > From owner-mobile-ip@sunroof.eng.sun.com Sat Jul 28 20:30:17 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAB09883 for ; Sat, 28 Jul 2001 20:30:16 -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 TAA06523; Fri, 27 Jul 2001 19:40: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 TAA26312; Fri, 27 Jul 2001 19:40:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6S2dOv18542 for mobile-ip-dist; Fri, 27 Jul 2001 19:39:24 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6S2dKY18535 for ; Fri, 27 Jul 2001 19:39:20 -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 TAA26213 for ; Fri, 27 Jul 2001 19:39:33 -0700 (PDT) Received: from mailrelay2.lge.com ([156.147.1.148]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA19270 for ; Fri, 27 Jul 2001 20:41:00 -0600 (MDT) Received: from lgekrhqmh01.lge.com (localhost [127.0.0.1]) by mailrelay2.lge.com (8.11.3/8.11.3) with ESMTP id f6S2cD914574 for ; Sat, 28 Jul 2001 11:38:13 +0900 (KST) Received: from aeb099w ([150.150.60.99]) by lgekrhqmh01.lge.com (Lotus Domino Release 5.07a) with SMTP id 2001072811390170:261734 ; Sat, 28 Jul 2001 11:39:01 +0900 Message-ID: <00b601c1170d$bde1f380$633c9696@aeb099w> From: "Kim Taeyong" To: References: <476F91F7CFDBD41182E000D0B7E7E693B9ACF6@U9JM7> <3B60235F.1DE13A77@usa.alcatel.com> <000b01c1162f$6aeaa0c0$633c9696@aeb099w> <004501c116f5$d0a35c10$10e0d5a5@cychong> <008701c116fc$846f2250$633c9696@aeb099w> <000601c116ff$bafc4110$10e0d5a5@cychong> Subject: Re: [mobile-ip] A question about 'traceroute' Date: Sat, 28 Jul 2001 11:33:52 +0900 MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-MIMETrack: Itemize by SMTP Server on LGEKRHQMH01/LGE/LG Group(Release 5.07a |May 14, 2001) at 07/28/2001 11:39:01 AM, Serialize by Router on LGEKRHQMH01/LGE/LG Group(Release 5.07a |May 14, 2001) at 07/28/2001 11:39:02 AM, Serialize complete at 07/28/2001 11:39:02 AM Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by sunroof.eng.sun.com id f6S2dKY18536 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 Yes. You are right. But I think, To know Intermediate nodes informaiton from HA to FA is not meaningless for security. Assume there is bad guy(?) that want to do replay attack or IP packet spoofing...etc. IF CN know whole node on tunnel, CN can prepare against a possible attack and some bad nodes. My subject is route tracing of tunnel is significant and certain way to know Intermediate nodes is needed. ----- Original Message ----- From: To: Sent: Saturday, July 28, 2001 9:53 AM Subject: Re: [mobile-ip] A question about 'traceroute' Hi. Yes, the question is that whether CN want to know the intermedia nodes in path from HA to FA where CN's packet is forwarded in tunneling. I think the MN is always on "Home Network" for CN's point. That's what Mobile IP provide to nodes. Moreover it is not possible for CN to know where MN is located without routing optimization. If so, Intermediate nodes informaiton from HA to FA is meaningless to CN. I think... Regards Chae-yong ----- Original Message ----- From: "Kim Taeyong" To: Sent: Saturday, July 28, 2001 9:30 AM Subject: Re: [mobile-ip] A question about 'traceroute' > Dear Chae-yong. > > > >> ex) > >> CN send ICMP packet by incrementing TTL=1, 2, 3, ....(TTL decrease ) > >> Then HA encapsulate ICMP message do not decrease TTL, and send the packet > >> through the tunnel between HA and FA(TTL decrease ) > >> > > >Some confusion. "encapsulate ICMP message do not decrease TTL" What does it mean? > >Does it mean that HA does not decrease the TTL value of original packet?(ICMP echo request) > > >RFC2003 said that the encapsulator decrease the TTL value of inner packet. > > Yes. It's correct. > HA encapsulate the packet with reduce TTL of inner packet. > Then, encapsulated packet is sended to FA with not reducing TTL of inner packet but outer packet. > > > fugure. > > Assume Initial TTL is 4 for inner, outer packet. > > MN -- FA --node A -- node B -- HA -- CN > TTL of inner packet : 1 2 2 2 3 4 > TTL of outer packet : 3 3 4 > > > Although, there are some node between HA and FA, more than 1hop, CN knows there is no more node between HA and FA, because TTL of inner packet is decreased by 1. > > > Tae-yong > From owner-mobile-ip@sunroof.eng.sun.com Sat Jul 28 20:30:18 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA09893 for ; Sat, 28 Jul 2001 20:30:17 -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 VAA15230; Fri, 27 Jul 2001 21:10:25 -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 VAA05769; Fri, 27 Jul 2001 21:10:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6S49AK19061 for mobile-ip-dist; Fri, 27 Jul 2001 21:09:10 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6S496Y19054 for ; Fri, 27 Jul 2001 21:09:06 -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 VAA00478 for ; Fri, 27 Jul 2001 21:09:20 -0700 (PDT) Received: from ms.samsung.com ([211.45.29.136]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA08412 for ; Fri, 27 Jul 2001 22:10:47 -0600 (MDT) Received: from cychong ([127.0.0.1]) by ms.samsung.com (Netscape Messaging Server 4.15 ms Jul 11 2001 16:32:57) with SMTP id GH60OL00.IXI for ; Sat, 28 Jul 2001 13:05:09 +0900 Message-ID: <000901c1171b$71ccfd60$10e0d5a5@cychong> From: "Chae-yong Chong" To: References: <200107271107.HAA06650@ietf.org> <04fa01c11694$b08a2960$0ee0d5a5@telecom.samsung.co.kr> <20010727065112.L13541@charizard.diameter.org> Subject: Re: [mobile-ip] I-D ACTION:draft-ietf-mobileip-aaa-key-08.txt Date: Sat, 28 Jul 2001 13:11:57 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" 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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by sunroof.eng.sun.com id f6S497Y19055 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 Hi PatC Here are some comments about your message. ----- Original Message ----- From: "Pat Calhoun" To: Cc: "Pat Calhoun" Sent: Friday, July 27, 2001 10:51 PM Subject: Re: [mobile-ip] I-D ACTION:draft-ietf-mobileip-aaa-key-08.txt > On Fri, Jul 27, 2001 at 09:07:20PM +0900, junhyuk song wrote: > > Hi Pat, > > > > I don't see the need for MN-FA shared key while using FAC and MN-AAA authentication. > > The AAAH will verify Mobile Node for Foreign Agent with MN-AAA authenticatiion defined in RFC3012. It seems to me using MN-FA Auth and FAC with MN-AAA Auth together is somewhat redundant. > > It isn't redundant since the AAA and the FA may be owned by separate > administrative domains. Having said that, no where in the draft does it > state that the MN-FA is to be present if the MN-AAA is present. > Okay, let's assume the FA and AAAF are controlled by what you called, "separate administrative domain". But there must be a security association between FA and AAAF. FAC extension itself does not provide any securicy. However MN-AAA extension with FAC extension provides some level of securicy. Isn't it the purpose of RFC3012 ? RFC3012 states: If the Mobile Node does not have a security association with the Foreign Agent, the Mobile Node MUST include the MN-AAA Authentication extension as defined in section 6. Does that mean the MN-AAA extension provide equivalent level of securicy of MN-FA? > > Besides, I wish you made separate section for RADIUS consideration in your draft. > > why? This draft discusses how the keys are sent to the mobile node, not > to a RADIUS and/or Diameter device. > > The AAA software used is completely irrelevant to this draft (unless I missed > something). > > > Further more the RADIUS based AAA case must be noted for DOS attack consideration, because HA will blindly procede Mobile IP signalling and AAA message without MN-HA authentication for the initial RRQ. Another approach is clearly defining MN-AAA authentication from HA before AAAH procede to generate "Key Material" and "Mn-HA shared key". > > Right, and this was one of the reasons why we decided to allow the FA to > forward the messages to the AAA infrastructure in Diameter. 3GPP2 decided > to let the HA to the work, and that is simply the wrong approach, and will > lead to DoS attacks. I've brought this up numerous times, and the real fix > is to change how 3GPP2 handles AAA (not necessarily the protocol, but rather > the way it uses RADIUS). As you know currently Diameter is not the RFC state, so 3GPP2 should have a way to use this draft with RADIUS. It's not the wrong approach, it is just for an avoidable situation. You know it takes a long time for Diameter to be prevailed. That means 3GPP2 should have a interim solution which cooperate this draft with RADIUS. > > > It also may be helpful to mandate HA-FA authentication between FA and HA. > > If keys are generated, yes, but this is not covered by this draft. It seems > like what you are requesting is really in the Diameter Mobile IP application, > and not in this one. > > PatC > Regards Chae-yong From owner-mobile-ip@sunroof.eng.sun.com Sat Jul 28 20:30:20 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA09906 for ; Sat, 28 Jul 2001 20:30:19 -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 UAA12847; Fri, 27 Jul 2001 20:44: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 UAA00809; Fri, 27 Jul 2001 20:44:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6S3hAc18674 for mobile-ip-dist; Fri, 27 Jul 2001 20:43:10 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6S3h7Y18667 for ; Fri, 27 Jul 2001 20:43:07 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA00732 for ; Fri, 27 Jul 2001 20:43:21 -0700 (PDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA12487 for ; Fri, 27 Jul 2001 20:43:20 -0700 (PDT) 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 f6S3fXJ27073; Fri, 27 Jul 2001 20:41:34 -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 AAZ00612; Fri, 27 Jul 2001 20:43:17 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id UAA11497; Fri, 27 Jul 2001 20:43:17 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15202.13525.495386.619084@thomasm-u1.cisco.com> Date: Fri, 27 Jul 2001 20:43:17 -0700 (PDT) To: Charlie Perkins Cc: Michael Thomas , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Concern over draft-team-mobileip-mipv6-sec-reqts-00.txt In-Reply-To: <3B621A1B.EECE6DAE@iprg.nokia.com> References: <3B61C80D.4DA456B0@iprg.nokia.com> <15201.51986.555615.673177@thomasm-u1.cisco.com> <3B61D678.CA0C67AB@iprg.nokia.com> <15201.58214.80975.246707@thomasm-u1.cisco.com> <3B621A1B.EECE6DAE@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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Charlie Perkins writes: > > Even if key establishment weren't a definition > > of "incomplete" -- which I most assuredly do > > not agree with; indeed we've take a giant step > > backward if we can't use IKE to key SA's -- > > what is currently defined is a length and an > > unspecified value for the bits in the vector. > > That is not my idea of "complete". How are > > replays, for example, prevented? > > - Replays are prevented by using different sequence > numbers. Section 13.1 discusses this briefly. What is in there is wholly insufficient and incomplete. > - Requiring IKE from every IPv6 node is too much. > However, it should be _allowed_ for nodes that > want it. Do you wish to specify the details? With what you have now, IKE cannot be use _at all_ because there is no DOI. This is large step backward; one which was not discussed on the list whatsoever. > - Section 4.4 discusses the authentication calculation. > I expected there to be more discussion about this; > presumably there could be an agreement for a > common default mechanism like HMAC_MD5 for > the algorithm. Insufficient and unreviewed, and incomplete. > > Yes. You moved the authentication data to the BU, and > > as far as I can tell, that was a) never discussed on > > the list, b) pre-supposes that IPsec is a non-starter, > > c) doesn't have any consensus, and d) surprised quite > > a few of us. > > I didn't go back and check the archives, but during the last > two IETFs, in various meetings including the mobileip > working group meetings, it seemed pretty clear to me that > we were being told that IPsec wasn't appropriate for > authenticating Binding Updates. Given that, I didn't see > any alternatives for how to proceed except to make the > authentication data into one of the fields of the Binding > Update option. Operative words: me, and I. Note that this isn't the same as working group consensus. In fact, I haven't heard _anybody_ say that they don't want to IPsec for some parts of the solution other than you, and this draft that got foisted on the working group. > You seem to be dead set on discrediting this work, and > of course I wish you could take a more constructive > approach. You should acknowledge that I argued quite > vociferously in various meetings and venues to retain the > IPsec AH mechanism. You didn't voice any support for > that effort before. Now that another approach has been > proposed, you seem more willing to support IPsec AH. > I don't know what to expect, but I guess it will not be > support from you. I have made literally dozens of posts on this subject and if this is your simplistic take on my view of this matter you are either unwilling or unable to grasp what is at issue here. I have *never* said that I think that IPsec is inappropriate in all circumstances and I challenge you to find where I have said so. I have said that I'd prefer ESP over AH, but again if that leads you to believe that I don't support use of IPsec in some situations, then you are clearly not grasping the subtleties here. > I did send out the proposed format for Binding Update > to a number of people for sanity checking before revising > the draft. Then I had to leave town for almost three > weeks. The work was done (aka getting down to work) > to the best of my understanding of what was needed, and > with as much input as I could gather in the time available. > If consensus indicates another approach, that will be very > fine with me. Yet, and there was no list consensus to do so, and this is the result. > As I understand it, and as further supported by recent > discussion, IPsec security associations aren't really > selectable based on the type of the Destination Options. If this were an original hope of pre-14, then it was clearly a misuse of IPsec. > Plus, authenticating payloads might need a different > algorithm than authenticating the Binding Update -- > so separation is advisable. What leads you to this conclusion? > > I read both the -14 spec and the security > > analysis. I agree with the conclusions of the > > security analysis, as I assume the authors > > did as well. > > As should have been obvious from what I posted, > I largely agree with the conclusions of the work > also -- except that it gives the false impression that > the existing Mobile IPv6 specification opens up > a vulnerability from remote redirection which is > false. That is yet to be seen, and from what I've read, there is no reason whatsoever for them to tone down their message. This is a very serious issue even if it is inconvenience to your standards track uber-alles schedule. > > As far as I can tell, you seem > > to be asking anybody who agrees with that > > analysis to either downplay its conclusions > > or sweep them under the rug. If you want > > marketing spin, I suggest you contact your > > marketing department instead of asking the > > participants of this forum to participate in > > whatever your idea of damage control is. > > This is totally wrong, unconstructive, and very > annoying. I ask you to stop it right away. Your > accusations are unfounded and cause for alarm, > making the entire rest of your points suspect also. So do tell, Charlie: what *was* the purpose of your "please tone it down" request? You are the *only* person who has disputed their findings. Also: it is rather disingenuous to argue with them after the fact since their analysis was made on the -13 draft. The -14 draft, until a week ago or so, was not available to them or anybody else to comment on. Their analysis of the -13 draft was pretty spot on from what I can tell, and it's completely unclear whether -14 -- which hasn't incorporated any feedback from the working group -- is any better. > > I have already sent out my own comments on the > > requirements draft. There are archives if you > > missed them. > > Did you have any comments to make on my suggestions for > improvement? I don't see why your comment was in the > least relevant to what I said. Yes: the unvarnished truth is far better than putting some idiotic market spin on the security problem with mipv6. It's appalling that you'd ask the working group to soft peddle the reality, and is insulting to those who have spent a lot of time trying to make an honest evaluation of the current state of affairs. Mike From owner-mobile-ip@sunroof.eng.sun.com Sat Jul 28 20:39:17 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA11711 for ; Sat, 28 Jul 2001 20:39:16 -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 OAA26810; Fri, 27 Jul 2001 14:35: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 OAA28385; Fri, 27 Jul 2001 14:35:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6RLX0016696 for mobile-ip-dist; Fri, 27 Jul 2001 14:33:00 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6RLWuY16689 for ; Fri, 27 Jul 2001 14:32:56 -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 OAA12110 for ; Fri, 27 Jul 2001 14:33:11 -0700 (PDT) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA29716 for ; Fri, 27 Jul 2001 15:33:09 -0600 (MDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (motgate 2.1) with ESMTP id OAA25546 for ; Fri, 27 Jul 2001 14:33:10 -0700 (MST)] Received: [from il02exi02.comm.mot.com (il02exi02.comm.mot.com [145.1.204.41]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id OAA14839 for ; Fri, 27 Jul 2001 14:33:09 -0700 (MST)] Received: by il02exi02.comm.mot.com with Internet Mail Service (5.5.2653.19) id <3ZHD00RQ>; Fri, 27 Jul 2001 16:32:59 -0500 Message-ID: <01FAF65DEA16D4119B95009027E78F3106AE380C@il02exm26.comm.mot.com> From: Lewis Adam-CAL022 To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] How does HA use routing table? Date: Fri, 27 Jul 2001 16:32:54 -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: Hi, I realize this is an old thread but I just came across it and don't understand the confusion. The way I understood it was that the binding cache in the home agent is independent of the routing table. A binding cache functions to map a node's home address to a care-of address; the routing table is used to determine which next hop to send that packet to in order to reach and address (in this case the care-of address.) The way I look at it they are totally seperate, independent entities. My only stipulation would be that the binding cache would have to be referenced before forwarding the packet, but then again I thought that was how it worked all along. To start placing conditions on what one must have based on the other is very confusing to me. Any thoughts? -----Original Message----- From: James Kempf [mailto:James.Kempf@Sun.COM] Sent: Monday, June 04, 2001 2:05 PM To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] How does HA use routing table? How about; The Home Agent MUST assure that the information in the binding cache is consistent with routing tables for the local subnet. If the Mobile Node as an entry in the routing table for the local subnet, then it MUST not have an entry in the binding cache, and vice versa. jak >X-Delivered-For: >X-mProtect: Mon, 4 Jun 2001 11:29:57 -0700 Nokia Silicon Valley Messaging Protection >Date: Mon, 04 Jun 2001 11:29:56 -0700 >From: "Charles E. Perkins" >To: mobile-ip@sunroof.eng.sun.com >Subject: Re: [mobile-ip] How does HA use routing table? > >Hello, > >First, I concur with Ichiro Okajima's assessment of the intention >of the home agent procedure. > >If the home agent has a binding for the mobile node, then that is >authoritative. If there is a clash between the home agent's >routing table and its Binding Cache entry for the mobile node, >then that means something has gone wrong. In fact, if the >home agent doesn't have a binding cache entry for the mobile >node, it typically shouldn't get the packet at all except insofar >as the home agent is a default router for the home network. >In that case, then its action is well defined, and typically it >still wouldn't have a host-specific route for the mobile node. > >I usually consider the Binding Cache to be like a part of >the routing table anyway, with special flags. > >Can someone suggest an improvement to the wording of the >Mobile IPv6 specification to clarify this? > >Regards, >Charlie P. > > >Qiang Zhang wrote: >> >> I think for Agent to deliever the packet, the implication is that it should >> follow the routing table, even there is a binding cache for a packet. Does >> MIP have to address the issue? >> >> ----- Original Message ----- >> From: "Ichiro Okajima" >> To: >> Sent: Monday, June 04, 2001 1:11 AM >> Subject: [mobile-ip] How does HA use routing table? >> >> > Hello all, >> > >> > I would appreciate it if anyone would answer my question. >> > I think that the HA of Mobile IPv6 has a routing table as well as >> > Binding Cache since it is a kind of router. It seems to me that >> > Mobile IPv6 I-D does not say the relationship between the Binding >> > Cache and the routing table, and how to use the routing table. >> > My guess is as follows: >> > >> > 1) When the HA receives a packet, it firstly checks the Binding >> > Cache whether a binding for the destination address of the packet >> > exists or not. >> > >> > 2) If no binding exist in the Binding Cache, it secondly checks >> > the routing table to find the best route for the packet. >> > >> > Is my understanding correct? >> > >> > Ichiro >> > From owner-mobile-ip@sunroof.eng.sun.com Sat Jul 28 20:42:24 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA12255 for ; Sat, 28 Jul 2001 20:42:23 -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 TAA02078; Fri, 27 Jul 2001 19:02: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 TAA23472; Fri, 27 Jul 2001 19:01:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6S20ZE18372 for mobile-ip-dist; Fri, 27 Jul 2001 19:00:36 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6S20WY18365 for ; Fri, 27 Jul 2001 19:00:32 -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 TAA23418 for ; Fri, 27 Jul 2001 19:00:47 -0700 (PDT) Received: from ms.samsung.com ([211.45.29.136]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA10981 for ; Fri, 27 Jul 2001 20:02:12 -0600 (MDT) Received: from cychong ([127.0.0.1]) by ms.samsung.com (Netscape Messaging Server 4.15 ms Jul 11 2001 16:32:57) with SMTP id GH5UQC00.5S2 for ; Sat, 28 Jul 2001 10:56:36 +0900 Message-ID: <000401c11709$7c23f3c0$10e0d5a5@cychong> From: "Chae-yong Chong" To: References: <476F91F7CFDBD41182E000D0B7E7E693B9ACF6@U9JM7> <3B60235F.1DE13A77@usa.alcatel.com> <000b01c1162f$6aeaa0c0$633c9696@aeb099w> <004501c116f5$d0a35c10$10e0d5a5@cychong> <008701c116fc$846f2250$633c9696@aeb099w> <000601c116ff$bafc4110$10e0d5a5@cychong> Subject: Re: [mobile-ip] A question about 'traceroute' Date: Sat, 28 Jul 2001 11:03:24 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" 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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by sunroof.eng.sun.com id f6S20WY18366 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 Oops some typo in the previous message In the first line , intermedia -> intermediate ----- Original Message ----- From: "Chae-yong Chong" To: Sent: Saturday, July 28, 2001 9:53 AM Subject: Re: [mobile-ip] A question about 'traceroute' > Hi. > > Yes, the question is that whether CN want to know the intermedia nodes in path > from HA to FA where CN's packet is forwarded in tunneling. > I think the MN is always on "Home Network" for CN's point. That's what Mobile IP > provide to nodes. Moreover it is not possible for CN to know where MN is located > without routing optimization. If so, Intermediate nodes informaiton from HA to FA > is meaningless to CN. I think... > > Regards > Chae-yong > > ----- Original Message ----- > From: "Kim Taeyong" > To: > Sent: Saturday, July 28, 2001 9:30 AM > Subject: Re: [mobile-ip] A question about 'traceroute' > > > > Dear Chae-yong. > > > > > > >> ex) > > >> CN send ICMP packet by incrementing TTL=1, 2, 3, ....(TTL decrease ) > > >> Then HA encapsulate ICMP message do not decrease TTL, and send the packet > > >> through the tunnel between HA and FA(TTL decrease ) > > >> > > > > >Some confusion. "encapsulate ICMP message do not decrease TTL" What does it mean? > > >Does it mean that HA does not decrease the TTL value of original packet?(ICMP echo request) > > > > >RFC2003 said that the encapsulator decrease the TTL value of inner packet. > > > > Yes. It's correct. > > HA encapsulate the packet with reduce TTL of inner packet. > > Then, encapsulated packet is sended to FA with not reducing TTL of inner packet but outer packet. > > > > > > fugure. > > > > Assume Initial TTL is 4 for inner, outer packet. > > > > MN -- FA --node A -- node B -- HA -- CN > > TTL of inner packet : 1 2 2 2 3 4 > > TTL of outer packet : 3 3 4 > > > > > > Although, there are some node between HA and FA, more than 1hop, CN knows there is no more node between HA and FA, because TTL of inner packet is decreased by 1. > > > > > > Tae-yong > > > From owner-mobile-ip@sunroof.eng.sun.com Sat Jul 28 20:42:26 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA12270 for ; Sat, 28 Jul 2001 20:42:25 -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 SAA00746; Fri, 27 Jul 2001 18:50:58 -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 SAA22619; Fri, 27 Jul 2001 18:50:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6S1mgS18299 for mobile-ip-dist; Fri, 27 Jul 2001 18:48:42 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6S1mcY18292 for ; Fri, 27 Jul 2001 18:48:39 -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 SAA26371 for ; Fri, 27 Jul 2001 18:48:53 -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 TAA16948 for ; Fri, 27 Jul 2001 19:48: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 SAA23422; Fri, 27 Jul 2001 18:48:52 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6S1mp109103; Fri, 27 Jul 2001 18:48:51 -0700 X-mProtect: Fri, 27 Jul 2001 18:48:51 -0700 Nokia Silicon Valley Messaging Protection Received: from Icharliep-1.iprg.nokia.com (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdabjOjn; Fri, 27 Jul 2001 18:48:49 PDT Message-ID: <3B621A1B.EECE6DAE@iprg.nokia.com> Date: Fri, 27 Jul 2001 18:49:16 -0700 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Michael Thomas CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Concern over draft-team-mobileip-mipv6-sec-reqts-00.txt References: <3B61C80D.4DA456B0@iprg.nokia.com> <15201.51986.555615.673177@thomasm-u1.cisco.com> <3B61D678.CA0C67AB@iprg.nokia.com> <15201.58214.80975.246707@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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > Even if key establishment weren't a definition > of "incomplete" -- which I most assuredly do > not agree with; indeed we've take a giant step > backward if we can't use IKE to key SA's -- > what is currently defined is a length and an > unspecified value for the bits in the vector. > That is not my idea of "complete". How are > replays, for example, prevented? - Replays are prevented by using different sequence numbers. Section 13.1 discusses this briefly. - Requiring IKE from every IPv6 node is too much. However, it should be _allowed_ for nodes that want it. Do you wish to specify the details? - Section 4.4 discusses the authentication calculation. I expected there to be more discussion about this; presumably there could be an agreement for a common default mechanism like HMAC_MD5 for the algorithm. > > Furthermore, varying parts of the draft have varying > > degrees of consensus. Perhaps you were thinking of > > some particular part of the draft for your comment. > > Could you be more specific? We need to have as much > > discussion as possible on it so that we can generate > > ideas for making sure it satisfies the requirements. > > Yes. You moved the authentication data to the BU, and > as far as I can tell, that was a) never discussed on > the list, b) pre-supposes that IPsec is a non-starter, > c) doesn't have any consensus, and d) surprised quite > a few of us. I didn't go back and check the archives, but during the last two IETFs, in various meetings including the mobileip working group meetings, it seemed pretty clear to me that we were being told that IPsec wasn't appropriate for authenticating Binding Updates. Given that, I didn't see any alternatives for how to proceed except to make the authentication data into one of the fields of the Binding Update option. You seem to be dead set on discrediting this work, and of course I wish you could take a more constructive approach. You should acknowledge that I argued quite vociferously in various meetings and venues to retain the IPsec AH mechanism. You didn't voice any support for that effort before. Now that another approach has been proposed, you seem more willing to support IPsec AH. I don't know what to expect, but I guess it will not be support from you. I did send out the proposed format for Binding Update to a number of people for sanity checking before revising the draft. Then I had to leave town for almost three weeks. The work was done (aka getting down to work) to the best of my understanding of what was needed, and with as much input as I could gather in the time available. If consensus indicates another approach, that will be very fine with me. > I've already discussed in a number of posts why > it is premature to declare IPsec dead. Thus far > you have as yet to respond to any of them. I'm happy either way. The authentication data can be part of the IPsec header, or it can be in the Binding Update. I understand the arguments for both sides, and I am not that particular. However, I would like to encourage the discussion to take place ASAP. As I understand it, and as further supported by recent discussion, IPsec security associations aren't really selectable based on the type of the Destination Options. Plus, authenticating payloads might need a different algorithm than authenticating the Binding Update -- so separation is advisable. > I read both the -14 spec and the security > analysis. I agree with the conclusions of the > security analysis, as I assume the authors > did as well. As should have been obvious from what I posted, I largely agree with the conclusions of the work also -- except that it gives the false impression that the existing Mobile IPv6 specification opens up a vulnerability from remote redirection which is false. > As far as I can tell, you seem > to be asking anybody who agrees with that > analysis to either downplay its conclusions > or sweep them under the rug. If you want > marketing spin, I suggest you contact your > marketing department instead of asking the > participants of this forum to participate in > whatever your idea of damage control is. This is totally wrong, unconstructive, and very annoying. I ask you to stop it right away. Your accusations are unfounded and cause for alarm, making the entire rest of your points suspect also. > > I'd be curious to find out whether you have any comments > > on my suggestions on how to improve the requirements > > draft. I didn't see anything useful in your message > > in response to my comments. > > I have already sent out my own comments on the > requirements draft. There are archives if you > missed them. Did you have any comments to make on my suggestions for improvement? I don't see why your comment was in the least relevant to what I said. Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Sat Jul 28 20:49:22 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA13687 for ; Sat, 28 Jul 2001 20:49:22 -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 HAA29634; Sat, 28 Jul 2001 07:04:05 -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 HAA00091; Sat, 28 Jul 2001 07:03:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6SE1Sx20867 for mobile-ip-dist; Sat, 28 Jul 2001 07:01:28 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6SE1PY20860 for ; Sat, 28 Jul 2001 07:01:25 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA22900 for ; Sat, 28 Jul 2001 07:01:39 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA24180 for ; Sat, 28 Jul 2001 07:01:39 -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 HAA01812; Sat, 28 Jul 2001 07:01:08 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6SE18s24685; Sat, 28 Jul 2001 07:01:08 -0700 X-mProtect: Sat, 28 Jul 2001 07:01:08 -0700 Nokia Silicon Valley Messaging Protection Received: from Icharliep-1.iprg.nokia.com (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdO5TuYW; Sat, 28 Jul 2001 07:01:05 PDT Message-ID: <3B62C5BD.519854A@iprg.nokia.com> Date: Sat, 28 Jul 2001 07:01:33 -0700 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com, Pat Calhoun Subject: Re: [mobile-ip] Handover Smoothing - What to Do? References: <034BEFD03799D411A59F00508BDF754603008B7B@esealnt448.al.sw.ericsson.se> <20010727093945.K13541@charizard.diameter.org> 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 Pat, O.K. I'll try to keep in mind that 3GPP2 cares a lot about Mobile IPv4. The last I checked, they were interested in IPv6, but that was a while back. The situation with Mobile IPv6 is indeed contentious right now, so I understand 3GPP2 reluctance to incorporate it into their work. Regards, Charlie P. Pat Calhoun wrote: > On Fri, Jul 27, 2001 at 06:44:42PM +0200, Hesham Soliman (ERA) wrote: > > > Not a technical reason, as well as completely false. Please remember > > > that there are two (2) 3G organizations. Both of you seem to be ignoring > > > the one that's actually using the stacks developed in this WG. > > > > > => Pat, do I have a sign today saying "Pat please misunderstand me" :)) > > At least I'd know your intentions :) :) > > > I know there are two and was only referring to the "one" mandating > > IPv6 for telephony. That was not 3GPP2 last time I checked. > > Things might have changed though... I hope I was wrong. > > I may have misunderstood all of your e-mails today, and if so, please > accept my appologies. 3GPP2 is planning on using IP for telephony, but > v4 will be supported (given that they already have Mobile IPv4 trials and > some limited deployments already). They are planning on moving towards v6, > but prior to doing so, need some reassurances that Mobile IPv6 will move > forward. > > So far, they haven't had any such reassurances :( > > PatC From owner-mobile-ip@sunroof.eng.sun.com Sat Jul 28 20:50:16 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA13808 for ; Sat, 28 Jul 2001 20:50:14 -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 NAA02041; Sat, 28 Jul 2001 13:10:43 -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 MAA10130; Sat, 28 Jul 2001 12:10:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6SJ94P21550 for mobile-ip-dist; Sat, 28 Jul 2001 12:09:04 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.82.166] (may be forged)) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6SJ91Y21543 for ; Sat, 28 Jul 2001 12:09:01 -0700 (PDT) Received: from teknoturk (dsl197-130.Eng.Sun.COM [129.146.197.130]) by jurassic.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with SMTP id f6SJ9ES716523 for ; Sat, 28 Jul 2001 12:09:14 -0700 (PDT) From: "Alper" To: Subject: RE: [mobile-ip] How does HA use routing table? Date: Sat, 28 Jul 2001 11:59:13 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <01FAF65DEA16D4119B95009027E78F3106AE380C@il02exm26.comm.mot.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 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 Hello, This is geting into implementation details, but let me answer this based on my implementation experience. When home agent recevies a binding update, it creates a tunnel entry between home agent and the care-of address. Also it installs a routing entry, that says all packet sent to home_address1 should be forwarded through this newly created tunnel. Note that this "host specific" routing entry co-exists with less-specific entry that says "all the packets sent to addresses in prefix1 should be forwarded on interface1". So now, when home agent receives a packet destined to home_address1, it'll use this host specific routing entry to forward it through tunnel. For other mobile nodes which are at "home", since there won't be such host specific routes, packets will be forwarded on to interface1. So, having a binding cache entry creates a matching routing entry which takes care of forwarding. Home agent doesn't have to check the binding cache when it receives packets to be forwarded. alper -----Original Message----- From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile-ip@sunroof.eng.sun.com]On Behalf Of Lewis Adam-CAL022 Sent: Friday, July 27, 2001 2:33 PM To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] How does HA use routing table? Hi, I realize this is an old thread but I just came across it and don't understand the confusion. The way I understood it was that the binding cache in the home agent is independent of the routing table. A binding cache functions to map a node's home address to a care-of address; the routing table is used to determine which next hop to send that packet to in order to reach and address (in this case the care-of address.) The way I look at it they are totally seperate, independent entities. My only stipulation would be that the binding cache would have to be referenced before forwarding the packet, but then again I thought that was how it worked all along. To start placing conditions on what one must have based on the other is very confusing to me. Any thoughts? -----Original Message----- From: James Kempf [mailto:James.Kempf@Sun.COM] Sent: Monday, June 04, 2001 2:05 PM To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] How does HA use routing table? How about; The Home Agent MUST assure that the information in the binding cache is consistent with routing tables for the local subnet. If the Mobile Node as an entry in the routing table for the local subnet, then it MUST not have an entry in the binding cache, and vice versa. jak >X-Delivered-For: >X-mProtect: Mon, 4 Jun 2001 11:29:57 -0700 Nokia Silicon Valley Messaging Protection >Date: Mon, 04 Jun 2001 11:29:56 -0700 >From: "Charles E. Perkins" >To: mobile-ip@sunroof.eng.sun.com >Subject: Re: [mobile-ip] How does HA use routing table? > >Hello, > >First, I concur with Ichiro Okajima's assessment of the intention >of the home agent procedure. > >If the home agent has a binding for the mobile node, then that is >authoritative. If there is a clash between the home agent's >routing table and its Binding Cache entry for the mobile node, >then that means something has gone wrong. In fact, if the >home agent doesn't have a binding cache entry for the mobile >node, it typically shouldn't get the packet at all except insofar >as the home agent is a default router for the home network. >In that case, then its action is well defined, and typically it >still wouldn't have a host-specific route for the mobile node. > >I usually consider the Binding Cache to be like a part of >the routing table anyway, with special flags. > >Can someone suggest an improvement to the wording of the >Mobile IPv6 specification to clarify this? > >Regards, >Charlie P. > > >Qiang Zhang wrote: >> >> I think for Agent to deliever the packet, the implication is that it should >> follow the routing table, even there is a binding cache for a packet. Does >> MIP have to address the issue? >> >> ----- Original Message ----- >> From: "Ichiro Okajima" >> To: >> Sent: Monday, June 04, 2001 1:11 AM >> Subject: [mobile-ip] How does HA use routing table? >> >> > Hello all, >> > >> > I would appreciate it if anyone would answer my question. >> > I think that the HA of Mobile IPv6 has a routing table as well as >> > Binding Cache since it is a kind of router. It seems to me that >> > Mobile IPv6 I-D does not say the relationship between the Binding >> > Cache and the routing table, and how to use the routing table. >> > My guess is as follows: >> > >> > 1) When the HA receives a packet, it firstly checks the Binding >> > Cache whether a binding for the destination address of the packet >> > exists or not. >> > >> > 2) If no binding exist in the Binding Cache, it secondly checks >> > the routing table to find the best route for the packet. >> > >> > Is my understanding correct? >> > >> > Ichiro >> > From owner-mobile-ip@sunroof.eng.sun.com Sat Jul 28 20:51:05 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA14118 for ; Sat, 28 Jul 2001 20:51:04 -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 SAA24083; Fri, 27 Jul 2001 18:02:53 -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 SAA04259; Fri, 27 Jul 2001 18:02:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6S11Ud18199 for mobile-ip-dist; Fri, 27 Jul 2001 18:01:30 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6S11QY18192 for ; Fri, 27 Jul 2001 18:01:26 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA17571 for ; Fri, 27 Jul 2001 18:01:40 -0700 (PDT) Received: from telecom.samsung.co.kr ([165.213.221.4]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA14686 for ; Fri, 27 Jul 2001 18:01:39 -0700 (PDT) Received: from metro (a22414 [165.213.224.14]) by telecom.samsung.co.kr (8.9.3/8.9.3) with SMTP id KAA08603 for ; Sat, 28 Jul 2001 10:04:09 +0900 (KST) Message-ID: <007701c11700$d47104e0$0ee0d5a5@telecom.samsung.co.kr> From: "junhyuk song" To: References: <200107271107.HAA06650@ietf.org> <04fa01c11694$b08a2960$0ee0d5a5@telecom.samsung.co.kr> <20010727065112.L13541@charizard.diameter.org> Subject: Re: [mobile-ip] I-D ACTION:draft-ietf-mobileip-aaa-key-08.txt Date: Sat, 28 Jul 2001 10:01:26 +0900 Organization: cdma2000 system 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.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by sunroof.eng.sun.com id f6S11RY18193 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 Please reade my comment below. ----- Original Message ----- From: "Pat Calhoun" To: Cc: "Pat Calhoun" Sent: Friday, July 27, 2001 10:51 PM Subject: Re: [mobile-ip] I-D ACTION:draft-ietf-mobileip-aaa-key-08.txt > On Fri, Jul 27, 2001 at 09:07:20PM +0900, junhyuk song wrote: > > Hi Pat, > > > > I don't see the need for MN-FA shared key while using FAC and MN-AAA authentication. > > The AAAH will verify Mobile Node for Foreign Agent with MN-AAA authenticatiion defined in RFC3012. It seems to me using MN-FA Auth and FAC with MN-AAA Auth together is somewhat redundant. > > It isn't redundant since the AAA and the FA may be owned by separate > administrative domains. Having said that, no where in the draft does it > state that the MN-FA is to be present if the MN-AAA is present. Yes I agree, AAA and FA may be owned by the separate administrative domains. That is the where FAC needed right? May be I misunderstood your Internet Draft 0.7. It said SHOULD include MN-FA Key Request extension, if there is no MN-FA Security Association. " If the mobile node does not have a Mobility Security Association with the foreign agent, it SHOULD include an MN-FA Key Request extension" It is same requirement with FAC in RFC3012. > > > Besides, I wish you made separate section for RADIUS consideration in your draft. > > why? This draft discusses how the keys are sent to the mobile node, not > to a RADIUS and/or Diameter device. > > The AAA software used is completely irrelevant to this draft (unless I missed > something). Yes, you are right. The rationale behind that request was unlike DIAMETER, RADIUS may have some security issue and your Internet Draft seems like also considering RADIUS based AAA. > > Further more the RADIUS based AAA case must be noted for DOS attack consideration, because HA will blindly procede Mobile IP signalling and AAA message without MN-HA authentication for the initial RRQ. Another approach is clearly defining MN-AAA authentication from HA before AAAH procede to generate "Key Material" and "Mn-HA shared key". > > Right, and this was one of the reasons why we decided to allow the FA to > forward the messages to the AAA infrastructure in Diameter. 3GPP2 decided > to let the HA to the work, and that is simply the wrong approach, and will > lead to DoS attacks. I've brought this up numerous times, and the real fix > is to change how 3GPP2 handles AAA (not necessarily the protocol, but rather > the way it uses RADIUS). I agree. > > It also may be helpful to mandate HA-FA authentication between FA and HA. > > If keys are generated, yes, but this is not covered by this draft. It seems > like what you are requesting is really in the Diameter Mobile IP application, > and not in this one. I agree, I was more like request 3GPP2 perspective, since 3GPP2 is currently using RADIUS for AAA. > PatC Regards, JH SONG From owner-mobile-ip@sunroof.eng.sun.com Sat Jul 28 20:58:40 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA15967 for ; Sat, 28 Jul 2001 20:58:39 -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 QAA06325; Fri, 27 Jul 2001 16:41:00 -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 QAA07160; Fri, 27 Jul 2001 16:40:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6RNdX817831 for mobile-ip-dist; Fri, 27 Jul 2001 16:39:33 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6RNdUY17824 for ; Fri, 27 Jul 2001 16:39:30 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA03262 for ; Fri, 27 Jul 2001 16:39:43 -0700 (PDT) Received: from ms.samsung.com ([211.45.29.136]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA26135 for ; Fri, 27 Jul 2001 16:39:42 -0700 (PDT) Received: from cychong ([127.0.0.1]) by ms.samsung.com (Netscape Messaging Server 4.15 ms Jul 11 2001 16:32:57) with SMTP id GH5O7O00.HPT for ; Sat, 28 Jul 2001 08:35:48 +0900 Message-ID: <004501c116f5$d0a35c10$10e0d5a5@cychong> From: "Chae-yong Chong" To: References: <476F91F7CFDBD41182E000D0B7E7E693B9ACF6@U9JM7> <3B60235F.1DE13A77@usa.alcatel.com> <000b01c1162f$6aeaa0c0$633c9696@aeb099w> Subject: Re: [mobile-ip] A question about 'traceroute' Date: Sat, 28 Jul 2001 08:42:36 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" 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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by sunroof.eng.sun.com id f6RNdUY17825 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 Hi I have some question about your message. ----- Original Message ----- From: "Kim Taeyong" To: Sent: Friday, July 27, 2001 9:02 AM Subject: Re: [mobile-ip] A question about 'traceroute' > Hi. > > I think traceroute program works. But wholl path not detectable. > Nodes exists in FA-HA tunnel can not be traced. > > ex) > CN send ICMP packet by incrementing TTL=1, 2, 3, ....(TTL decrease ) > Then HA encapsulate ICMP message do not decrease TTL, and send the packet > through the tunnel between HA and FA(TTL decrease ) > Some confusion. "encapsulate ICMP message do not decrease TTL" What does it mean? Does it mean that HA does not decrease the TTL value of original packet?(ICMP echo request) RFC2003 said that the encapsulator decrease the TTL value of inner packet. > FA decapsulate the packet and send to MN,(TTL decrease ) > > Finally, MN send ICMP Port Unreachable message to CN. > Then traceroute ends. > > > > > > Regards Chae-yong From owner-mobile-ip@sunroof.eng.sun.com Sat Jul 28 21:01:54 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA16567 for ; Sat, 28 Jul 2001 21:01:52 -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 PAA21871; Fri, 27 Jul 2001 15:46:49 -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 PAA20389; Fri, 27 Jul 2001 15:46:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6RMitu17637 for mobile-ip-dist; Fri, 27 Jul 2001 15:44:55 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6RMioY17630 for ; Fri, 27 Jul 2001 15:44:50 -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 PAA23443 for ; Fri, 27 Jul 2001 15:45:03 -0700 (PDT) From: Internet-Drafts@ietf.org Received: from public.szptt.net.cn (mail1-smtp.szptt.net.cn [202.96.136.221]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id QAA09960 for ; Fri, 27 Jul 2001 16:44:30 -0600 (MDT) Received: from public.szptt.net.cn([202.96.136.221]) by public.szptt.net.cn(JetMail 2.5.3.0) with SMTP id jm53b61f022; Fri, 27 Jul 2001 22:42:01 -0000 Received: from loki.ietf.org([132.151.1.177]) by public.szptt.net.cn(JetMail 2.5.3.0) with SMTP id jm1a3b5f4ee9; Wed, 25 Jul 2001 22:28:50 -0000 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id LAA29632 for ietf-123-outbound.01@ietf.org; Wed, 25 Jul 2001 11:35:00 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA25589 for ; Wed, 25 Jul 2001 06:34:54 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07722; Wed, 25 Jul 2001 06:34:51 -0400 (EDT) Message-Id: <200107251034.GAA07722@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] I-D ACTION:draft-montenegro-sucv-01.txt Date: Wed, 25 Jul 2001 06:34:51 -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. Title : SUCV Identifiers and Addresses Author(s) : G. Montenegro, C. Castelluccia Filename : draft-montenegro-sucv-01.txt Pages : 23 Date : 24-Jul-01 This document addresses the identifier ownership problem. It does so by using characteristics of Statistic Uniqueness and Cryptographic Verifiability (SUCV) of certain entities which this document calls SUCV Identifiers (SUCV ID's). This note also proposes using these SUCV characteristics in related entities called SUCV Addresses in order to severely limit certain classes of denial of service attacks and hijacking attacks. SUCV addresses are particularly applicable to solve the 'address ownership' problem that severely undermines confidence in mechanisms like Binding Updates in Mobile IP for IPv6. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-montenegro-sucv-01.txt 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-montenegro-sucv-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-montenegro-sucv-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: <20010724132501.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-montenegro-sucv-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-montenegro-sucv-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010724132501.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Sat Jul 28 21:17:37 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA18587 for ; Sat, 28 Jul 2001 21:17:35 -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 RAA14028; Sat, 28 Jul 2001 17:52: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 QAA28823; Sat, 28 Jul 2001 16:52:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6SNp0G22133 for mobile-ip-dist; Sat, 28 Jul 2001 16:51:00 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6SNovY22126 for ; Sat, 28 Jul 2001 16:50:57 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA22839 for ; Sat, 28 Jul 2001 16:51:11 -0700 (PDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id QAA12478 for ; Sat, 28 Jul 2001 16:51:10 -0700 (PDT) Received: (qmail 24322 invoked by uid 500); 28 Jul 2001 23:40:00 -0000 Date: Sat, 28 Jul 2001 16:40:00 -0700 From: Pat Calhoun To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] I-D ACTION:draft-ietf-mobileip-aaa-key-08.txt Message-ID: <20010728163959.B24014@charizard.diameter.org> References: <200107271107.HAA06650@ietf.org> <04fa01c11694$b08a2960$0ee0d5a5@telecom.samsung.co.kr> <20010727065112.L13541@charizard.diameter.org> <000901c1171b$71ccfd60$10e0d5a5@cychong> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <000901c1171b$71ccfd60$10e0d5a5@cychong>; from cychong@samsung.com on Sat, Jul 28, 2001 at 01:11:57PM +0900 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: > Okay, let's assume the FA and AAAF are controlled by what you called, "separate administrative domain". > But there must be a security association between FA and AAAF. of course. > FAC extension itself does not provide any securicy. However MN-AAA extension with FAC extension provides > some level of securicy. Isn't it the purpose of RFC3012 ? RFC3012 states: FAC provides replay protection, not authentication. The MN-AAA piggy backs the security authentication between the FA-AAAF, and then the AAAF-AAAH. So, a secure Diameter message is a replacement for MN-FA and FA-HA. Of course, you don't want to always invoke the overhead of AAA, hence key distribution. > If the Mobile Node does not have a security association with the > Foreign Agent, the Mobile Node MUST include the MN-AAA Authentication > extension as defined in section 6. > > Does that mean the MN-AAA extension provide equivalent level of securicy of MN-FA? MN-AAA combined with the AAA infrastructure security across both domains. > As you know currently Diameter is not the RFC state, so 3GPP2 should have > a way to use this draft with RADIUS. It's not the wrong approach, it is just for an avoidable > situation. You know it takes a long time for Diameter to be prevailed. That means > 3GPP2 should have a interim solution which cooperate this draft with RADIUS. Right, we we cannot re-write RADIUS for it to be secure. There is only so much that we can do, given the way RADIUS works. So the issues raised have nothing to do with this draft, but rather RADIUS weaknesses. Thanks, PatC From owner-mobile-ip@sunroof.eng.sun.com Sat Jul 28 21:26:04 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA04850 for ; Sat, 28 Jul 2001 20:12:19 -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 SAA28983; Fri, 27 Jul 2001 18:52: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 RAA02965; Fri, 27 Jul 2001 17:52:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6S0p6F18113 for mobile-ip-dist; Fri, 27 Jul 2001 17:51:06 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6S0p3Y18106 for ; Fri, 27 Jul 2001 17:51:03 -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 RAA12404 for ; Fri, 27 Jul 2001 17:51:17 -0700 (PDT) Received: from ms.samsung.com ([211.45.29.136]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA25004 for ; Fri, 27 Jul 2001 18:52:41 -0600 (MDT) Received: from cychong ([127.0.0.1]) by ms.samsung.com (Netscape Messaging Server 4.15 ms Jul 11 2001 16:32:57) with SMTP id GH5RHZ00.TQJ for ; Sat, 28 Jul 2001 09:46:47 +0900 Message-ID: <000601c116ff$bafc4110$10e0d5a5@cychong> From: "Chae-yong Chong" To: References: <476F91F7CFDBD41182E000D0B7E7E693B9ACF6@U9JM7> <3B60235F.1DE13A77@usa.alcatel.com> <000b01c1162f$6aeaa0c0$633c9696@aeb099w> <004501c116f5$d0a35c10$10e0d5a5@cychong> <008701c116fc$846f2250$633c9696@aeb099w> Subject: Re: [mobile-ip] A question about 'traceroute' Date: Sat, 28 Jul 2001 09:53:34 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" 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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by sunroof.eng.sun.com id f6S0p3Y18107 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 Hi. Yes, the question is that whether CN want to know the intermedia nodes in path from HA to FA where CN's packet is forwarded in tunneling. I think the MN is always on "Home Network" for CN's point. That's what Mobile IP provide to nodes. Moreover it is not possible for CN to know where MN is located without routing optimization. If so, Intermediate nodes informaiton from HA to FA is meaningless to CN. I think... Regards Chae-yong ----- Original Message ----- From: "Kim Taeyong" To: Sent: Saturday, July 28, 2001 9:30 AM Subject: Re: [mobile-ip] A question about 'traceroute' > Dear Chae-yong. > > > >> ex) > >> CN send ICMP packet by incrementing TTL=1, 2, 3, ....(TTL decrease ) > >> Then HA encapsulate ICMP message do not decrease TTL, and send the packet > >> through the tunnel between HA and FA(TTL decrease ) > >> > > >Some confusion. "encapsulate ICMP message do not decrease TTL" What does it mean? > >Does it mean that HA does not decrease the TTL value of original packet?(ICMP echo request) > > >RFC2003 said that the encapsulator decrease the TTL value of inner packet. > > Yes. It's correct. > HA encapsulate the packet with reduce TTL of inner packet. > Then, encapsulated packet is sended to FA with not reducing TTL of inner packet but outer packet. > > > fugure. > > Assume Initial TTL is 4 for inner, outer packet. > > MN -- FA --node A -- node B -- HA -- CN > TTL of inner packet : 1 2 2 2 3 4 > TTL of outer packet : 3 3 4 > > > Although, there are some node between HA and FA, more than 1hop, CN knows there is no more node between HA and FA, because TTL of inner packet is decreased by 1. > > > Tae-yong > From owner-mobile-ip@sunroof.eng.sun.com Sun Jul 29 10:21:28 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA21717 for ; Sun, 29 Jul 2001 10:21:28 -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 IAA24784; Sun, 29 Jul 2001 08:21: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 HAA12141; Sun, 29 Jul 2001 07:21:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6TEKAd24331 for mobile-ip-dist; Sun, 29 Jul 2001 07:20:10 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6TEK6Y24321 for ; Sun, 29 Jul 2001 07:20:06 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA11982 for ; Sun, 29 Jul 2001 07:20:19 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA18925 for ; Sun, 29 Jul 2001 07:20:18 -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 HAA15185 for ; Sun, 29 Jul 2001 07:20:17 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6TEKHk06008 for ; Sun, 29 Jul 2001 07:20:17 -0700 X-mProtect: Sun, 29 Jul 2001 07:20:17 -0700 Nokia Silicon Valley Messaging Protection Received: from Icharliep-1.iprg.nokia.com (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpd9SAGJj; Sun, 29 Jul 2001 07:20:16 PDT Message-ID: <3B641BBB.DAF70116@iprg.nokia.com> Date: Sun, 29 Jul 2001 07:20:43 -0700 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Mobile IP Working Group Mailing List Subject: [mobile-ip] (non-technical) Support for draft-team-mobileip-mipv6-sec-reqts-00.txt 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, This note is intended to reaffirm my support for the recent security draft, but does not contain any additional technical proposals or suggestions. The security requirements draft reaches a number of conclusions about what is needed to make sure that Mobile IPv6 is secure. I believe that the conclusions are largely correct, and my private conversations and e-mails with some of the authors would make that clear. The corrections and suggestions contained in my previous e-mail was not intended to derogate the findings of the abovementioned draft, since I largely agree with them. Unfortunately, a previous message to this mailing list claimed otherwise, and as co-author and document editor for the Mobile IPv6 draft, I feel that it is very important for my support for this document to be clearly understood. I believe that all of the vulnerabilities in the document need to be understood, and the vulnerabilities specific to Mobile IPv6 need to be countered within the Mobile IPv6 specification. One exception is that I suggested a MUST should be a SHOULD, and so on, but this does not amount to lack of support for the document, nor any wholesale dispute with its findings, nor any attempt on my part to soft-peddle reality. The main point of my previous note was to urge the authors to restate certain introductory discussion points (not the eventual findings) so that it would be clear that Mobile IPv6 already DOES address one of the very important potential vulnerabilities discussed within the report. I have been stressing over this for over a day now and it seems to me that since I have the responsibility for revising the Mobile IPv6 document, and since the requirements document will be used to determine further revisions, I have to be sure that interested parties within the working group understand that I do support the analysis offered within the security requirements document, and the process (albeit seemingly slow) by which that document can be used to make progress. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Sun Jul 29 15:40:17 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA01188 for ; Sun, 29 Jul 2001 15:40: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 NAA12857; Sun, 29 Jul 2001 13:40:37 -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 MAA13096; Sun, 29 Jul 2001 12:40:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6TJcRL25496 for mobile-ip-dist; Sun, 29 Jul 2001 12:38:27 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6TJcOY25489 for ; Sun, 29 Jul 2001 12:38:24 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA13120 for ; Sun, 29 Jul 2001 12:38:38 -0700 (PDT) Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA04454 for ; Sun, 29 Jul 2001 12:38:33 -0700 (PDT) Received: from strtio1.cup.hp.com (strtio1.cup.hp.com [15.13.129.245]) by palrel1.hp.com (Postfix) with ESMTP id D29B21521; Sun, 29 Jul 2001 12:38:32 -0700 (PDT) Received: (from jlau@localhost) by strtio1.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) id MAA28069; Sun, 29 Jul 2001 12:40:18 -0700 (PDT) Date: Sun, 29 Jul 2001 12:40:18 -0700 (PDT) From: Joe Lau Message-Id: <200107291940.MAA28069@strtio1.cup.hp.com> To: charliep@iprg.nokia.com, pcalhoun@diameter.org Subject: [mobile-ip] Generalized MN-HA and MN-FAKey Reply Extension Cc: jlau@cup.hp.com, mobile-ip@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset=X-roman8 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 Charlie and Pat, On your latest draft , I am puzzled over the asymmetry between the MN-HA Key Reply Extension and the MN-FA Key Reply Extension. The former has a lifetime field but the latter does not. I understand that the lifetime of the MN-FA Key will come from the Unsolicited MN-FA Key Material From AAA Subtype. But I don't understand why these two keys have to be treated differently as far as how the lifetime is placed. Thanks in advance for your clarification. Regards, Joe Lau From owner-mobile-ip@sunroof.eng.sun.com Sun Jul 29 21:07:23 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA08454 for ; Sun, 29 Jul 2001 21:07:22 -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 SAA17120; Sun, 29 Jul 2001 18:07: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 SAA19687; Sun, 29 Jul 2001 18:07:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6U16Ue26430 for mobile-ip-dist; Sun, 29 Jul 2001 18:06:30 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6U16RY26423 for ; Sun, 29 Jul 2001 18:06:27 -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 SAA00815 for ; Sun, 29 Jul 2001 18:06:42 -0700 (PDT) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA23176 for ; Sun, 29 Jul 2001 19:08:09 -0600 (MDT) Received: by megisto-sql1.megisto.com with Internet Mail Service (5.5.2650.21) id ; Sun, 29 Jul 2001 21:06:34 -0400 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Handover Smoothing - What to Do? Date: Sun, 29 Jul 2001 21:06:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) 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: So this is the message to which I responded, "I don't buy it." You requested more detail. Here is the general observation. You are proposing bicasting as a solution that solves only a part of the handover smoothing problem, that is the potential loss of packets in flight between an HA or hierarchical MIP agent and an FA or AR. That's fine as far as it goes and it seems it should be made clear that this is *all* it does. It does not help in the general case of interruption of flow between oFA/MN and nFA/MN. I believe you agree to this below when you say the examples I put forth were L2 specific. More on those below. > -----Original Message----- > From: Karim El-Malki (ERA) [mailto:Karim.El-Malki@era.ericsson.se] > Sent: Thursday, July 26, 2001 10:44 AM > To: 'mobile-ip@sunroof.eng.sun.com' > Subject: RE: [mobile-ip] Handover Smoothing - What to Do? > > > > They are both receiving packets without any knowledge of what > > the other > > has received, or has forwarded to the MN. Might you not have > > a situation > > like this? > > I agree that there should not be the need for nFA to know what > oFA has transmitted. What I'm saying is that if you bicast and > (if needed) have an appropriate (jitter) buffer size at nFA then > it should be possible to avoid duplicates. More below. > > > > > At a single point in time the MN is no longer reachable from > > the oFA and is > > not yet reachable on the nFA. At that point in time a packet > > arrives at > > both > > oFA and nFA and they discard the packet. The MN attaches to > > the nFA but the > > packet is gone. (That's in case A you describe). > > I would think that this is an effect of L2 (i.e. L2 handoff time) > and we are mostly aiming to minimise/eliminate effects due to L3. Good. We're agreeing so far. > Also what I was pointing to is that a buffer is probably needed > if the handoff time from oFA to nFA is not negligible (your next > case and this case). That's why packet dropping is a MAY. So this > case wouldn't happen, unless of course it's not TCP and you don't > care about dropping some packets. In fact low latency handoffs are > probably most useful for real-time services (e.g. Voice on UDP) > in which case, if there's an period of L2 disconnection during > handoff, the packets should be dropped. So here we need some kind of information that describes FA or AR behavior wrt duration of the handoff time and whether or not it's TCP traffic or something that is realtime traffic. > > > > > Or like this? > > > > At a single point in time a packet arrives at the oFA and is > > sent to the MN > > and > > at the same time arrives at the nFA and gets buffered. The > > MN disconnects > > and then reconnects at the nFA and gets a second copy of the packet. > > (That's > > in case B you describe). > > The buffer size should be set such that you don't get duplicates. > By the time MN connects to nFA, the second copy of the packet > should be dropped out of the FIFO queue/buffer and the next one > should be ready for sending to MN. Of course this calculation > depends on the l2 handoff characteristics and possibly the wired > connectivity between the bicasting point and oFA/nFA. I agree with this, but I don't know how to do it. Now we need to add to the decision matrix characteristics about the wired connectivity. But still, it doesn't take into account latency within the network. Whereas it seems that a receiving station might be able to make some intelligent decisions about when it is important to drop a packet (because it arrived way too late), but now do you want the network in between to get involved in the measurement and timing of these decisions? > > > > > Or like this? > > The same packet arrives at oFA and is transmitted to the MN > > which then moves > > to the > > nFA and gets the same packet which was delayed on its way > to the nFA. > > That would again need to be handled by a jitter-smoothing > buffer at nFA. OK, but how? A packet arrives at the nFA. How does the nFA have any idea whether or not it needs to be buffered and then for how long, or dropped? In this case it should be dropped, in the previous case it should be dropped, and in the first case it should be sent. But the only way I know that is by knowing what the MN has already received. > > > > > Or like this? > > The MN disconnects from the oFA the packet arrives and is > > dropped, then the > > MN comes > > back to the oFA because of radio conditions and the packet > > has been lost. > > We could devise some temporary oFA buffer for this, but the L2 > handoff failure is pretty serious so I think that it is > too much to expect smooth handoffs in this case. If we can > maintain L3 connectivity then I think that should be good enough. > > > > > It seems like there is some coordination needed between the > > oFA and the nFA > > to > > overcome these problems, perhaps a temporary tunnel? But > in that case > > bicasting from > > an HA or a hierarchical FA wouldn't be adding much to it, > > would it. > > Well, I think that having a local central HA would help. > Say that oFA and nFA are at an equal distance from the GFA > which is the aggregation router between the two. That could > alleviate jitter on the fixed network, as has been already > mentioned by James. Also, if oFA and nFA happen to be connected > to each other through the GFA router, then bicasting at the > GFA would be more efficient. But wait a second. What do you mean by equal distance? Number of hops, geographical distance? It has to be transmission time. Is this another item we need to add to our decision matrix? > > >At any > > rate > > one would think that issues like this need some exploration > > and explanation > > somewhere. > > OK. Up to now there has been a lot of emphasis on TCP. Although I > agree that it would be useful to give more detail of how bicasting > + buffering works with TCP, we are also not considering the fact that > a major driver for having faster handoffs at L3 was to support > real-time services (over UDP). I would think that the issues above are > not applicable to this case? If this is so then we should not apply > these issues to bicasting/buffering in general and make that > clear too. > > Rgds > /Karim > So I guess in summary, "I don't buy it," means I'm not convinced by your answers. I've given some of my reasons why. Speaking as a member of the working group now: So what's my position on this? It seems that there are fairly obvious cases in which bicasting introduces packet duplicates with potentially unknown effects in the network. It doesn't seem the network agents will have the information needed to prevent this from happening. What I would recommend instead of including bicasting in the fast handoff drafts for v4 and v6 is a placeholder that describes precisely what the problem is (of lost packets in flight) and that a solution needs to be provided. The WG debates the possible solutions and puts those in a separate draft. Speaking as a working group chair now: I'm doing a little work to find out whether a solution that introduces duplicate packets will be shot down by the IESG right off the bat. It seems wise to separate the fast from the smooth part, advance the fast, and produce a solution for the smooth later. I will of course dutifully abide by the consensus of the working group. Hope this helps, Phil From owner-mobile-ip@sunroof.eng.sun.com Sun Jul 29 21:18:23 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA08636 for ; Sun, 29 Jul 2001 21:18: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 TAA20470; Sun, 29 Jul 2001 19:18:55 -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 SAA01502; Sun, 29 Jul 2001 18:18:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6U1HQR26509 for mobile-ip-dist; Sun, 29 Jul 2001 18:17:26 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6U1HNY26502 for ; Sun, 29 Jul 2001 18:17:23 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA00783 for ; Sun, 29 Jul 2001 18:17:38 -0700 (PDT) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA00870 for ; Sun, 29 Jul 2001 18:17:37 -0700 (PDT) Received: by megisto-sql1.megisto.com with Internet Mail Service (5.5.2650.21) id ; Sun, 29 Jul 2001 21:17:30 -0400 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] my schedule Date: Sun, 29 Jul 2001 21:17:28 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) 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 only going to be reachable through about noon eastern on Wednesday this week and not again until Sunday. So if you need something from me before then please keep this in mind. Phil From owner-mobile-ip@sunroof.eng.sun.com Sun Jul 29 21:21:25 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA08774 for ; Sun, 29 Jul 2001 21:21:25 -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 SAA19456; Sun, 29 Jul 2001 18:22:02 -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 SAA01724; Sun, 29 Jul 2001 18:21:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6U1Ko226580 for mobile-ip-dist; Sun, 29 Jul 2001 18:20:50 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6U1KkY26573 for ; Sun, 29 Jul 2001 18:20:46 -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 SAA00906 for ; Sun, 29 Jul 2001 18:21:01 -0700 (PDT) Received: from tiger.korea.ac.kr (tiger.korea.ac.kr [163.152.209.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA21043 for ; Sun, 29 Jul 2001 19:20:57 -0600 (MDT) Received: from jinwoo ([163.152.155.226]) by tiger.korea.ac.kr (8.11.0/8.11.0) with SMTP id f6U1HkZ37290; Mon, 30 Jul 2001 10:17:46 +0900 Message-ID: <003a01c11896$56171980$e29b98a3@korea> From: =?ks_c_5601-1987?B?waTB+L/s?= To: "mobileIP" Subject: [mobile-ip] I-D ACTION:draft-kahng-rss-mipv4-00.txt Date: Mon, 30 Jul 2001 10:24:10 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0037_01C118E1.C5C4C5C0" 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: This is a multi-part message in MIME format. ------=_NextPart_000_0037_01C118E1.C5C4C5C0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVy bmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4NCiANCiANCiAgVGl0bGUgOiBSZWRpcmVjdCBTdWJuZXQg U3dpdGNoaW5nIGluIE1vYmlsZSBJUHY0DQogQXV0aG9yKHMpIDogSC4gS2FobmcgZXQgYWwuDQog RmlsZW5hbWUgOiBkcmFmdC1rYWhuZy1yc3MtbWlwdjQtMDAudHh0DQogUGFnZXMgOiAxNA0KIERh dGUgOiAyNi1KdWwtMDENCiANCiAgRnJvbSBhIHZpZXdwb2ludCBvZiBhIGxheWVyIGFyY2hpdGVj dHVyZSwgYSBuZXR3b3JrIGxheWVyIHNob3VsZCANCiAgZmVhdHVyZSBhIG1vYmlsaXR5IHN1cHBv cnQuIFRoZW4gdGhlIHVzZXJzIGNhbiBlbmpveSB0aGVpciBtb2JpbGl0eSANCiAgd2hhdGV2ZXIg ZGF0YS1saW5rIGRldmljZXMgYW5kIHVzZXIgYXBwbGljYXRpb25zIHRoZXkgdXNlLiANCiAgTW9i aWxlIElQIGhhcyBiZWVuIHByb3Bvc2VkIGZvciBhIHNvbHV0aW9uIHRvIHByb3ZpZGUgSVAtbGF5 ZXIgDQogIGhhbmRvZmZzIGJldHdlZW4gc3VibmV0cyBzZXJ2ZWQgYnkgZGlmZmVyZW50IEZvcmVp Z24gQWdlbnRzLiBIb3dldmVyLCANCiAgaXQgc3RpbGwgc3VmZmVycyBhbiBpbnRlcnJ1cHRpb24g b2YgdGhlIGNvbW11bmljYXRpb25zIGZvciByZWFsLXRpbWUgDQogIGFwcGxpY2F0aW9ucy4NCiAN CiAgQSBVUkwgZm9yIHRoaXMgSW50ZXJuZXQtRHJhZnQgaXM6DQogIGh0dHA6Ly93d3cuaWV0Zi5v cmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWthaG5nLXJzcy1taXB2NC0wMC50eHQNCiANCiAgSW50 ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQLiBMb2dpbiB3 aXRoIHRoZSB1c2VybmFtZQ0KICAiYW5vbnltb3VzIiBhbmQgYSBwYXNzd29yZCBvZiB5b3VyIGUt bWFpbCBhZGRyZXNzLiBBZnRlciBsb2dnaW5nIGluLA0KICB0eXBlICJjZCBpbnRlcm5ldC1kcmFm dHMiIGFuZCB0aGVuDQogICJnZXQgZHJhZnQta2FobmctcnNzLW1pcHY0LTAwLnR4dCIuDQogIA0K ICBBIGxpc3Qgb2YgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzIGNhbiBiZSBmb3VuZCBpbg0K ICBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sIA0KICBvciBmdHA6Ly9mdHAuaWV0Zi5v cmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dA0KICANCiAgDQogIEludGVybmV0LURyYWZ0cyBjYW4g YWxzbyBiZSBvYnRhaW5lZCBieSBlLW1haWwuDQogIA0KICBTZW5kIGEgbWVzc2FnZSB0bzoNCiAg bWFpbHNlcnZAaWV0Zi5vcmcuDQogIEluIHRoZSBib2R5IHR5cGU6DQogICJGSUxFIC9pbnRlcm5l dC1kcmFmdHMvZHJhZnQta2FobmctcnNzLW1pcHY0LTAwLnR4dCIuDQogIA0KICBOT1RFOiBUaGUg bWFpbCBzZXJ2ZXIgYXQgaWV0Zi5vcmcgY2FuIHJldHVybiB0aGUgZG9jdW1lbnQgaW4NCiAgTUlN RS1lbmNvZGVkIGZvcm0gYnkgdXNpbmcgdGhlICJtcGFjayIgdXRpbGl0eS4gIFRvIHVzZSB0aGlz DQogIGZlYXR1cmUsIGluc2VydCB0aGUgY29tbWFuZCAiRU5DT0RJTkcgbWltZSIgYmVmb3JlIHRo ZSAiRklMRSINCiAgY29tbWFuZC4gIFRvIGRlY29kZSB0aGUgcmVzcG9uc2UocyksIHlvdSB3aWxs IG5lZWQgIm11bnBhY2siIG9yDQogIGEgTUlNRS1jb21wbGlhbnQgbWFpbCByZWFkZXIuICBEaWZm ZXJlbnQgTUlNRS1jb21wbGlhbnQgbWFpbCByZWFkZXJzDQogIGV4aGliaXQgZGlmZmVyZW50IGJl aGF2aW9yLCBlc3BlY2lhbGx5IHdoZW4gZGVhbGluZyB3aXRoDQogICJtdWx0aXBhcnQiIE1JTUUg bWVzc2FnZXMgKGkuZS4gZG9jdW1lbnRzIHdoaWNoIGhhdmUgYmVlbiBzcGxpdA0KICB1cCBpbnRv IG11bHRpcGxlIG1lc3NhZ2VzKSwgc28gY2hlY2sgeW91ciBsb2NhbCBkb2N1bWVudGF0aW9uIG9u DQogIGhvdyB0byBtYW5pcHVsYXRlIHRoZXNlIG1lc3NhZ2VzLg0KICANCiAgQmVsb3cgaXMgdGhl IGRhdGEgd2hpY2ggd2lsbCBlbmFibGUgYSBNSU1FIGNvbXBsaWFudCBtYWlsIHJlYWRlcg0KICBp bXBsZW1lbnRhdGlvbiB0byBhdXRvbWF0aWNhbGx5IHJldHJpZXZlIHRoZSBBU0NJSSB2ZXJzaW9u IG9mIHRoZQ0KICBJbnRlcm5ldC1EcmFmdC4NCiAgDQo= ------=_NextPart_000_0037_01C118E1.C5C4C5C0 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA1LjUwLjQ2MTYuMjAwIiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT48L1NUWUxFPg0KPC9I RUFEPg0KPEJPRFkgYmdDb2xvcj0jZmZmZmZmPg0KPERJVj4mbmJzcDtBIE5ldyBJbnRlcm5ldC1E cmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgDQpkaXJl Y3Rvcmllcy48QlI+Jm5ic3A7PEJSPiZuYnNwOzxCUj4mbmJzcDsgVGl0bGUgOiBSZWRpcmVjdCBT dWJuZXQgU3dpdGNoaW5nIGluIA0KTW9iaWxlIElQdjQ8QlI+Jm5ic3A7QXV0aG9yKHMpIDogSC4g S2FobmcgZXQgYWwuPEJSPiZuYnNwO0ZpbGVuYW1lIDogDQpkcmFmdC1rYWhuZy1yc3MtbWlwdjQt MDAudHh0PEJSPiZuYnNwO1BhZ2VzIDogMTQ8QlI+Jm5ic3A7RGF0ZSA6IA0KMjYtSnVsLTAxPEJS PiZuYnNwOzxCUj4mbmJzcDsgRnJvbSBhIHZpZXdwb2ludCBvZiBhIGxheWVyIGFyY2hpdGVjdHVy ZSwgYSANCm5ldHdvcmsgbGF5ZXIgc2hvdWxkJm5ic3A7PEJSPiZuYnNwOyBmZWF0dXJlIGEgbW9i aWxpdHkgc3VwcG9ydC4gVGhlbiB0aGUgdXNlcnMgDQpjYW4gZW5qb3kgdGhlaXIgbW9iaWxpdHkm bmJzcDs8QlI+Jm5ic3A7IHdoYXRldmVyIGRhdGEtbGluayBkZXZpY2VzIGFuZCB1c2VyIA0KYXBw bGljYXRpb25zIHRoZXkgdXNlLiZuYnNwOzxCUj4mbmJzcDsgTW9iaWxlIElQIGhhcyBiZWVuIHBy b3Bvc2VkIGZvciBhIA0Kc29sdXRpb24gdG8gcHJvdmlkZSBJUC1sYXllciZuYnNwOzxCUj4mbmJz cDsgaGFuZG9mZnMgYmV0d2VlbiBzdWJuZXRzIHNlcnZlZCBieSANCmRpZmZlcmVudCBGb3JlaWdu IEFnZW50cy4gSG93ZXZlciwmbmJzcDs8QlI+Jm5ic3A7IGl0IHN0aWxsIHN1ZmZlcnMgYW4gDQpp bnRlcnJ1cHRpb24gb2YgdGhlIGNvbW11bmljYXRpb25zIGZvciByZWFsLXRpbWUmbmJzcDs8QlI+ Jm5ic3A7IA0KYXBwbGljYXRpb25zLjxCUj4mbmJzcDs8QlI+Jm5ic3A7IEEgVVJMIGZvciB0aGlz IEludGVybmV0LURyYWZ0IGlzOjxCUj48Rk9OVCANCnNpemU9Mj4mbmJzcDs8L0ZPTlQ+Jm5ic3A7 PEEgDQpocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1rYWhu Zy1yc3MtbWlwdjQtMDAudHh0Ij5odHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9k cmFmdC1rYWhuZy1yc3MtbWlwdjQtMDAudHh0PC9BPjxCUj4mbmJzcDs8QlI+Jm5ic3A7IA0KSW50 ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQLiBMb2dpbiB3 aXRoIHRoZSANCnVzZXJuYW1lPEJSPiZuYnNwOyZuYnNwOyJhbm9ueW1vdXMiIGFuZCBhIHBhc3N3 b3JkIG9mIHlvdXIgZS1tYWlsIGFkZHJlc3MuIEFmdGVyIA0KbG9nZ2luZyBpbiw8QlI+Jm5ic3A7 Jm5ic3A7dHlwZSAiY2QgaW50ZXJuZXQtZHJhZnRzIiBhbmQgDQp0aGVuPEJSPiZuYnNwOyZuYnNw OyJnZXQgZHJhZnQta2FobmctcnNzLW1pcHY0LTAwLnR4dCIuPEJSPjxGT05UIA0Kc2l6ZT0yPiZu YnNwOzwvRk9OVD4mbmJzcDs8QlI+PEZPTlQgc2l6ZT0yPiZuYnNwOzwvRk9OVD4gQSBsaXN0IG9m IA0KSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzIGNhbiBiZSBmb3VuZCBpbjxCUj4mbmJzcDsm bmJzcDs8QSANCmhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwiPmh0dHA6Ly93 d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWw8L0E+Jm5ic3A7PEJSPiZuYnNwOyANCm9yIDxBIA0KaHJl Zj0iZnRwOi8vZnRwLmlldGYub3JnL2lldGYvMXNoYWRvdy1zaXRlcy50eHQiPmZ0cDovL2Z0cC5p ZXRmLm9yZy9pZXRmLzFzaGFkb3ctc2l0ZXMudHh0PC9BPjxCUj48Rk9OVCANCnNpemU9Mj4mbmJz cDs8L0ZPTlQ+Jm5ic3A7PEJSPjxGT05UIHNpemU9Mj4mbmJzcDs8L0ZPTlQ+Jm5ic3A7PEJSPjxG T05UIA0Kc2l6ZT0yPiZuYnNwOzwvRk9OVD4gSW50ZXJuZXQtRHJhZnRzIGNhbiBhbHNvIGJlIG9i dGFpbmVkIGJ5IGUtbWFpbC48QlI+PEZPTlQgDQpzaXplPTI+Jm5ic3A7PC9GT05UPiZuYnNwOzxC Uj48Rk9OVCBzaXplPTI+Jm5ic3A7PC9GT05UPiBTZW5kIGEgbWVzc2FnZSANCnRvOjxCUj4mbmJz cDsmbmJzcDs8QSANCmhyZWY9Im1haWx0bzptYWlsc2VydkBpZXRmLm9yZyI+bWFpbHNlcnZAaWV0 Zi5vcmc8L0E+LjxCUj4mbmJzcDsmbmJzcDtJbiB0aGUgDQpib2R5IHR5cGU6PEJSPiZuYnNwOyZu YnNwOyJGSUxFIA0KL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1rYWhuZy1yc3MtbWlwdjQtMDAudHh0 Ii48QlI+PEZPTlQgDQpzaXplPTI+Jm5ic3A7PC9GT05UPiZuYnNwOzxCUj48Rk9OVCBzaXplPTI+ Jm5ic3A7PC9GT05UPiBOT1RFOiBUaGUgbWFpbCBzZXJ2ZXIgDQphdCBpZXRmLm9yZyBjYW4gcmV0 dXJuIHRoZSBkb2N1bWVudCBpbjxCUj4mbmJzcDsmbmJzcDtNSU1FLWVuY29kZWQgZm9ybSBieSB1 c2luZyANCnRoZSAibXBhY2siIHV0aWxpdHkuJm5ic3A7IFRvIHVzZSB0aGlzPEJSPiZuYnNwOyZu YnNwO2ZlYXR1cmUsIGluc2VydCB0aGUgDQpjb21tYW5kICJFTkNPRElORyBtaW1lIiBiZWZvcmUg dGhlICJGSUxFIjxCUj4mbmJzcDsmbmJzcDtjb21tYW5kLiZuYnNwOyBUbyANCmRlY29kZSB0aGUg cmVzcG9uc2UocyksIHlvdSB3aWxsIG5lZWQgIm11bnBhY2siIG9yPEJSPiZuYnNwOyZuYnNwO2Eg DQpNSU1FLWNvbXBsaWFudCBtYWlsIHJlYWRlci4mbmJzcDsgRGlmZmVyZW50IE1JTUUtY29tcGxp YW50IG1haWwgDQpyZWFkZXJzPEJSPiZuYnNwOyZuYnNwO2V4aGliaXQgZGlmZmVyZW50IGJlaGF2 aW9yLCBlc3BlY2lhbGx5IHdoZW4gZGVhbGluZyANCndpdGg8QlI+Jm5ic3A7Jm5ic3A7Im11bHRp cGFydCIgTUlNRSBtZXNzYWdlcyAoaS5lLiBkb2N1bWVudHMgd2hpY2ggaGF2ZSBiZWVuIA0Kc3Bs aXQ8QlI+Jm5ic3A7Jm5ic3A7dXAgaW50byBtdWx0aXBsZSBtZXNzYWdlcyksIHNvIGNoZWNrIHlv dXIgbG9jYWwgDQpkb2N1bWVudGF0aW9uIG9uPEJSPiZuYnNwOyZuYnNwO2hvdyB0byBtYW5pcHVs YXRlIHRoZXNlIG1lc3NhZ2VzLjxCUj48Rk9OVCANCnNpemU9Mj4mbmJzcDs8L0ZPTlQ+Jm5ic3A7 PEJSPjxGT05UIHNpemU9Mj4mbmJzcDs8L0ZPTlQ+IEJlbG93IGlzIHRoZSBkYXRhIHdoaWNoIA0K d2lsbCBlbmFibGUgYSBNSU1FIGNvbXBsaWFudCBtYWlsIHJlYWRlcjxCUj4mbmJzcDsmbmJzcDtp bXBsZW1lbnRhdGlvbiB0byANCmF1dG9tYXRpY2FsbHkgcmV0cmlldmUgdGhlIEFTQ0lJIHZlcnNp b24gb2YgDQp0aGU8QlI+Jm5ic3A7Jm5ic3A7SW50ZXJuZXQtRHJhZnQuPEJSPjxGT05UIA0Kc2l6 ZT0yPiZuYnNwOzwvRk9OVD4mbmJzcDs8L0RJVj48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_0037_01C118E1.C5C4C5C0-- From owner-mobile-ip@sunroof.eng.sun.com Sun Jul 29 21:55:55 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA10541 for ; Sun, 29 Jul 2001 21:55: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 SAA24893; Sun, 29 Jul 2001 18:56: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 SAA03342; Sun, 29 Jul 2001 18:56:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6U1sPb26756 for mobile-ip-dist; Sun, 29 Jul 2001 18:54:25 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6U1sMY26749 for ; Sun, 29 Jul 2001 18:54:22 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA02494 for ; Sun, 29 Jul 2001 18:54:37 -0700 (PDT) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA07602 for ; Sun, 29 Jul 2001 18:54:37 -0700 (PDT) Received: by megisto-sql1.megisto.com with Internet Mail Service (5.5.2650.21) id ; Sun, 29 Jul 2001 21:54:30 -0400 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] comments on low latency handoff draft Date: Sun, 29 Jul 2001 21:54:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) 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: Hi, here are some more general comments on the draft. The draft assumes that the L2 will be able to provide information that says a handoff is about to occur, but no concrete information about when it has occured. I find this a little odd. Are there some concrete examples of L2 technology someone could point to like this? A lot of what's in this draft seems to rest on this second assumption. It justifies the need for bicasting in the POST REG method. On page 5, it says that "[t]he registration process takes some non-zero time to complete as the Registration Requests propagate through the network. During this period of time the MN is not able to send or receive IP packets." I don't follow this. It should be able to send if it is connected and possibly receive though not at its home address. In table 1 is it useful to include a trigger for a link down status? (IE. I just told the mobile to go somewhere else so you can't reach it via this link anymore). On page 9 "no dependence on a wireless L2 technology," should probably be clarified in the light of the presence of various L2 triggers the protocols make use of. On page 10 (pedantic) s/order to not delay/order not to delay/ On page 11. I don't understand what's being said in paragraph 3. "The MN performs movement detection upon receipt of either a solicited or unsolicited RA,...." By movement detection I gather from the rest of the explanation that it is "possible upcoming movement detection?" How does a mobile node MIP client know it has actually moved? On page 15. "the trigger timing SHOULD be arranged such that a full L3 ...." Hmmm. This seems like a curious requirement. This seems more like an assumption about the underlying technology. How can we specify in *this* document how an L2 should be engineered? On page 17 "... are also useful to support ping-ponging." should probably be reworded. Perhaps "... are also useful to support proper L3 operation in the presence of ping-pong behavior at L2?" On page 23 Perhaps it would be possible to elaborate on some of the specifics to smooth the behavior in the presence of ping-ponging? I'm assuming the nFA gets some traffic and finds out somehow that the mobile is back on the oFA and starts sending it back? On page 23 s/egress/ingress/ On page 26 "The MN MAY ... establish a link-layer connection with the MN." I suspect one of these MNs should be something else. On page 26 "The oFA SHOULD stop bicasting ...." Why SHOULD rather than MUST? On page 31 would it be helpful to have a reference in the IMSI extension to where one could get info on IMSIs and connection ids. Does the length of this extension include the subtype field as in the other extensions? Anybody got any patents that they need to tell us about? Phil From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 30 02:19:02 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA03954 for ; Mon, 30 Jul 2001 02:19:01 -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 AAA20727; Mon, 30 Jul 2001 00: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 XAA18766; Sun, 29 Jul 2001 23:18:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6U6GjO27230 for mobile-ip-dist; Sun, 29 Jul 2001 23:16:45 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6U6GfY27223 for ; Sun, 29 Jul 2001 23:16:41 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA19982 for ; Sun, 29 Jul 2001 23:16:57 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA29869 for ; Sun, 29 Jul 2001 23:16:56 -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 XAA02487; Sun, 29 Jul 2001 23:16:21 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6U6GGp24712; Sun, 29 Jul 2001 23:16:16 -0700 X-mProtect: Sun, 29 Jul 2001 23:16:16 -0700 Nokia Silicon Valley Messaging Protection Received: from maxdialin11.iprg.nokia.com (205.226.20.241, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdqqsaaU; Sun, 29 Jul 2001 23:16:14 PDT Message-ID: <3B64FBCC.C437405A@iprg.nokia.com> Date: Sun, 29 Jul 2001 23:16:45 -0700 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: jlau@cup.hp.com CC: mobile-ip@sunroof.eng.sun.com, pcalhoun@diameter.org Subject: Re: [mobile-ip] Generalized MN-HA and MN-FAKey Reply Extension References: <200107291940.MAA28069@strtio1.cup.hp.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 Joe, These are generalized key extensions. Subtypes will define more data fields. There is a good argument that some specific key subtypes of the MN-FA Key Reply extension will NOT have a lifetime, because the key will have the same lifetime as the Mobile IP registration lifetime. In fact, one could argue that this would be the preferred mode of operation for the security association between the mobile node and the foreign agent. The security association between mobile node and home agent is clearly different, and the lifetime of that association would not typically be controlled by registration factors. Since every security associatoin has to have a lifetime, and there isn't any likely implicit lifetime, it would be present for every subtype, and thus belongs in the generalized extension. At least that's my understanding! Regards, Charlie P. Regards, Charlie P. Joe Lau wrote: > Hello Charlie and Pat, > > On your latest draft , > I am puzzled over the asymmetry between the MN-HA Key Reply Extension > and the MN-FA Key Reply Extension. The former has a lifetime field > but the latter does not. I understand that the lifetime of the > MN-FA Key will come from the Unsolicited MN-FA Key Material From AAA Subtype. > > But I don't understand why these two keys have to be treated differently > as far as how the lifetime is placed. > > Thanks in advance for your clarification. > > Regards, > > Joe Lau From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 30 04:54:08 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA09280 for ; Mon, 30 Jul 2001 04:54:07 -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 BAA16342; Mon, 30 Jul 2001 01:53:29 -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 BAA28972; Mon, 30 Jul 2001 01:51:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6U8nvl27431 for mobile-ip-dist; Mon, 30 Jul 2001 01:49:57 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6U8nrY27424 for ; Mon, 30 Jul 2001 01:49:53 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA28919 for ; Mon, 30 Jul 2001 01:50:08 -0700 (PDT) Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA25860 for ; Mon, 30 Jul 2001 01:50:06 -0700 (PDT) Received: from fredrikj (sierra.local.ipunplugged.com [192.168.4.88]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with SMTP id KAA32286; Mon, 30 Jul 2001 10:51:40 +0200 From: "Fredrik Johansson" To: , "Charlie Perkins" Cc: "Pat Calhoun" Subject: RE: [mobile-ip] Re: mobile-ip] WG last call: draft-ietf-mobileip-gen-key-00.txt Date: Mon, 30 Jul 2001 10:51:33 +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) Importance: Normal In-Reply-To: <3B61D37F.A75CF9B4@iprg.nokia.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 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, Thanks for getting this draft ready for last call. I've just a few comments that I unfortunately missed before. in section 2.0 and 4.0 It's stated that the mobile node SPI is the SPI that will be assigned for the security association. Shouldn't it rather be a hint to what SPI the mobile node would like to assign for the security association? i.e. Mobile Node SPI The Security Parameter Index provided by the mobile node as a hint to which SPI it would like to assign for the security association created for use with the registration key. Section 3.0 and 5.0 The MN-FA/MN-HA Key Reply Subtype Data shouldn't be an encrypted copy of the key to be used as some subtypes doesn't send the actual key but a key material instead. "Subtype data, e.g. key material, to be used between the mobile node and its home/foreign agent, along with any other information needed by the mobile node to create the designated Mobility Security Association with the home/foreign agent. Section 7.0 Is there a reason to why the FA-FA key reply extension contains a SPI when it's left out from the other reply extensions? Or can it be left to the subtype as in the other reply extensions? thanks /Fredrik >-----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: den 27 juli 2001 22:48 >To: Madhavi W. Chandra >Cc: Mobile IP Working Group; Pat Calhoun >Subject: Re: [mobile-ip] Re: mobile-ip] WG last call: >draft-ietf-mobileip-gen-key-00.txt > > > >Hello folks, > >I submitted a version of the genkey draft, but I turned off my laptop >before the mail had gone out and so I missed last week's deadline. >It turns out that I had forgotten to cite RFC 2119 anyway, and so >it might have been rejected by the IESG. I have re-revised the draft, >and I will resubmit it at the next opportunity. > >The new draft is available at: > http://people.nokia.net/charliep/txt/genkey/genkey.txt > >Here are some additional comments. > > >"Madhavi W. Chandra" wrote: >> >> Hi Charlie and Pat, >> >> We've just started following this draft and are trying to grasp its >> intent. We have a few questions/comments: >> >> 1. Since it is not specified, can the 'Reply' Key extensions be >> appended to both RPYs and RRQs? > >As Pat noted, there should be restrictions. I have added text >to that effect near the end of the Introduction. > >> 2. Section 7, 'FA-FA Key Reply Subtype Data' sounds like a >> description for MN-HA Reply. > >Fixed. > >> 7. We would like a mobility agent, say MA-1, to pass key to MA-2 for >> MA-2 to use with MN. If MAs are FAs, then probably the FA-FA Key >> Reply Extension would be used...appended to what MIP message? What if >> the MAs are HAs? > >I agree with Pat's comments about hierarchical FAs being the >motivation for this extension, which seems to belong here. >For the case of home agents, no one ever made such a request, >and I haven't seen any protocol that would use such a thing as >part of any Mobile IPv4 registration message. Even though it's >a bit late, it's not completely impossible to add such a feature. >However, I reckon the burden of proof would be on you to make >the case. > > >Regards, >Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 30 07:36:16 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA17454 for ; Mon, 30 Jul 2001 07:36:16 -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 EAA28539; Mon, 30 Jul 2001 04:36: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 EAA10406; Mon, 30 Jul 2001 04:36:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6UBZEB27749 for mobile-ip-dist; Mon, 30 Jul 2001 04:35:14 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6UBZAY27742 for ; Mon, 30 Jul 2001 04:35:11 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA28465 for ; Mon, 30 Jul 2001 04:35:24 -0700 (PDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA24801 for ; Mon, 30 Jul 2001 04:35:24 -0700 (PDT) Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f6UBZMO19753 for ; Mon, 30 Jul 2001 13:35:22 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Mon Jul 30 13:35:22 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Mon, 30 Jul 2001 13:35:21 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008B7D@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Handover Smoothing - What to Do? Date: Mon, 30 Jul 2001 13:35:13 +0200 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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hello Rajeev, > > There are so many mails I hope no one else made the same > > comments that I'm about to make. > > > > > I don't understand your viewpoint. Just because you have not heard from > > > buffering advocates does not imply that the alternative is the way to go. There > > > are at least two things to consider. First, you are proposing to add a > > > particular smoothing technique to FMIPv6. I am registering my complaint saying > > > that it is not the right thing to do. > > > > > => You're making a statement that is not backed by a reason. See more below. > > > > > > On the contrary, I was reasoning that when FMIP can progress without having to rely on > any particular smoothing technique. > => See an answer below. > > > FMIPv6 must be able to work independently > > > of bicasting. > > > > > => Why ? > > > > > > Why not ? FMIP can work without any dependency. > => It _does_not. The draft clearly states that there are cases (like ping pong) where the current solution does not work. We've said this many times and it's in the FMIPv6 draft. > Besides, the smoothing techniques by > themselves are not well-understood to be part of a standard. I mentioned this (in the > same thread somewhere) didn't I ? > => This is handwaving, I'd prefer if you point out specific issues. I don't think HC and CT has any role here. Bicasting adds nothing to the complexity of the HC CT (which is already very complex and of unproven value as it is). We can't build a solution taking into consideration a solution that does not exist or even agreed on. > > > > > Second, taking up smoothing as a > > > topic by itself, it is not a foregone conclusion that bicasting/simultaneous > > > binding are the only means. This is an open area and we need discussion and > > > *real experimental* evidence. Also, the header compression example hold here as > > > well. > > > > > => Well other proposals are also welcome. But I'm sure you can appreciate > > that new ideas come up all the time, that doesn't mean we don't make > > any decisions. We have to decide on what we have now. Unless you've > > done some experiments on bicasting and saw that it's bad for some > > reason. > > > > We are now talking about handling smoothing techniques on their own. > As I mentioned above, this topic by itself needs a lot of discussion before we can make > decisions. I am not convinced that we can draw definitive conclusions on smoothing > techniques to progress them on a standardization path. > => Frnkly I'm not interested in the discussion of documents and which doc contains what. I'm more interested in the technical evaluation of a proposal. It seems like people are avoiding this topic. Regards, Hesham From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 30 09:29:12 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA21346 for ; Mon, 30 Jul 2001 09:29:12 -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 GAA01892; Mon, 30 Jul 2001 06:29: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 GAA19960; Mon, 30 Jul 2001 06:29:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6UDS3228097 for mobile-ip-dist; Mon, 30 Jul 2001 06:28:03 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6UDS0Y28090 for ; Mon, 30 Jul 2001 06:28:00 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA19830 for ; Mon, 30 Jul 2001 06:28:15 -0700 (PDT) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA07126 for ; Mon, 30 Jul 2001 06:28:12 -0700 (PDT) Received: by megisto-sql1.megisto.com with Internet Mail Service (5.5.2650.21) id ; Mon, 30 Jul 2001 09:28:04 -0400 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Handover Smoothing - What to Do? Date: Mon, 30 Jul 2001 09:28:01 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) 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, We've made a distinction in our discussions all along between fast and smooth. To say that the fast handover proposals "don't work" because they are not smooth seems to be confusing these two issues. I outlined some cases in an earlier mail in which bicasting could be used but the handover not be smooth. Bicasting makes it possible that both (or all) FAs (or ARs) receive a copy of the packet with the hope they can do something meaningful with them to make the handover smooth. This is commendable, but perhaps something better could be attained. So it seems worthwhile to separate fast and smooth in our work. I think we've got the fast part fairly well handled. Phil > -----Original Message----- > From: Hesham Soliman (ERA) [mailto:Hesham.Soliman@era.ericsson.se] > Sent: Monday, July 30, 2001 7:35 AM > To: 'mobile-ip@sunroof.eng.sun.com' > Subject: RE: [mobile-ip] Handover Smoothing - What to Do? > > > Hello Rajeev, > > > > There are so many mails I hope no one else made the same > > > comments that I'm about to make. > > > > > > > I don't understand your viewpoint. Just because you > have not heard from > > > > buffering advocates does not imply that the alternative > is the way to go. There > > > > are at least two things to consider. First, you are > proposing to add a > > > > particular smoothing technique to FMIPv6. I am > registering my complaint saying > > > > that it is not the right thing to do. > > > > > > > => You're making a statement that is not backed > by a reason. See more below. > > > > > > > > > > On the contrary, I was reasoning that when FMIP can > progress without having to rely on > > any particular smoothing technique. > > > => See an answer below. > > > > > > FMIPv6 must be able to work independently > > > > of bicasting. > > > > > > > => Why ? > > > > > > > > > > Why not ? FMIP can work without any dependency. > > > => It _does_not. The draft clearly states that there > are cases (like ping pong) > where the current solution does not work. We've said this many > times and it's in the FMIPv6 draft. > > > Besides, the smoothing techniques by > > themselves are not well-understood to be part of a > standard. I mentioned this (in the > > same thread somewhere) didn't I ? > > > => This is handwaving, I'd prefer if you point out > specific issues. > I don't think HC and CT has any role here. Bicasting > adds nothing > to the complexity of the HC CT (which is already very complex > and of unproven value as it is). We can't build a > solution taking into > consideration a solution that does not exist or even agreed on. > > > > > > > > Second, taking up smoothing as a > > > > topic by itself, it is not a foregone conclusion that > bicasting/simultaneous > > > > binding are the only means. This is an open area and we > need discussion and > > > > *real experimental* evidence. Also, the header > compression example hold here as > > > > well. > > > > > > > => Well other proposals are also welcome. But I'm > sure you can appreciate > > > that new ideas come up all the time, that doesn't > mean we don't make > > > any decisions. We have to decide on what we have > now. Unless you've > > > done some experiments on bicasting and saw that > it's bad for some > > > reason. > > > > > > > We are now talking about handling smoothing techniques on their own. > > As I mentioned above, this topic by itself needs a lot of > discussion before we can make > > decisions. I am not convinced that we can draw definitive > conclusions on smoothing > > techniques to progress them on a standardization path. > > > => Frnkly I'm not interested in the discussion of documents and > which doc contains what. I'm more interested in the technical > evaluation of a proposal. It seems like people are avoiding > this topic. > > Regards, > Hesham > From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 30 09:57:43 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA22372 for ; Mon, 30 Jul 2001 09:57:42 -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 GAA12700; Mon, 30 Jul 2001 06:57: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 GAA23552; Mon, 30 Jul 2001 06:57:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6UDtbP28254 for mobile-ip-dist; Mon, 30 Jul 2001 06:55:37 -0700 (PDT) Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6UDtXY28247 for ; Mon, 30 Jul 2001 06:55:33 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f6UDtk218499 for ; Mon, 30 Jul 2001 15:55:46 +0200 (MET DST) Date: Mon, 30 Jul 2001 15:53:38 +0200 (CEST) From: Erik Nordmark Subject: Re: [mobile-ip] Analysis of Latency Propagation with Buffering To: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <200107272118.OAA25125@heliopolis.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: > R = T(0)/(1 - (A/B)) Jim, You seem to have computed the total time until the buffering and downloading of the buffer process is running. This is longer than the maximum delay that buffering adds to any packet. In fact, isn't the max delay added just T(0) for the first packet that was buffered. Then subsequent packets see a linearly decreasing addional delay until R time units have passed. Erik From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 30 10:12:49 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA23279 for ; Mon, 30 Jul 2001 10:12:48 -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 IAA04683; Mon, 30 Jul 2001 08:12: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 HAA27217; Mon, 30 Jul 2001 07:12:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6UEBUT28387 for mobile-ip-dist; Mon, 30 Jul 2001 07:11:30 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6UEBQY28380 for ; Mon, 30 Jul 2001 07:11:26 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA26718 for ; Mon, 30 Jul 2001 07:11:40 -0700 (PDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id HAA29028 for ; Mon, 30 Jul 2001 07:11:39 -0700 (PDT) Received: (qmail 4075 invoked by uid 500); 30 Jul 2001 14:00:23 -0000 Date: Mon, 30 Jul 2001 07:00:23 -0700 From: Pat Calhoun To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Handover Smoothing - What to Do? Message-ID: <20010730070023.E4017@charizard.diameter.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from PRoberts@MEGISTO.com on Sun, Jul 29, 2001 at 09:06:29PM -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: > So what's my position on this? It seems that there are fairly obvious > cases in which bicasting introduces packet duplicates with potentially > unknown > effects in the network. It doesn't seem the network agents will have the > information needed to prevent this from happening. Just for clarification, duplicate packets already occur in the network. So, why is the possibility of creating duplicates at the edges, during a handoff - which is infrequent - now become a real problem, when they already occur in the network without handoffs? PatC From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 30 10:20:32 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA23698 for ; Mon, 30 Jul 2001 10:20:31 -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 IAA10109; Mon, 30 Jul 2001 08:20: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 HAA28769; Mon, 30 Jul 2001 07:20:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6UEJ0E28501 for mobile-ip-dist; Mon, 30 Jul 2001 07:19:00 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6UEIvY28494 for ; Mon, 30 Jul 2001 07:18:57 -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 HAA27602 for ; Mon, 30 Jul 2001 07:18:50 -0700 (PDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id IAA09019 for ; Mon, 30 Jul 2001 08:18:48 -0600 (MDT) Received: (qmail 4181 invoked by uid 500); 30 Jul 2001 14:07:33 -0000 Date: Mon, 30 Jul 2001 07:07:33 -0700 From: Pat Calhoun To: Charlie Perkins Cc: jlau@cup.hp.com, mobile-ip@sunroof.eng.sun.com, pcalhoun@diameter.org Subject: Re: [mobile-ip] Generalized MN-HA and MN-FAKey Reply Extension Message-ID: <20010730070733.H4017@charizard.diameter.org> References: <200107291940.MAA28069@strtio1.cup.hp.com> <3B64FBCC.C437405A@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: <3B64FBCC.C437405A@iprg.nokia.com>; from charliep@IPRG.nokia.com on Sun, Jul 29, 2001 at 11:16:45PM -0700 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: Joe, Also you will notice that the MN-FA AAA subtype does include the missing lifetime. So, in the AAA case, both the MN-HA and the MN-FA have lifetimes. PatC On Sun, Jul 29, 2001 at 11:16:45PM -0700, Charlie Perkins wrote: > > Hello Joe, > > These are generalized key extensions. Subtypes will define more > data fields. There is a good argument that some specific key > subtypes of the MN-FA Key Reply extension will NOT have > a lifetime, because the key will have the same lifetime as the > Mobile IP registration lifetime. In fact, one could argue that > this would be the preferred mode of operation for the security > association between the mobile node and the foreign agent. > > The security association between mobile node and home > agent is clearly different, and the lifetime of that association > would not typically be controlled by registration factors. > Since every security associatoin has to have a lifetime, and > there isn't any likely implicit lifetime, it would be present for > every subtype, and thus belongs in the generalized extension. > > At least that's my understanding! > > Regards, > Charlie P. > > > Regards, > Charlie P. > > > > Joe Lau wrote: > > > Hello Charlie and Pat, > > > > On your latest draft , > > I am puzzled over the asymmetry between the MN-HA Key Reply Extension > > and the MN-FA Key Reply Extension. The former has a lifetime field > > but the latter does not. I understand that the lifetime of the > > MN-FA Key will come from the Unsolicited MN-FA Key Material From AAA Subtype. > > > > But I don't understand why these two keys have to be treated differently > > as far as how the lifetime is placed. > > > > Thanks in advance for your clarification. > > > > Regards, > > > > Joe Lau > From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 30 10:21:10 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA23774 for ; Mon, 30 Jul 2001 10:21:10 -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 HAA21947; Mon, 30 Jul 2001 07:20: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 HAA28788; Mon, 30 Jul 2001 07:20:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6UEJ5Y28510 for mobile-ip-dist; Mon, 30 Jul 2001 07:19:05 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6UEJ0Y28503 for ; Mon, 30 Jul 2001 07:19:01 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA05316 for ; Mon, 30 Jul 2001 07:19:04 -0700 (PDT) Received: from RRMAIL01.RADIOROUTER_NT ([63.103.94.23]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA22990 for ; Mon, 30 Jul 2001 07:19:02 -0700 (PDT) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Mon, 30 Jul 2001 10:19:01 -0400 Message-ID: <8C92E23A3E87FB479988285F9E22BE460546DC@ftmail> From: George Tsirtsis To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Handover Smoothing - What to Do? Date: Mon, 30 Jul 2001 10:18:58 -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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Pat, Maybe you have missed this...please see my response to Mike on the same question... I feel like a broken record by there you go :-0 George P.S: in your question...what is "infrequent"??? the handoff? I do not think so.... -----Original Message----- From: George Tsirtsis [mailto:G.Tsirtsis@flarion.com] Sent: Thursday, July 26, 2001 7:06 PM To: 'mobile-ip@sunroof.eng.sun.com' Subject: RE: [mobile-ip] Analysis of Jitter in Bicasting Hi Mike, I think you are making the point that - end hosts already deal with duplicate packets since this is a natural occurrence in the Internet today so bicasting should not be a problem - The difference is that end nodes deal with duplicate packets up to a point...i.e.: up to 3 re-orderings/losses etc generating 3 dupacks in a row, before TCP starts having problems. The fact that TCP deals with 3 dupacks and not with 5 or 10 or 100 was an engineering choice that balances adaptivity and throughput with the chances of this happening in the Internet or they just picked a number from thin air...wouldn't know...was not here :-) My argument is that bicasting, increases the chances of duplication on top of what the Internet naturally does and that could have bad effects if in widespread use. Say for example, due to natural re-ordering somewhere in the Internet, a node is about to receive 2 TCP acks, which TCP can actually deal with no problems. At the same time the MN's packets are duplicated (due to bicasting) at the receiving end, which results in the MN receiving 4 TCP acks! This forces TCP to half its window thinking that there must be congestion in the network and the packets do not get across which is clearly not the case! So, the objections here are not about being able to "deal" with re-ordering as it naturally occurs but that we should not introduce mechanisms that artificially increase the chance duplicate acks. Regards George -----Original Message----- From: Michael Thomas [mailto:mat@cisco.com] Sent: Thursday, July 26, 2001 6:34 PM To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Analysis of Jitter in Bicasting Gary Kenward writes: > > From: James Kempf [mailto:James.Kempf@Sun.COM] > > In the case of 1, the probability of a duplicate packet has nothing > > whatsoever to do with the radio link. It is purely a matter of traffic > > engineering in the wired network. So the probability of a duplicate > > packet can be reduced by properly engineering the wired network. In > > addition, the probability is likely to increase with the topological > > distance between the new AR and the source of the bicast (simply > > because, the more network a packet has to traverse, the more likely > > it is that a congestion event may cause delay). Since engineering > > of the wired network is largely under the network operator's control, > > this problem is fairly straightforward to solve, though it may > > require measures such as over provisioning. > > Well, it takes more then over provisioning. You need to ensure > the same number of hops between the bicasting source (the traffic > bifurcation > point if you will), and you also need to provide some guaranteed bounds on > the delay at each hop after the bicasting source. *if* you want to ensure no > duplicates > at all at the receiver. This may seem like a definition of EF, but > consider that the constraint is much more severe then that of EF. With > EF the bound is on inter-packet delay and delay jitter for a single stream. > With bicasting, the bound is on the arrival delay of two copies of the > same packet that traverse different paths through N hops. The maximum > delay difference, I believe, is one packet duration, T. Thus, the delay > difference bound at each hop must roughly be T/N (the relationship is > not linear, but this gives a rough approximation). If the source of > the delay is from queuing, then this would imply that there can be > no other traffic following the same path. E.g. if a bicasted packet > arrives at an AR and is queued behind a packet that is being served > (note: served, not queued), from a different packet stream, then > it receives a delay of roughly T/2. I am very, very confused by all of this. Bicasting at the IP layer would merely result in duplicates which the transport/application layer would need to deal with. In fact, it already needs to deal with dups because IP packets are fairly regularly duplicated anyway. While it may require some specific tweaks to TCP (which I assume EIFEL attempts to provide), I see no reason why one would want to shield the receiver from this in the network, nor do I see any reason why it requires a difference in the per hop behavior in the tunneled traffic to AR new, or any consideration of number of hops, etc. The beauty of the end to end principal is that the receiver just adapts *regardless* of where the source of the jitter/loss/duplication/etc came from. Trying to deal with jitter hop-by-hop is akin to the general X.25 approach to transport which is if nothing else against the general IP philosphy of end to end transport. More pragmatically, dealing with jitter in the network will almost certainly yield a worse end to end delay as a single jitter buffer on the receiver. Mike -----Original Message----- From: Pat Calhoun [mailto:pcalhoun@diameter.org] Sent: Monday, July 30, 2001 3:00 PM To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Handover Smoothing - What to Do? > So what's my position on this? It seems that there are fairly obvious > cases in which bicasting introduces packet duplicates with potentially > unknown > effects in the network. It doesn't seem the network agents will have the > information needed to prevent this from happening. Just for clarification, duplicate packets already occur in the network. So, why is the possibility of creating duplicates at the edges, during a handoff - which is infrequent - now become a real problem, when they already occur in the network without handoffs? PatC From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 30 10:25:56 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA24022 for ; Mon, 30 Jul 2001 10:25:55 -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 HAA24429; Mon, 30 Jul 2001 07:25: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 HAA00007; Mon, 30 Jul 2001 07:25:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6UENgi28640 for mobile-ip-dist; Mon, 30 Jul 2001 07:23:42 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6UENdY28633 for ; Mon, 30 Jul 2001 07:23:39 -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 HAA14244 for ; Mon, 30 Jul 2001 07:23:52 -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 IAA12943 for ; Mon, 30 Jul 2001 08:23:50 -0600 (MDT) Received: by megisto-sql1.megisto.com with Internet Mail Service (5.5.2650.21) id ; Mon, 30 Jul 2001 10:23:44 -0400 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Handover Smoothing - What to Do? Date: Mon, 30 Jul 2001 10:23:35 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) 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: > > So what's my position on this? It seems that there are > fairly obvious > > cases in which bicasting introduces packet duplicates with > potentially > > unknown > > effects in the network. It doesn't seem the network agents > will have the > > information needed to prevent this from happening. > > Just for clarification, duplicate packets already occur in > the network. > > So, why is the possibility of creating duplicates at the > edges, during a > handoff - which is infrequent - now become a real problem, when they > already occur in the network without handoffs? I'm not sure what sort of problem it is, but would like to know. I'm somewhat concerned about putting forth a proposal that does cause this sometimes. It seems like it would be worthwhile to determine whether there is another way to perform smooth handovers that doesn't create duplicates. > > PatC > Phil From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 30 10:26:55 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA24053 for ; Mon, 30 Jul 2001 10:26:55 -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 IAA15135; Mon, 30 Jul 2001 08:26: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 HAA00315; Mon, 30 Jul 2001 07:26:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6UEPW328662 for mobile-ip-dist; Mon, 30 Jul 2001 07:25:32 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6UEPSY28655 for ; Mon, 30 Jul 2001 07:25:28 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA28456 for ; Mon, 30 Jul 2001 07:25:31 -0700 (PDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id HAA25731 for ; Mon, 30 Jul 2001 07:25:31 -0700 (PDT) Received: (qmail 4273 invoked by uid 500); 30 Jul 2001 14:14:15 -0000 Date: Mon, 30 Jul 2001 07:14:15 -0700 From: Pat Calhoun To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Handover Smoothing - What to Do? Message-ID: <20010730071415.K4017@charizard.diameter.org> References: <8C92E23A3E87FB479988285F9E22BE460546DC@ftmail> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <8C92E23A3E87FB479988285F9E22BE460546DC@ftmail>; from G.Tsirtsis@flarion.com on Mon, Jul 30, 2001 at 10:18:58AM -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: On Mon, Jul 30, 2001 at 10:18:58AM -0400, George Tsirtsis wrote: > Maybe you have missed this...please see my response to Mike on the same > question... > I feel like a broken record by there you go :-0 but your response is in regards to a problem that is being fixed. Should we stop all development until the fix has an RFC number? I don't think so. Folks that want to build mobile devices will include this fix. Folks running general purpose OSes that don't include the fix can complain to their OS supplier. > P.S: in your question...what is "infrequent"??? the handoff? I do not think > so.... Relative to staying within a cell, yes, but I suppose with pico cells that's not the case. In any case, I'm not saying let's design a protocol assuming the mobile doesn't handoff often, in case that's what you thought I meant :) PatC From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 30 10:36:27 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA24578 for ; Mon, 30 Jul 2001 10:36:27 -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 HAA29455; Mon, 30 Jul 2001 07:36:31 -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 HAA07247; Mon, 30 Jul 2001 07:35:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6UEY4T28795 for mobile-ip-dist; Mon, 30 Jul 2001 07:34:05 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6UEY1Y28788 for ; Mon, 30 Jul 2001 07:34:01 -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 HAA07158 for ; Mon, 30 Jul 2001 07:34:14 -0700 (PDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id IAA20930 for ; Mon, 30 Jul 2001 08:34:12 -0600 (MDT) Received: (qmail 4378 invoked by uid 500); 30 Jul 2001 14:22:58 -0000 Date: Mon, 30 Jul 2001 07:22:58 -0700 From: Pat Calhoun To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Handover Smoothing - What to Do? Message-ID: <20010730072258.N4017@charizard.diameter.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from PRoberts@MEGISTO.com on Mon, Jul 30, 2001 at 10:23:35AM -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: On Mon, Jul 30, 2001 at 10:23:35AM -0400, Phil Roberts wrote: > I'm not sure what sort of problem it is, but would like to know. I'm > somewhat concerned about putting forth a proposal that does cause this > sometimes. It seems like it would be worthwhile to determine whether there > is another way to perform smooth handovers that doesn't create duplicates. And just to be clear, the mobile wouldn't automatically receive several copies all the time. There is a fairly small window where the mobile could end up receiving dups. PatC From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 30 10:41:01 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA24935 for ; Mon, 30 Jul 2001 10:41: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 HAA01650; Mon, 30 Jul 2001 07:40:55 -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 HAA07875; Mon, 30 Jul 2001 07:38:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6UEbLM28860 for mobile-ip-dist; Mon, 30 Jul 2001 07:37:21 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6UEbIY28853 for ; Mon, 30 Jul 2001 07:37:18 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA02931 for ; Mon, 30 Jul 2001 07:37:31 -0700 (PDT) Received: from RRMAIL01.RADIOROUTER_NT ([63.103.94.23]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA12555 for ; Mon, 30 Jul 2001 07:37:30 -0700 (PDT) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Mon, 30 Jul 2001 10:37:30 -0400 Message-ID: <8C92E23A3E87FB479988285F9E22BE460546DD@ftmail> From: George Tsirtsis To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Handover Smoothing - What to Do? Date: Mon, 30 Jul 2001 10:37:22 -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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: So you did not miss it :) Pat, I never said stop all development, if that is what you thought I meant :)...I only said that specs should be clear about problems that a technology might cause and I do not like coupling such a technology with another technology (in this case FMIP) that does not cause such problems... I am all for studying bicasting, comparing it with other smoothing mechanisms and deciding on what to do an a fashion orthogonal to FMIP. George -----Original Message----- From: Pat Calhoun [mailto:pcalhoun@diameter.org] Sent: Monday, July 30, 2001 3:14 PM To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Handover Smoothing - What to Do? On Mon, Jul 30, 2001 at 10:18:58AM -0400, George Tsirtsis wrote: > Maybe you have missed this...please see my response to Mike on the same > question... > I feel like a broken record by there you go :-0 but your response is in regards to a problem that is being fixed. Should we stop all development until the fix has an RFC number? I don't think so. Folks that want to build mobile devices will include this fix. Folks running general purpose OSes that don't include the fix can complain to their OS supplier. > P.S: in your question...what is "infrequent"??? the handoff? I do not think > so.... Relative to staying within a cell, yes, but I suppose with pico cells that's not the case. In any case, I'm not saying let's design a protocol assuming the mobile doesn't handoff often, in case that's what you thought I meant :) PatC From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 30 10:41:36 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA24996 for ; Mon, 30 Jul 2001 10:41:36 -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 IAA26864; Mon, 30 Jul 2001 08:41:46 -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 HAA08401; Mon, 30 Jul 2001 07:41:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6UEeaN29013 for mobile-ip-dist; Mon, 30 Jul 2001 07:40:36 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6UEeWY29006 for ; Mon, 30 Jul 2001 07:40:32 -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 HAA00475 for ; Mon, 30 Jul 2001 07:40:46 -0700 (PDT) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA19668 for ; Mon, 30 Jul 2001 08:42:16 -0600 (MDT) Received: by megisto-sql1.megisto.com with Internet Mail Service (5.5.2650.21) id ; Mon, 30 Jul 2001 10:40:36 -0400 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Handover Smoothing - What to Do? Date: Mon, 30 Jul 2001 10:40:25 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) 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: Pat Calhoun [mailto:pcalhoun@diameter.org] > Sent: Monday, July 30, 2001 10:23 AM > To: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Handover Smoothing - What to Do? > > > On Mon, Jul 30, 2001 at 10:23:35AM -0400, Phil Roberts wrote: > > I'm not sure what sort of problem it is, but would like to > know. I'm > > somewhat concerned about putting forth a proposal that does > cause this > > sometimes. It seems like it would be worthwhile to > determine whether there > > is another way to perform smooth handovers that doesn't > create duplicates. > > And just to be clear, the mobile wouldn't automatically > receive several > copies all the time. There is a fairly small window where the mobile > could end up receiving dups. Right. > > PatC > From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 30 10:58:18 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA26061 for ; Mon, 30 Jul 2001 10:58:17 -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 HAA09318; Mon, 30 Jul 2001 07:57:53 -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 HAA10426; Mon, 30 Jul 2001 07:56:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6UEt5R29142 for mobile-ip-dist; Mon, 30 Jul 2001 07:55:05 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6UEt1Y29135 for ; Mon, 30 Jul 2001 07:55:01 -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 HAA10241 for ; Mon, 30 Jul 2001 07:55:15 -0700 (PDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id IAA27726 for ; Mon, 30 Jul 2001 08:56:44 -0600 (MDT) Received: (qmail 4532 invoked by uid 500); 30 Jul 2001 14:43:50 -0000 Date: Mon, 30 Jul 2001 07:43:50 -0700 From: Pat Calhoun To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Handover Smoothing - What to Do? Message-ID: <20010730074350.B4496@charizard.diameter.org> References: <8C92E23A3E87FB479988285F9E22BE460546DD@ftmail> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <8C92E23A3E87FB479988285F9E22BE460546DD@ftmail>; from G.Tsirtsis@flarion.com on Mon, Jul 30, 2001 at 10:37:22AM -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: On Mon, Jul 30, 2001 at 10:37:22AM -0400, George Tsirtsis wrote: > So you did not miss it :) > > Pat, I never said stop all development, if that is what you thought I meant > :)...I only said that specs should be clear about problems that a technology > might cause and I do not like coupling such a technology with another > technology (in this case FMIP) that does not cause such problems... > > I am all for studying bicasting, comparing it with other smoothing > mechanisms and deciding on what to do an a fashion orthogonal to FMIP. Excellent. Let's also make sure that we study buffering in as much detail, since I'm sure it'll uncover a few interesting nuggets. PatC From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 30 11:46:23 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA00046 for ; Mon, 30 Jul 2001 11:46:23 -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 HAA14779; Mon, 30 Jul 2001 07: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 GAA22020; Mon, 30 Jul 2001 06:46:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6UDiMI28170 for mobile-ip-dist; Mon, 30 Jul 2001 06:44:22 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6UDiIY28163 for ; Mon, 30 Jul 2001 06:44: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 GAA09469 for ; Mon, 30 Jul 2001 06:44:33 -0700 (PDT) Received: from sonne.darmstadt.gmd.de (sonne.darmstadt.gmd.de [141.12.62.20]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA13611 for ; Mon, 30 Jul 2001 07:44:30 -0600 (MDT) Received: from ipsi.fraunhofer.de (pc-morion [141.12.35.155]) by sonne.darmstadt.gmd.de (8.8.8/8.8.5) with ESMTP id PAA11650; Mon, 30 Jul 2001 15:44:29 +0200 (MET DST) Message-ID: <3B6565C0.82B7A039@ipsi.fraunhofer.de> Date: Mon, 30 Jul 2001 15:48:48 +0200 From: Wolfgang Schoenfeld Organization: FhG IPSI X-Mailer: Mozilla 4.7 [de] (WinNT; I) X-Accept-Language: en,de MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Handover Smoothing - What to Do? References: <034BEFD03799D411A59F00508BDF754603008B7D@esealnt448.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, to a certain extend, I understand your impatience - you want to go on with your idea. But let me, in order to illustrate the gravity of the situation, develop an analogy: Assume that you have a gun and you want to shoot a bullet (i.e. data packet) to a target. If the target is stationary - no problem. If it is mobile, you have to perform quite complicated computations which take velocity of bullet and velocity as well as direction of target into account. Since you don't know the latter (neither the former), you may take a machine gun which produces lots of copies of the bullet/packet. Obviously, this increases the probabilty that you hit the target. Alternatively, you may introduce 'redirection guns' which intercept your packet and redirect it to some new position of the target. Or you may use retardation devices to hold back the packet if it is too early. (Maybe, there are acceleration devices, too.) You may also combine all these mechanisms into 'enhanced machine guns'. And the final solution would be to 'broadcast' everywhere - at least one bullet/packet would reach the target in any case. Well, you can do that. However, because of possible collateral damages, you have to carefully analyze what you are doing. Where is such an analysis? Note that an analysis is the harder the more complicated your mechanism is. You have to take into account not only velocity and direction of the bullet, but also the effects of all the intermediate devices. Do you really believe that 'practical tests' are sufficient? Wolfgang PS: Question to Phil's recent email: Is the following understand right? fast handover = very quickly adjust the gun to a new position smooth handover = try all the other means mentioned above "Hesham Soliman (ERA)" schrieb: > > Hello Rajeev, > > > > There are so many mails I hope no one else made the same > > > comments that I'm about to make. > > > > > > > I don't understand your viewpoint. Just because you have not heard from > > > > buffering advocates does not imply that the alternative is the way to go. There > > > > are at least two things to consider. First, you are proposing to add a > > > > particular smoothing technique to FMIPv6. I am registering my complaint saying > > > > that it is not the right thing to do. > > > > > > > => You're making a statement that is not backed by a reason. See more below. > > > > > > > > > > On the contrary, I was reasoning that when FMIP can progress without having to rely on > > any particular smoothing technique. > > > => See an answer below. > > > > > FMIPv6 must be able to work independently > > > > of bicasting. > > > > > > > => Why ? > > > > > > > > > > Why not ? FMIP can work without any dependency. > > > => It _does_not. The draft clearly states that there are cases (like ping pong) > where the current solution does not work. We've said this many > times and it's in the FMIPv6 draft. > > > Besides, the smoothing techniques by > > themselves are not well-understood to be part of a standard. I mentioned this (in the > > same thread somewhere) didn't I ? > > > => This is handwaving, I'd prefer if you point out specific issues. > I don't think HC and CT has any role here. Bicasting adds nothing > to the complexity of the HC CT (which is already very complex > and of unproven value as it is). We can't build a solution taking into > consideration a solution that does not exist or even agreed on. > > > > > > > > Second, taking up smoothing as a > > > > topic by itself, it is not a foregone conclusion that bicasting/simultaneous > > > > binding are the only means. This is an open area and we need discussion and > > > > *real experimental* evidence. Also, the header compression example hold here as > > > > well. > > > > > > > => Well other proposals are also welcome. But I'm sure you can appreciate > > > that new ideas come up all the time, that doesn't mean we don't make > > > any decisions. We have to decide on what we have now. Unless you've > > > done some experiments on bicasting and saw that it's bad for some > > > reason. > > > > > > > We are now talking about handling smoothing techniques on their own. > > As I mentioned above, this topic by itself needs a lot of discussion before we can make > > decisions. I am not convinced that we can draw definitive conclusions on smoothing > > techniques to progress them on a standardization path. > > > => Frnkly I'm not interested in the discussion of documents and > which doc contains what. I'm more interested in the technical > evaluation of a proposal. It seems like people are avoiding > this topic. > > Regards, > Hesham -- Prof. Dr. Wolfgang Schoenfeld, Fraunhofer IPSI, Dolivostr. 15, D-64293 Darmstadt Office: +49-6151-869-865 FAX: -6847 Mobile: +49-174-7093455 From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 30 11:48:00 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA00161 for ; Mon, 30 Jul 2001 11:48:00 -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 JAA22899; Mon, 30 Jul 2001 09:47: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 IAA04150; Mon, 30 Jul 2001 08:47:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6UFkGX29503 for mobile-ip-dist; Mon, 30 Jul 2001 08:46:16 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6UFkCY29496 for ; Mon, 30 Jul 2001 08:46:12 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA10888 for ; Mon, 30 Jul 2001 08:46:26 -0700 (PDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA04891 for ; Mon, 30 Jul 2001 08:46:25 -0700 (PDT) Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f6UFkPO04067 for ; Mon, 30 Jul 2001 17:46:25 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Mon Jul 30 17:46:24 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Mon, 30 Jul 2001 17:46:24 +0200 Message-ID: <795A014AF92DD21182AF0008C7A404320C5204AC@esealnt117> From: "Karim El-Malki (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Handover Smoothing - What to Do? Date: Mon, 30 Jul 2001 17:46: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: Hello Phil > Here is the general observation. You are proposing bicasting > as a solution > that > solves only a part of the handover smoothing problem, that is > the potential > loss > of packets in flight between an HA or hierarchical MIP agent > and an FA or > AR. That's not totally correct and misses an important reason for bicasting. If FMIP (let's take FMIPv6) is used without any bicasting, the MN will receive a proxy advertisement a certain time before an L2 handoff and it will send a F-BU. From that moment onwards, until the MN moves to nAR it can't resume communication. The same thing is for FMIPv4. Does that make sense? So the MN will stay without service for a certain period. Instead, by using simultaneous bindings (which we've also called bicasting) that period of service disruption can be avoided. This is more than eliminating the loss of packets in flight between HA or local HA and FA/AR while the MN is about to make the L2 handoff. > That's > fine as far as it goes and it seems it should be made clear > that this is > *all* it > does. It does not help in the general case of interruption > of flow between > oFA/MN and > nFA/MN. I believe you agree to this below when you say the > examples I put > forth were > L2 specific. Some comments on this above. Of course we cannot get L3 to solve the case where the MN is disconnected al L2. > > Also what I was pointing to is that a buffer is probably needed > > if the handoff time from oFA to nFA is not negligible (your next > > case and this case). That's why packet dropping is a MAY. So this > > case wouldn't happen, unless of course it's not TCP and you don't > > care about dropping some packets. In fact low latency handoffs are > > probably most useful for real-time services (e.g. Voice on UDP) > > in which case, if there's an period of L2 disconnection during > > handoff, the packets should be dropped. > > So here we need some kind of information that describes FA or AR > behavior wrt duration of the handoff time and whether or not it's > TCP traffic or something that is realtime traffic. Happy to put something in describing the real-time/non real-time cases. The idea was to leave this behaviour open and say the nFA MAY buffer or MAY drop. We could give an example though. > > The buffer size should be set such that you don't get duplicates. > > By the time MN connects to nFA, the second copy of the packet > > should be dropped out of the FIFO queue/buffer and the next one > > should be ready for sending to MN. Of course this calculation > > depends on the l2 handoff characteristics and possibly the wired > > connectivity between the bicasting point and oFA/nFA. > > I agree with this, but I don't know how to do it. Now we need to add > to the decision matrix characteristics about the wired connectivity. Well, I can agree with putting in some examples as above but we can't design the system and take the implementor's place. So would some examples be what you are looking for? > But still, it doesn't take into account latency within the network. > Whereas it seems that a receiving station might be able to make some > intelligent decisions about when it is important to drop a > packet (because > it arrived way too late), but now do you want the network in > between to get > involved in the measurement and timing of these decisions? No measurement is involved by the network. Any buffering is put in place by the implementor depending on the traffic, network etc. That has to be done in any case depending on the application. I wasn't suggesting an on-the-fly calculation. > > > Or like this? > > > The same packet arrives at oFA and is transmitted to the MN > > > which then moves > > > to the > > > nFA and gets the same packet which was delayed on its way > > to the nFA. > > > > That would again need to be handled by a jitter-smoothing > > buffer at nFA. > > OK, but how? A packet arrives at the nFA. How does the nFA > have any idea > whether or not it needs to be buffered and then for how long, > or dropped? > In > this case it should be dropped, in the previous case it > should be dropped, > and in the first case it should be sent. But the only way I > know that is by > knowing what the MN has already received. If the jitter-smoothing buffer is put in nFA it will be used. There's no decision on-the-fly. If instead it is deemed that the gains in buffering are not worth the memeory/complexity then we have the case where nFA always drops. > > > It seems like there is some coordination needed between the > > > oFA and the nFA > > > to > > > overcome these problems, perhaps a temporary tunnel? But > > in that case > > > bicasting from > > > an HA or a hierarchical FA wouldn't be adding much to it, > > > would it. > > > > Well, I think that having a local central HA would help. > > Say that oFA and nFA are at an equal distance from the GFA > > which is the aggregation router between the two. That could > > alleviate jitter on the fixed network, as has been already > > mentioned by James. Also, if oFA and nFA happen to be connected > > to each other through the GFA router, then bicasting at the > > GFA would be more efficient. > > But wait a second. What do you mean by equal distance? Number > of hops, geographical distance? It has to be transmission time. > Is this another item we need to add to our decision matrix? That's the wired connectivity which you had previously and I assumed that was the same as transmission time. This would not be considered in the case I described above, but would be part of the buffer sizing calculation otherwise. So there's different ways of implementing this. Overall, you seem to want to understand the details of the buffer calculation. It's good to discuss this and find any problems, but I don't think we should document a formula how to calculate buffer sizes. The people who know the L2 characteristics and the implementors will know better. The point is that, and I've hopefully come across with that, bicasting is useful and can work. Otherwise if I haven't succeeded, too bad :( > So I guess in summary, "I don't buy it," means I'm not convinced by > your answers. I've given some of my reasons why. Hope I've answered some of the questions. What I haven't understood yet is whether you think it can work but we need to study the details or whether you think this doesn't work. > What I would recommend instead of including bicasting in the > fast handoff > drafts for v4 and v6 is a placeholder that describes > precisely what the > problem > is (of lost packets in flight) and that a solution needs to > be provided. > The WG > debates the possible solutions and puts those in a separate draft. Well, the problem is not really lost packets in flight. Anyway, this placeholder would have to be turned into a reference to the new solution/s ASAP. If not, the FMIP drafts remain incomplete. That is, they solve the handoff issue but introduce another period of service disruption. I don't think we can assume that there will be L2 solutions to this new gap. > > Speaking as a working group chair now: > > I'm doing a little work to find out whether a solution that introduces > duplicate > packets will be shot down by the IESG right off the bat. It > seems wise to > separate the fast from the smooth part, advance the fast, and > produce a > solution > for the smooth later. Fast and smooth are tightly linked. So we cannot move Fast on without having come to some solution for smooth. They should go hand in hand through standards process, which is why I don't like the idea of delaying bicasting/buffering for later. Rgds /Karim From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 30 12:32:22 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04131 for ; Mon, 30 Jul 2001 12:32:22 -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 JAA27192; Mon, 30 Jul 2001 09:32:30 -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 JAA28697; Mon, 30 Jul 2001 09:27:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6UGQOl29652 for mobile-ip-dist; Mon, 30 Jul 2001 09:26:24 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6UGQLY29645 for ; Mon, 30 Jul 2001 09:26:21 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA12754 for ; Mon, 30 Jul 2001 09:26:35 -0700 (PDT) Received: from jm.epitest.fi (d248-126.arenanet.fi [194.241.248.126]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id JAA25100 for ; Mon, 30 Jul 2001 09:26:34 -0700 (PDT) Received: (qmail 17380 invoked by uid 500); 30 Jul 2001 16:26:33 -0000 Date: Mon, 30 Jul 2001 19:26:33 +0300 From: Jouni Malinen To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] draft-ietf-mobileip-aaa-key-08.txt and MN-AAA auth ext in reply Message-ID: <20010730192633.B14137@jm.epitest.fi> References: <200107271107.HAA06650@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200107271107.HAA06650@ietf.org>; from Internet-Drafts@ietf.org on Fri, Jul 27, 2001 at 07:07:42AM -0400 X-AntiVirus: scanned for viruses by AMaViS 0.2.1 (http://amavis.org/) 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: aaa-key-08 draft has following text in chapter 1: ... When the Mobile IP Registration Reply packet is authenticated by the MN-AAA Authentication Extension [3], the mobile node can verify that the keys contained in the extensions were produced by the AAA server, and thus may be reliably used to create security associations with the home agent, or alternatively with the foreign agent. ... I.e., it specifies that MN can use MN-AAA auth ext to authenticate registration _reply_. However, RFC 3012, chapter 6 has following requirement which seems to conflict with the text above: ... The mobile node MAY include a MN-AAA Authentication extension in any Registration Request. The corresponding response MUST include the MN-HA Authentication Extension, and MUST NOT include the MN-AAA Authentication Extension. ... In addition, aaa-key draft does not require that MN-AAA auth ext protects MN-FA or MN-HA key material from AAA extensions. Chapter 2, items 7 and 8 require that the Reply passes authentication before MN generates the key using key material provided. Am I correct in assuming, that the validation must be done by first generating temporary keys based on key material and then checking the MN-HA / MN-FA auth ext (that are required to be in the reply containing corresponding key material)? Only if this validation is successful, the temporary keys are actually taken into use. Should this be explained in more details? At least the introduction talking about MN-AAA auth ext in registration reply should be fixed. -- Jouni Malinen PGP id EFC895FA From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 30 13:01:25 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA06768 for ; Mon, 30 Jul 2001 13:01:24 -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 LAA25360; Mon, 30 Jul 2001 11:01:47 -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 HAA10981; Mon, 30 Jul 2001 07:59:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6UEwcg29187 for mobile-ip-dist; Mon, 30 Jul 2001 07:58:38 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6UEwYY29177 for ; Mon, 30 Jul 2001 07:58:34 -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 HAA02861 for ; Mon, 30 Jul 2001 07:58:48 -0700 (PDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA10543 for ; Mon, 30 Jul 2001 08:58:45 -0600 (MDT) Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f6UEwjO15115 for ; Mon, 30 Jul 2001 16:58:45 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Mon Jul 30 16:58:45 2001 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 30 Jul 2001 16:52:31 +0200 Message-ID: <795A014AF92DD21182AF0008C7A404320C5204AB@esealnt117> From: "Karim El-Malki (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] comments on low latency handoff draft Date: Mon, 30 Jul 2001 16:58: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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hello Thanks for the comments. Some replies below. > here are some more general comments on the draft. > > The draft assumes that the L2 will be able to provide > information that > says a handoff is about > to occur, but no concrete information about when it has > occured. I find > this a little odd. Are there > some concrete examples of L2 technology someone could point > to like this? A > lot of what's in this draft > seems to rest on this second assumption. It justifies the need for > bicasting in the POST REG method. POST-REG doesn't need bicasting for the reason that there is no information of when the handoff has occurred. It's just that you won't be told "handoff will happen in precisely xxx.xxx msecs". In any case, the draft also supports triggers saying "handoff has occurred". A trigger could be a message from L2 identifying that the handoff is being requested/initiated. That's an example of the "about to occur" case. There are also "network handoff complete" and "mobile handoff complete" triggers (as reported in Table 1) which communicate that the handoff event has occurred. Both types of trigger are used. > > On page 5, it says that "[t]he registration process takes > some non-zero > time to complete as the Registration Requests propagate > through the network. > During this period of time the MN is not able to send or receive IP > packets." I don't follow this. It should be able to send if it is > connected and possibly receive though not at its home address. Until the FA has made sure that the user is authorised to use the network it should not give service to the MN. That means that the FA must wait for the reply. So the MN should neither receive nor be able to transmit. Am I missing something? > > In table 1 is it useful to include a trigger for a link > down status? > (IE. I just told the mobile to go somewhere else so you can't > reach it via > this link anymore). That could be another trigger. What would it be applied to? > > On page 9 "no dependence on a wireless L2 technology," > should probably > be clarified in the light of the presence of various L2 triggers the > protocols make use of. I thought the point of having triggers was to be independent of a particular wireless standard. By this I mean that the "about to handoff" trigger comes from different nodes in different wireless standards but is presented as a single logical trigger to the receiving entity. Of course not all wireless systems will have all the triggers. But if the trigger is available it'll be generic. What were you suggesting? > > On page 10 (pedantic) s/order to not delay/order not to delay/ OK. > > On page 11. I don't understand what's being said in > paragraph 3. "The > MN performs movement detection upon receipt of either a solicited or > unsolicited RA,...." By movement detection I gather from the > rest of the > explanation that it is "possible upcoming movement > detection?" How does a > mobile node MIP client know it has actually moved? I'm not sure I understand your question. Are you saying that the MN must know when it actually moves? What does the MIP client need to do when it finds it has actually moved? > On page 15. "the trigger timing SHOULD be arranged such > that a full L3 > ...." Hmmm. This seems like a curious requirement. This > seems more like > an assumption about the underlying technology. How can we > specify in *this* > document how an L2 should be engineered? We don't. What we specify is the anticipation of the L3 handoff. The implementors then need to make sure that the anticipation time is appropriate for their L2 system. > > On page 17 "... are also useful to support ping-ponging." should > probably be reworded. Perhaps "... are also useful to > support proper L3 > operation in the presence of ping-pong behavior at L2?" OK, but I guess the meaning is clear isn't it? (defined ping-pong in terminology). > > On page 23 Perhaps it would be possible to elaborate on > some of the > specifics to smooth the behavior in the presence of ping-ponging? I'm > assuming the nFA gets some traffic and finds out somehow that > the mobile is > back on the oFA and starts sending it back? It's basically that the ping-pong will cause continuous triggers and therefore continuous tunnel setups between oFA and nFA. So yes, traffic gets sent back and forth or just dropped if there is not enough time to setup the tunnel. > > On page 23 s/egress/ingress/ OK. > > On page 26 "The MN MAY ... establish a link-layer > connection with the > MN." I suspect one of these MNs should be something else. Yes thanks, the first is FA. > > On page 26 "The oFA SHOULD stop bicasting ...." Why > SHOULD rather than > MUST? I think that is a MUST. > On page 31 would it be helpful to have a reference in the IMSI > extension to where one could get info on IMSIs and connection > ids. Does the > length of this extension include the subtype field as in the other > extensions? yes. This may need some more clarification. I believe that this IMSI coding was aimed at CDMA2000, but it would be good to make sure it works in other cases too. > Anybody got any patents that they need to tell us about? Not that I know of. /Karim From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 30 13:33:27 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09405 for ; Mon, 30 Jul 2001 13:33:26 -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 KAA27821; Mon, 30 Jul 2001 10:33:35 -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 KAA12514; Mon, 30 Jul 2001 10:22:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6UHKuh00015 for mobile-ip-dist; Mon, 30 Jul 2001 10:20:56 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6UHKqY00008 for ; Mon, 30 Jul 2001 10:20:53 -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 KAA11892 for ; Mon, 30 Jul 2001 10:21:07 -0700 (PDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id LAA12388 for ; Mon, 30 Jul 2001 11:21:05 -0600 (MDT) Received: (qmail 5268 invoked by uid 500); 30 Jul 2001 17:09:50 -0000 Date: Mon, 30 Jul 2001 10:09:50 -0700 From: Pat Calhoun To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Handover Smoothing - What to Do? Message-ID: <20010730100950.H4496@charizard.diameter.org> References: <9FBD322B7824D511B36900508BF93C9C9F5EAC@zcard031.ca.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: <9FBD322B7824D511B36900508BF93C9C9F5EAC@zcard031.ca.nortel.com>; from gkenward@nortelnetworks.com on Mon, Jul 30, 2001 at 01:08:26PM -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: > I am not saying you are wrong, but a detrimental increase > in duplicates is possible, and given the complete lack > of bounds on the behaviour of handover, it would seem > imprudent to say that there is no issue. I didn't meant to say there is no issue. I was just stating that we are building a solution for a handoff, which already has overhead, and complexity. Adding dups, buffering or anyother solution is trivial. Since dups already occur in the 'net, and clients already have to handle them (and they don't, hence the proposed fix), then bicasting seems an appropriate option to consider. Of course, I won't dispute that a more thorough analysis of bicasting and buffering is needed. PatC From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 30 13:36:23 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09662 for ; Mon, 30 Jul 2001 13:36:23 -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 LAA26819; Mon, 30 Jul 2001 11:36: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 IAA01716; Mon, 30 Jul 2001 08:36:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6UFYti29398 for mobile-ip-dist; Mon, 30 Jul 2001 08:34:55 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6UFYpY29391 for ; Mon, 30 Jul 2001 08:34:51 -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 IAA17477 for ; Mon, 30 Jul 2001 08:35:05 -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 JAA12307 for ; Mon, 30 Jul 2001 09:35:03 -0600 (MDT) Received: by megisto-sql1.megisto.com with Internet Mail Service (5.5.2650.21) id ; Mon, 30 Jul 2001 11:34:56 -0400 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] comments on low latency handoff draft Date: Mon, 30 Jul 2001 11:34:52 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) 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: Hi, > > > > > On page 5, it says that "[t]he registration process takes > > some non-zero > > time to complete as the Registration Requests propagate > > through the network. > > During this period of time the MN is not able to send or receive IP > > packets." I don't follow this. It should be able to send if it is > > connected and possibly receive though not at its home address. > > Until the FA has made sure that the user is authorised to use the > network it should not give service to the MN. That means that the FA > must wait for the reply. So the MN should neither receive nor be able > to transmit. Am I missing something? No, I'd just make what you stated clear in the draft. > > > > > In table 1 is it useful to include a trigger for a link > > down status? > > (IE. I just told the mobile to go somewhere else so you can't > > reach it via > > this link anymore). > > That could be another trigger. What would it be applied to? packet forwarding from the old FA/AR for smoothing. > > > > > On page 9 "no dependence on a wireless L2 technology," > > should probably > > be clarified in the light of the presence of various L2 triggers the > > protocols make use of. > > I thought the point of having triggers was to be independent of a > particular wireless standard. By this I mean that the "about to > handoff" trigger comes from different nodes in different wireless > standards but is presented as a single logical trigger to the > receiving entity. Of course not all wireless systems will have > all the triggers. But if the trigger is available it'll be generic. > What were you suggesting? Just that (some of?) the layer 2 triggers themselves while abstracted the way you suggest are needed for the methods in this draft. > > On page 11. I don't understand what's being said in > > paragraph 3. "The > > MN performs movement detection upon receipt of either a solicited or > > unsolicited RA,...." By movement detection I gather from the > > rest of the > > explanation that it is "possible upcoming movement > > detection?" How does a > > mobile node MIP client know it has actually moved? > > I'm not sure I understand your question. > Are you saying that the MN must know when it actually moves? > What does the MIP client need to do when it finds it has actually > moved? Hey, I'm asking the questions here!!! Seriously, I didn't understand the text and was trying to figure out why it was there. Now that I've gone back and read it more closely I understand what it's saying. Disregard this question. > > > > On page 15. "the trigger timing SHOULD be arranged such > > that a full L3 > > ...." Hmmm. This seems like a curious requirement. This > > seems more like > > an assumption about the underlying technology. How can we > > specify in *this* > > document how an L2 should be engineered? > > We don't. What we specify is the anticipation of the L3 handoff. > The implementors then need to make sure that the anticipation > time is appropriate for their L2 system. Well, the document uses a SHOULD to specify something that is implemented elsewhere rather than in the entities that are making this part of it work. I suppose this is ok, but it strikes me as a little strange. Stating it as an assumption about how the underlying technology has to be engineered for this to work would be another way of doing it. > > > > > On page 17 "... are also useful to support > ping-ponging." should > > probably be reworded. Perhaps "... are also useful to > > support proper L3 > > operation in the presence of ping-pong behavior at L2?" > > OK, but I guess the meaning is clear isn't it? (defined ping-pong > in terminology). You and I know what ping-pong is, or what it is in this context, but I'm not sure all readers or reviewers will. > > > > > On page 23 Perhaps it would be possible to elaborate on > > some of the > > specifics to smooth the behavior in the presence of > ping-ponging? I'm > > assuming the nFA gets some traffic and finds out somehow that > > the mobile is > > back on the oFA and starts sending it back? > > It's basically that the ping-pong will cause continuous triggers > and therefore continuous tunnel setups between oFA and nFA. > So yes, traffic gets sent back and forth or just dropped if there > is not enough time to setup the tunnel. Can you incorporate this explanation, then? > > /Karim > Good, thanks, Phil From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 30 13:38:54 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09876 for ; Mon, 30 Jul 2001 13:38:53 -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 KAA00483; Mon, 30 Jul 2001 10:38:29 -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 KAA08777; Mon, 30 Jul 2001 10:11:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6UH8sx29883 for mobile-ip-dist; Mon, 30 Jul 2001 10:08:54 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6UH8oY29876 for ; Mon, 30 Jul 2001 10:08:50 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA08032 for ; Mon, 30 Jul 2001 10:09:05 -0700 (PDT) Received: from zcars0m9.ca.nortel.com ([47.129.242.157]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA15542 for ; Mon, 30 Jul 2001 10:09:04 -0700 (PDT) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f6UH8a907511 for ; Mon, 30 Jul 2001 13:08:36 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Mon, 30 Jul 2001 13:08:33 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 30 Jul 2001 13:08:35 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5EAC@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Handover Smoothing - What to Do? Date: Mon, 30 Jul 2001 13:08:26 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1191A.3F97C680" X-Orig: 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_01C1191A.3F97C680 Content-Type: text/plain; charset="iso-8859-1" Pat: What is "infrequent"? Just for the sake of the discussion, if on average 0.5 packets are duplicated per handoff (e.g. ever second handover produces a duplicate), is this a big increase in duplicates? Obviously, it would depend upon the rate of handover, and if I'm dealing with 1Km cells and pedestrian traffic, this may not be a big issue. What if the cells are 100m? 10m? 0.5 packet duplicates per handoff is not extreme - it could easily happen. I am not saying you are wrong, but a detrimental increase in duplicates is possible, and given the complete lack of bounds on the behaviour of handover, it would seem imprudent to say that there is no issue. Gary > -----Original Message----- > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > Sent: July 30, 2001 10:00 > To: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Handover Smoothing - What to Do? > > > > So what's my position on this? It seems that there are > fairly obvious > > cases in which bicasting introduces packet duplicates with > potentially > > unknown > > effects in the network. It doesn't seem the network agents > will have the > > information needed to prevent this from happening. > > Just for clarification, duplicate packets already occur in > the network. > > So, why is the possibility of creating duplicates at the > edges, during a > handoff - which is infrequent - now become a real problem, when they > already occur in the network without handoffs? > > PatC > ------_=_NextPart_001_01C1191A.3F97C680 Content-Type: text/html; charset="iso-8859-1" RE: [mobile-ip] Handover Smoothing - What to Do?

Pat:

 What is "infrequent"? Just for the sake of the discussion,
if on average 0.5 packets are duplicated per handoff (e.g.
ever second handover produces a duplicate), is this
a big increase in duplicates? Obviously, it would depend
upon the rate of handover, and if I'm dealing with 1Km
cells and pedestrian traffic, this may not be a big issue.
What if the cells are 100m? 10m? 0.5 packet duplicates per
handoff is not extreme - it could easily happen.

 I am not saying you are wrong, but a detrimental increase
in duplicates is possible, and given the complete lack
of bounds on the behaviour of handover, it would seem
imprudent to say that there is no issue.

Gary

> -----Original Message-----
> From: Pat Calhoun [mailto:pcalhoun@diameter.org]
> Sent: July 30, 2001 10:00
> To: mobile-ip@sunroof.eng.sun.com
> Subject: Re: [mobile-ip] Handover Smoothing - What to Do?
>
>
> > So what's my position on this?  It seems that there are
> fairly obvious
> > cases in which bicasting introduces packet duplicates with
> potentially
> > unknown
> > effects in the network.  It doesn't seem the network agents
> will have the
> > information needed to prevent this from happening.
>
> Just for clarification, duplicate packets already occur in
> the network.
>
> So, why is the possibility of creating duplicates at the
> edges, during a
> handoff - which is infrequent - now become a real problem, when they
> already occur in the network without handoffs?
>
> PatC
>

------_=_NextPart_001_01C1191A.3F97C680-- From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 30 14:01:12 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA11386 for ; Mon, 30 Jul 2001 14:01:12 -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 LAA11955; Mon, 30 Jul 2001 11:00:29 -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 KAA20704; Mon, 30 Jul 2001 10:54:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6UHqpB00241 for mobile-ip-dist; Mon, 30 Jul 2001 10:52:51 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6UHqmY00233 for ; Mon, 30 Jul 2001 10:52:48 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id KAA25726 for ; Mon, 30 Jul 2001 10:53:03 -0700 (PDT) Message-Id: <200107301753.KAA25726@heliopolis.eng.sun.com> Date: Mon, 30 Jul 2001 10:53:01 -0700 (PDT) From: James Kempf Subject: RE: [mobile-ip] comments on low latency handoff draft To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: RG7O9NZpw3lyfZ2rVhHY/Q== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 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: Phil/Karim, Maybe we can remove the section on L2 triggers and instead make reference to draft-manyfolks-mobilereq-l2-00.txt? Seems better to have this information in one place, makes it easier to update. We would, of course, still need to edit to reflect how the triggers are used (e.g. using a "Link Down" trigger to signal that handoff did, in fact, occur as opposed to that handoff is anticipated). jak >From: Phil Roberts >To: "'mobile-ip@sunroof.eng.sun.com'" >Subject: RE: [mobile-ip] comments on low latency handoff draft >Date: Mon, 30 Jul 2001 11:34:52 -0400 > >Hi, > > >> >> > >> > On page 5, it says that "[t]he registration process takes >> > some non-zero >> > time to complete as the Registration Requests propagate >> > through the network. >> > During this period of time the MN is not able to send or receive IP >> > packets." I don't follow this. It should be able to send if it is >> > connected and possibly receive though not at its home address. >> >> Until the FA has made sure that the user is authorised to use the >> network it should not give service to the MN. That means that the FA >> must wait for the reply. So the MN should neither receive nor be able >> to transmit. Am I missing something? > >No, I'd just make what you stated clear in the draft. > >> >> > >> > In table 1 is it useful to include a trigger for a link >> > down status? >> > (IE. I just told the mobile to go somewhere else so you can't >> > reach it via >> > this link anymore). >> >> That could be another trigger. What would it be applied to? > >packet forwarding from the old FA/AR for smoothing. > >> >> > >> > On page 9 "no dependence on a wireless L2 technology," >> > should probably >> > be clarified in the light of the presence of various L2 triggers the >> > protocols make use of. >> >> I thought the point of having triggers was to be independent of a >> particular wireless standard. By this I mean that the "about to >> handoff" trigger comes from different nodes in different wireless >> standards but is presented as a single logical trigger to the >> receiving entity. Of course not all wireless systems will have >> all the triggers. But if the trigger is available it'll be generic. >> What were you suggesting? > >Just that (some of?) the layer 2 triggers themselves while abstracted the >way you >suggest are needed for the methods in this draft. > > >> > On page 11. I don't understand what's being said in >> > paragraph 3. "The >> > MN performs movement detection upon receipt of either a solicited or >> > unsolicited RA,...." By movement detection I gather from the >> > rest of the >> > explanation that it is "possible upcoming movement >> > detection?" How does a >> > mobile node MIP client know it has actually moved? >> >> I'm not sure I understand your question. >> Are you saying that the MN must know when it actually moves? >> What does the MIP client need to do when it finds it has actually >> moved? > >Hey, I'm asking the questions here!!! > >Seriously, I didn't understand the text and was trying to figure out why it >was there. >Now that I've gone back and read it more closely I understand what it's >saying. Disregard >this question. > >> >> >> > On page 15. "the trigger timing SHOULD be arranged such >> > that a full L3 >> > ...." Hmmm. This seems like a curious requirement. This >> > seems more like >> > an assumption about the underlying technology. How can we >> > specify in *this* >> > document how an L2 should be engineered? >> >> We don't. What we specify is the anticipation of the L3 handoff. >> The implementors then need to make sure that the anticipation >> time is appropriate for their L2 system. > >Well, the document uses a SHOULD to specify something that is implemented >elsewhere rather than in the entities that are making this part of it work. >I suppose this is ok, but it strikes me as a little strange. Stating it >as an assumption about how the underlying technology has to be engineered >for >this to work would be another way of doing it. > >> >> > >> > On page 17 "... are also useful to support >> ping-ponging." should >> > probably be reworded. Perhaps "... are also useful to >> > support proper L3 >> > operation in the presence of ping-pong behavior at L2?" >> >> OK, but I guess the meaning is clear isn't it? (defined ping-pong >> in terminology). > >You and I know what ping-pong is, or what it is in this context, but I'm not >sure all readers or reviewers will. > >> >> > >> > On page 23 Perhaps it would be possible to elaborate on >> > some of the >> > specifics to smooth the behavior in the presence of >> ping-ponging? I'm >> > assuming the nFA gets some traffic and finds out somehow that >> > the mobile is >> > back on the oFA and starts sending it back? >> >> It's basically that the ping-pong will cause continuous triggers >> and therefore continuous tunnel setups between oFA and nFA. >> So yes, traffic gets sent back and forth or just dropped if there >> is not enough time to setup the tunnel. > >Can you incorporate this explanation, then? > >> >> /Karim >> > >Good, thanks, >Phil > From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 30 14:11:39 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12097 for ; Mon, 30 Jul 2001 14:11:38 -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 MAA26550; Mon, 30 Jul 2001 12:11:55 -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 LAA24743; Mon, 30 Jul 2001 11:11:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6UI9ox00394 for mobile-ip-dist; Mon, 30 Jul 2001 11:09:50 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6UI9kY00387 for ; Mon, 30 Jul 2001 11:09:46 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id LAA26689 for ; Mon, 30 Jul 2001 11:10:02 -0700 (PDT) Message-Id: <200107301810.LAA26689@heliopolis.eng.sun.com> Date: Mon, 30 Jul 2001 11:10:00 -0700 (PDT) From: James Kempf Subject: Re: [mobile-ip] Analysis of Latency Propagation with Buffering To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: crZMh6qRsL+dJQ8HdyOvzQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 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: Hi Erik, >> R = T(0)/(1 - (A/B)) > >You seem to have computed the total time until the buffering and downloading >of the buffer process is running. Correct. >This is longer than the maximum delay that buffering adds to any packet. The concern isn't with the maximum delay added to any packet, but rather the time period in which *any* traffic is buffered. The longer traffic is buffered, the longer it loses its "real time" characteristic, and the more likely users will perceive the converstation as stilted or hear some artifact. >In fact, isn't the max delay added just T(0) for the first packet >that was buffered. Then subsequent packets see a linearly decreasing >addional delay until R time units have passed. > Sure, but, as I mentioned above, the figure of merit for judging acceptability for users is the aggregate delay, not the per packet delay. jak From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 30 14:30:45 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14208 for ; Mon, 30 Jul 2001 14:30:44 -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 MAA13917; Mon, 30 Jul 2001 12:31:03 -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 LAA00286; Mon, 30 Jul 2001 11:30:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6UITai00701 for mobile-ip-dist; Mon, 30 Jul 2001 11:29:36 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6UITXY00694 for ; Mon, 30 Jul 2001 11:29:33 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA13156 for ; Mon, 30 Jul 2001 11:29:47 -0700 (PDT) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA27495 for ; Mon, 30 Jul 2001 11:29:46 -0700 (PDT) Received: by megisto-sql1.megisto.com with Internet Mail Service (5.5.2650.21) id ; Mon, 30 Jul 2001 14:29:37 -0400 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] comments on low latency handoff draft Date: Mon, 30 Jul 2001 14:29:31 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) 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: James Kempf [mailto:James.Kempf@Sun.COM] > Sent: Monday, July 30, 2001 1:53 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: RE: [mobile-ip] comments on low latency handoff draft > > > Phil/Karim, > > Maybe we can remove the section on L2 triggers and instead make > reference to draft-manyfolks-mobilereq-l2-00.txt? Seems better > to have this information in one place, makes it easier to update. > We would, of course, still need to edit to reflect how > the triggers are used (e.g. using a "Link Down" trigger to > signal that handoff did, in fact, occur as opposed to that > handoff is anticipated). I didn't see the 2 triggers in opposition, but complementary. > > jak > >From: Phil Roberts > >To: "'mobile-ip@sunroof.eng.sun.com'" > >Subject: RE: [mobile-ip] comments on low latency handoff draft > >Date: Mon, 30 Jul 2001 11:34:52 -0400 > > > >Hi, > > > > > >> > >> > > >> > On page 5, it says that "[t]he registration process takes > >> > some non-zero > >> > time to complete as the Registration Requests propagate > >> > through the network. > >> > During this period of time the MN is not able to send or > receive IP > >> > packets." I don't follow this. It should be able to > send if it is > >> > connected and possibly receive though not at its home address. > >> > >> Until the FA has made sure that the user is authorised to use the > >> network it should not give service to the MN. That means > that the FA > >> must wait for the reply. So the MN should neither receive > nor be able > >> to transmit. Am I missing something? > > > >No, I'd just make what you stated clear in the draft. > > > >> > >> > > >> > In table 1 is it useful to include a trigger for a link > >> > down status? > >> > (IE. I just told the mobile to go somewhere else so you can't > >> > reach it via > >> > this link anymore). > >> > >> That could be another trigger. What would it be applied to? > > > >packet forwarding from the old FA/AR for smoothing. > > > >> > >> > > >> > On page 9 "no dependence on a wireless L2 technology," > >> > should probably > >> > be clarified in the light of the presence of various L2 > triggers the > >> > protocols make use of. > >> > >> I thought the point of having triggers was to be independent of a > >> particular wireless standard. By this I mean that the "about to > >> handoff" trigger comes from different nodes in different wireless > >> standards but is presented as a single logical trigger to the > >> receiving entity. Of course not all wireless systems will have > >> all the triggers. But if the trigger is available it'll be generic. > >> What were you suggesting? > > > >Just that (some of?) the layer 2 triggers themselves while > abstracted the > >way you > >suggest are needed for the methods in this draft. > > > > > >> > On page 11. I don't understand what's being said in > >> > paragraph 3. "The > >> > MN performs movement detection upon receipt of either a > solicited or > >> > unsolicited RA,...." By movement detection I gather from the > >> > rest of the > >> > explanation that it is "possible upcoming movement > >> > detection?" How does a > >> > mobile node MIP client know it has actually moved? > >> > >> I'm not sure I understand your question. > >> Are you saying that the MN must know when it actually moves? > >> What does the MIP client need to do when it finds it has actually > >> moved? > > > >Hey, I'm asking the questions here!!! > > > >Seriously, I didn't understand the text and was trying to > figure out why it > >was there. > >Now that I've gone back and read it more closely I > understand what it's > >saying. Disregard > >this question. > > > >> > >> > >> > On page 15. "the trigger timing SHOULD be arranged such > >> > that a full L3 > >> > ...." Hmmm. This seems like a curious requirement. This > >> > seems more like > >> > an assumption about the underlying technology. How can we > >> > specify in *this* > >> > document how an L2 should be engineered? > >> > >> We don't. What we specify is the anticipation of the L3 handoff. > >> The implementors then need to make sure that the anticipation > >> time is appropriate for their L2 system. > > > >Well, the document uses a SHOULD to specify something that > is implemented > >elsewhere rather than in the entities that are making this > part of it work. > >I suppose this is ok, but it strikes me as a little strange. > Stating it > >as an assumption about how the underlying technology has to > be engineered > >for > >this to work would be another way of doing it. > > > >> > >> > > >> > On page 17 "... are also useful to support > >> ping-ponging." should > >> > probably be reworded. Perhaps "... are also useful to > >> > support proper L3 > >> > operation in the presence of ping-pong behavior at L2?" > >> > >> OK, but I guess the meaning is clear isn't it? (defined ping-pong > >> in terminology). > > > >You and I know what ping-pong is, or what it is in this > context, but I'm not > >sure all readers or reviewers will. > > > >> > >> > > >> > On page 23 Perhaps it would be possible to elaborate on > >> > some of the > >> > specifics to smooth the behavior in the presence of > >> ping-ponging? I'm > >> > assuming the nFA gets some traffic and finds out somehow that > >> > the mobile is > >> > back on the oFA and starts sending it back? > >> > >> It's basically that the ping-pong will cause continuous triggers > >> and therefore continuous tunnel setups between oFA and nFA. > >> So yes, traffic gets sent back and forth or just dropped if there > >> is not enough time to setup the tunnel. > > > >Can you incorporate this explanation, then? > > > >> > >> /Karim > >> > > > >Good, thanks, > >Phil > > > From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 30 14:34:07 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14393 for ; Mon, 30 Jul 2001 14:34:07 -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 LAA00268; Mon, 30 Jul 2001 11:33:57 -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 LAA29685; Mon, 30 Jul 2001 11:29:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6UISEb00679 for mobile-ip-dist; Mon, 30 Jul 2001 11:28:14 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6UISAY00672 for ; Mon, 30 Jul 2001 11:28:10 -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 LAA19000 for ; Mon, 30 Jul 2001 11:28:24 -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 MAA11124 for ; Mon, 30 Jul 2001 12:28:21 -0600 (MDT) Received: by megisto-sql1.megisto.com with Internet Mail Service (5.5.2650.21) id ; Mon, 30 Jul 2001 14:28:09 -0400 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Handover Smoothing - What to Do? Date: Mon, 30 Jul 2001 14:28:03 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) 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: > Hello Phil > HI again, > > Here is the general observation. You are proposing bicasting > > as a solution > > that > > solves only a part of the handover smoothing problem, that is > > the potential > > loss > > of packets in flight between an HA or hierarchical MIP agent > > and an FA or > > AR. > > That's not totally correct and misses an important reason for > bicasting. > If FMIP (let's take FMIPv6) is used without any bicasting, the MN > will receive a proxy advertisement a certain time before an L2 handoff > and it will send a F-BU. From that moment onwards, until the MN moves > to nAR it can't resume communication. The same thing is for FMIPv4. > Does that make sense? So the MN will stay without service for > a certain > period. Instead, by using simultaneous bindings (which we've also > called bicasting) that period of service disruption can be avoided. > This is more than eliminating the loss of packets in flight between > HA or local HA and FA/AR while the MN is about to make the L2 handoff. I half agree with what you've said. There is another case my description didn't cover between the oAR and the nAR. The F-BU is the indication that the oAR should start forwarding packets to the nAR. To the extent that the MN can't come up on the nAR there is a disruption. In this case you are suggesting bicasting to allow the oAR to also send on the old link. (I guess this means the F-BU is not a deterministic indication that the mobile is moving? As an aside this is why I raised the issue of an L2 trigger saying the mobile is no longer reachable here.) The devil is in the details of course. It seems perhaps a strategy in this case is to have the local implementation handle the ambiguity it has on its local link, for those links on which there is ambiguity about the connectivity. > > > Also what I was pointing to is that a buffer is probably needed > > > if the handoff time from oFA to nFA is not negligible (your next > > > case and this case). That's why packet dropping is a MAY. So this > > > case wouldn't happen, unless of course it's not TCP and you don't > > > care about dropping some packets. In fact low latency handoffs are > > > probably most useful for real-time services (e.g. Voice on UDP) > > > in which case, if there's an period of L2 disconnection during > > > handoff, the packets should be dropped. > > > > So here we need some kind of information that describes FA or AR > > behavior wrt duration of the handoff time and whether or not it's > > TCP traffic or something that is realtime traffic. > > Happy to put something in describing the real-time/non > real-time cases. > The idea was to leave this behaviour open and say the nFA MAY buffer > or MAY drop. We could give an example though. > > > > The buffer size should be set such that you don't get duplicates. > > > By the time MN connects to nFA, the second copy of the packet > > > should be dropped out of the FIFO queue/buffer and the next one > > > should be ready for sending to MN. Of course this calculation > > > depends on the l2 handoff characteristics and possibly the wired > > > connectivity between the bicasting point and oFA/nFA. > > > > I agree with this, but I don't know how to do it. Now we > need to add > > to the decision matrix characteristics about the wired connectivity. > > Well, I can agree with putting in some examples as above but we can't > design the system and take the implementor's place. So would some > examples be what you are looking for? There are a few things I'm looking for. One is some sense that this could be made to work. That's personal. Maybe more examples would persuade me. I'd also like to explore what some other options are for smoothing. I see the fast part of handoff as more decoupled from the underlying technology than the smoothing part and it seems it might be more worthwhile to explore how what's done at L3 interacts with L2 for smoothing. That's just my personal opinion. > > > > But still, it doesn't take into account latency within the network. > > Whereas it seems that a receiving station might be able to make some > > intelligent decisions about when it is important to drop a > > packet (because > > it arrived way too late), but now do you want the network in > > between to get > > involved in the measurement and timing of these decisions? > > No measurement is involved by the network. Any buffering is put > in place by the implementor depending on the traffic, network etc. > That has to be done in any case depending on the application. > I wasn't suggesting an on-the-fly calculation. Good. > > > > > Or like this? > > > > The same packet arrives at oFA and is transmitted to the MN > > > > which then moves > > > > to the > > > > nFA and gets the same packet which was delayed on its way > > > to the nFA. > > > > > > That would again need to be handled by a jitter-smoothing > > > buffer at nFA. > > > > OK, but how? A packet arrives at the nFA. How does the nFA > > have any idea > > whether or not it needs to be buffered and then for how long, > > or dropped? > > In > > this case it should be dropped, in the previous case it > > should be dropped, > > and in the first case it should be sent. But the only way I > > know that is by > > knowing what the MN has already received. > > If the jitter-smoothing buffer is put in nFA it will be used. > There's no decision on-the-fly. If instead it is deemed that > the gains in buffering are not worth the memeory/complexity > then we have the case where nFA always drops. It's hard for me to see how to implement a buffer at the nFA to handle this case and if the nFA always drops then we're back to the original case in which bicasting does not solve the problem. (Packet arrives at nFA and oFA while the MN is unreachable via either). This makes me think there might be another solution. > > > > > It seems like there is some coordination needed between the > > > > oFA and the nFA > > > > to > > > > overcome these problems, perhaps a temporary tunnel? But > > > in that case > > > > bicasting from > > > > an HA or a hierarchical FA wouldn't be adding much to it, > > > > would it. > > > > > > Well, I think that having a local central HA would help. > > > Say that oFA and nFA are at an equal distance from the GFA > > > which is the aggregation router between the two. That could > > > alleviate jitter on the fixed network, as has been already > > > mentioned by James. Also, if oFA and nFA happen to be connected > > > to each other through the GFA router, then bicasting at the > > > GFA would be more efficient. > > > > But wait a second. What do you mean by equal distance? Number > > of hops, geographical distance? It has to be transmission time. > > Is this another item we need to add to our decision matrix? > > That's the wired connectivity which you had previously and I assumed > that was the same as transmission time. This would not be considered > in the case I described above, but would be part of the buffer > sizing calculation otherwise. So there's different ways of > implementing > this. Let me make one other point. If the buffer size is dependent on the wired topology does it have to be adjusted as the wired topology changes (due to things like routing updates or congestion) or the AR/FA from which the mobile is coming? > > Overall, you seem to want to understand the details of the buffer > calculation. It's good to discuss this and find any problems, but I > don't think we should document a formula how to calculate buffer > sizes. The people who know the L2 characteristics and the implementors > will know better. The point is that, and I've hopefully come across > with that, bicasting is useful and can work. Otherwise if I haven't > succeeded, too bad :( What I'd really like is to be persuaded that this solves the smoothing problem without introducing any new problems. Right now I believe it doesn't solve the problem and does introduce new problems. I don't know how serious the new problems are, but would like to. > > > So I guess in summary, "I don't buy it," means I'm not convinced by > > your answers. I've given some of my reasons why. > > Hope I've answered some of the questions. What I haven't understood > yet is whether you think it can work but we need to study the details > or whether you think this doesn't work. > > > What I would recommend instead of including bicasting in the > > fast handoff > > drafts for v4 and v6 is a placeholder that describes > > precisely what the > > problem > > is (of lost packets in flight) and that a solution needs to > > be provided. > > The WG > > debates the possible solutions and puts those in a separate draft. > > Well, the problem is not really lost packets in flight. > Anyway, this placeholder would have to be turned into a reference to > the new solution/s ASAP. If not, the FMIP drafts remain incomplete. > That is, they solve the handoff issue but introduce another period > of service disruption. I don't think we can assume that there will > be L2 solutions to this new gap. I would like a smoothing solution quickly as well. Let's be careful. I don't think FMIP introduces a gap that wouldn't be there with MIP already, but is there something I'm missing? I do think the gap is substantially shortened by the fast techniques. That is, after all, what was being attempted. > > > > > Speaking as a working group chair now: > > > > I'm doing a little work to find out whether a solution that > introduces > > duplicate > > packets will be shot down by the IESG right off the bat. It > > seems wise to > > separate the fast from the smooth part, advance the fast, and > > produce a > > solution > > for the smooth later. > > Fast and smooth are tightly linked. So we cannot move Fast on without > having come to some solution for smooth. They should go hand in hand > through standards process, which is why I don't like the idea of > delaying bicasting/buffering for later. I don't agree here. I would like a smoothing solution also and would like to see discussion on this progress. But one of the important cases could be L2 support for smoothing. For such an environment, having fast handoffs with MIP would be a big plus and there is not necessarily demand for smoothing support. > > Rgds > /Karim > Phil From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 30 14:39:11 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14701 for ; Mon, 30 Jul 2001 14:39:11 -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 LAA03098; Mon, 30 Jul 2001 11:39:30 -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 LAA02580; Mon, 30 Jul 2001 11:37:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6UIaf900873 for mobile-ip-dist; Mon, 30 Jul 2001 11:36:41 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6UIaaY00866 for ; Mon, 30 Jul 2001 11:36:37 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id LAA28316 for ; Mon, 30 Jul 2001 11:36:50 -0700 (PDT) Message-Id: <200107301836.LAA28316@heliopolis.eng.sun.com> Date: Mon, 30 Jul 2001 11:36:48 -0700 (PDT) From: James Kempf Subject: RE: [mobile-ip] Handover Smoothing - What to Do? To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Xz84MuOEGwyfwN2puOGMmA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 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: >> Fast and smooth are tightly linked. So we cannot move Fast on without >> having come to some solution for smooth. They should go hand in hand >> through standards process, which is why I don't like the idea of >> delaying bicasting/buffering for later. > >I don't agree here. I would like a smoothing solution also and would >like to see discussion on this progress. But one of the important cases >could be L2 support for smoothing. For such an environment, having fast >handoffs with MIP would be a big plus and there is not necessarily demand >for smoothing support. > Yes, I think this is the key issue. There are some cases where sufficiently tight L2 information on the sequencing of events during handover would render smoothing irrelevent (they may not be common, but nevertheless). On the other hand, nobody is arguing that L2 information will render the FMIP techniques irrelevent, on the contrary. jak From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 30 14:40:10 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14762 for ; Mon, 30 Jul 2001 14:40:09 -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 MAA22757; Mon, 30 Jul 2001 12:40:26 -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 LAA03155; Mon, 30 Jul 2001 11:40:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6UIcWv00940 for mobile-ip-dist; Mon, 30 Jul 2001 11:38:32 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6UIcTY00933 for ; Mon, 30 Jul 2001 11:38:29 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id LAA28414 for ; Mon, 30 Jul 2001 11:38:43 -0700 (PDT) Message-Id: <200107301838.LAA28414@heliopolis.eng.sun.com> Date: Mon, 30 Jul 2001 11:38:41 -0700 (PDT) From: James Kempf Subject: RE: [mobile-ip] comments on low latency handoff draft To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: GJ6j4LXQ3JZVk71H0F4rug== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 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: >> We would, of course, still need to edit to reflect how >> the triggers are used (e.g. using a "Link Down" trigger to >> signal that handoff did, in fact, occur as opposed to that >> handoff is anticipated). > >I didn't see the 2 triggers in opposition, but complementary. > Right, that's what I meant. The low latency draft currently contains a somewhat outdated list of triggers, that doesn't reflect the more recent thinking in draft-manyfolks-mobilereq-l2-00.txt. Link Down is not mentioned. This is one of the reasons I would like to consolodate discussion of L2 triggers there, with references in other drafts as ncessary. >> >> jak >> >From: Phil Roberts >> >To: "'mobile-ip@sunroof.eng.sun.com'" >> >Subject: RE: [mobile-ip] comments on low latency handoff draft >> >Date: Mon, 30 Jul 2001 11:34:52 -0400 >> > >> >Hi, >> > >> > >> >> >> >> > >> >> > On page 5, it says that "[t]he registration process takes >> >> > some non-zero >> >> > time to complete as the Registration Requests propagate >> >> > through the network. >> >> > During this period of time the MN is not able to send or >> receive IP >> >> > packets." I don't follow this. It should be able to >> send if it is >> >> > connected and possibly receive though not at its home address. >> >> >> >> Until the FA has made sure that the user is authorised to use the >> >> network it should not give service to the MN. That means >> that the FA >> >> must wait for the reply. So the MN should neither receive >> nor be able >> >> to transmit. Am I missing something? >> > >> >No, I'd just make what you stated clear in the draft. >> > >> >> >> >> > >> >> > In table 1 is it useful to include a trigger for a link >> >> > down status? >> >> > (IE. I just told the mobile to go somewhere else so you can't >> >> > reach it via >> >> > this link anymore). >> >> >> >> That could be another trigger. What would it be applied to? >> > >> >packet forwarding from the old FA/AR for smoothing. >> > >> >> >> >> > >> >> > On page 9 "no dependence on a wireless L2 technology," >> >> > should probably >> >> > be clarified in the light of the presence of various L2 >> triggers the >> >> > protocols make use of. >> >> >> >> I thought the point of having triggers was to be independent of a >> >> particular wireless standard. By this I mean that the "about to >> >> handoff" trigger comes from different nodes in different wireless >> >> standards but is presented as a single logical trigger to the >> >> receiving entity. Of course not all wireless systems will have >> >> all the triggers. But if the trigger is available it'll be generic. >> >> What were you suggesting? >> > >> >Just that (some of?) the layer 2 triggers themselves while >> abstracted the >> >way you >> >suggest are needed for the methods in this draft. >> > >> > >> >> > On page 11. I don't understand what's being said in >> >> > paragraph 3. "The >> >> > MN performs movement detection upon receipt of either a >> solicited or >> >> > unsolicited RA,...." By movement detection I gather from the >> >> > rest of the >> >> > explanation that it is "possible upcoming movement >> >> > detection?" How does a >> >> > mobile node MIP client know it has actually moved? >> >> >> >> I'm not sure I understand your question. >> >> Are you saying that the MN must know when it actually moves? >> >> What does the MIP client need to do when it finds it has actually >> >> moved? >> > >> >Hey, I'm asking the questions here!!! >> > >> >Seriously, I didn't understand the text and was trying to >> figure out why it >> >was there. >> >Now that I've gone back and read it more closely I >> understand what it's >> >saying. Disregard >> >this question. >> > >> >> >> >> >> >> > On page 15. "the trigger timing SHOULD be arranged such >> >> > that a full L3 >> >> > ...." Hmmm. This seems like a curious requirement. This >> >> > seems more like >> >> > an assumption about the underlying technology. How can we >> >> > specify in *this* >> >> > document how an L2 should be engineered? >> >> >> >> We don't. What we specify is the anticipation of the L3 handoff. >> >> The implementors then need to make sure that the anticipation >> >> time is appropriate for their L2 system. >> > >> >Well, the document uses a SHOULD to specify something that >> is implemented >> >elsewhere rather than in the entities that are making this >> part of it work. >> >I suppose this is ok, but it strikes me as a little strange. >> Stating it >> >as an assumption about how the underlying technology has to >> be engineered >> >for >> >this to work would be another way of doing it. >> > >> >> >> >> > >> >> > On page 17 "... are also useful to support >> >> ping-ponging." should >> >> > probably be reworded. Perhaps "... are also useful to >> >> > support proper L3 >> >> > operation in the presence of ping-pong behavior at L2?" >> >> >> >> OK, but I guess the meaning is clear isn't it? (defined ping-pong >> >> in terminology). >> > >> >You and I know what ping-pong is, or what it is in this >> context, but I'm not >> >sure all readers or reviewers will. >> > >> >> >> >> > >> >> > On page 23 Perhaps it would be possible to elaborate on >> >> > some of the >> >> > specifics to smooth the behavior in the presence of >> >> ping-ponging? I'm >> >> > assuming the nFA gets some traffic and finds out somehow that >> >> > the mobile is >> >> > back on the oFA and starts sending it back? >> >> >> >> It's basically that the ping-pong will cause continuous triggers >> >> and therefore continuous tunnel setups between oFA and nFA. >> >> So yes, traffic gets sent back and forth or just dropped if there >> >> is not enough time to setup the tunnel. >> > >> >Can you incorporate this explanation, then? >> > >> >> >> >> /Karim >> >> >> > >> >Good, thanks, >> >Phil >> > >> From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 30 15:28:17 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17710 for ; Mon, 30 Jul 2001 15:28:16 -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 MAA26167; Mon, 30 Jul 2001 12:28: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 MAA05960; Mon, 30 Jul 2001 12:17:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6UJEf801263 for mobile-ip-dist; Mon, 30 Jul 2001 12:14:41 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6UJEbY01253 for ; Mon, 30 Jul 2001 12:14:37 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA24253 for ; Mon, 30 Jul 2001 12:14:51 -0700 (PDT) Received: from netmail2.alcatel.com (netmail2.alcatel.com [128.251.168.51]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA19722 for ; Mon, 30 Jul 2001 12:14:51 -0700 (PDT) Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6]) by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id OAA13405 for ; Mon, 30 Jul 2001 14:14:51 -0500 (CDT) Received: from usa.alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f6UJEod10371 for ; Mon, 30 Jul 2001 14:14:50 -0500 (CDT) Message-ID: <3B65A33F.B66C7553@usa.alcatel.com> Date: Mon, 30 Jul 2001 14:11:11 -0400 From: Behcet Sarikaya X-Mailer: Mozilla 4.76 [en]C-CCK-MCD BDPjm-Sony3 (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Re:Comments on draft-ietf-mobileip-fast-mipv6-02.txt References: <200107301836.LAA28316@heliopolis.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 The draft: draft-ietf-mobileip-fast-mipv6-02.txt has so many editorial problems including the following: No table of contents. Figures 1-3 captions should end with handover, e.g. Stateless Handover. More importantly section 5.1 on Dad handling should include some text on the links that do not require any DAD such as 3GPP links as per draft-manyfolks-ipv6-cellular-host-00.txt. Regards, -- Behcet From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 30 15:41:29 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA18531 for ; Mon, 30 Jul 2001 15:41:28 -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 NAA11073; Mon, 30 Jul 2001 13:41: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 MAA06152; Mon, 30 Jul 2001 12:41:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6UJcF901381 for mobile-ip-dist; Mon, 30 Jul 2001 12:38:15 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6UJcCY01374 for ; Mon, 30 Jul 2001 12:38:12 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA09785 for ; Mon, 30 Jul 2001 12:38:26 -0700 (PDT) From: Basavaraj.Patil@nokia.com Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA29700 for ; Mon, 30 Jul 2001 12:38:26 -0700 (PDT) Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f6UJcGi19201 for ; Mon, 30 Jul 2001 14:38:28 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Mon, 30 Jul 2001 14:38:12 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.1600); Mon, 30 Jul 2001 14:38:12 -0500 content-class: urn:content-classes:message Subject: RE: [mobile-ip] Re:Comments on draft-ietf-mobileip-fast-mipv6-02.txt Date: Mon, 30 Jul 2001 14:38:12 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF440967DD@daebe007.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [mobile-ip] Re:Comments on draft-ietf-mobileip-fast-mipv6-02.txt X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 Thread-Index: AcEZLhu+Rjn+rIUdEdWJUgAIx6TWpQAAKfQw To: Cc: X-OriginalArrivalTime: 30 Jul 2001 19:38:12.0419 (UTC) FILETIME=[2B545930:01C1192F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f6UJcCY01375 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 Thanks for your comments Behcet. The draft will be be dealing with these and other issues that have been raised by the new editor. If you believe section 5.1 needs additional text, I am sure the editor would be more than happy to receive something from you that clarifies behavior of DAD on specific links. -Basavaraj > > The draft: > draft-ietf-mobileip-fast-mipv6-02.txt > has so many editorial problems including the following: > No table of contents. Figures 1-3 captions should end with > handover, e.g. > Stateless Handover. > More importantly section 5.1 on Dad handling should include > some text on the links > that do not require any DAD such as 3GPP links as per > draft-manyfolks-ipv6-cellular-host-00.txt. > > Regards, > > -- > Behcet > From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 30 15:55:10 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA19549 for ; Mon, 30 Jul 2001 15:55:10 -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 MAA08363; Mon, 30 Jul 2001 12:55: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 MAA08580; Mon, 30 Jul 2001 12:53:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6UJqDg01482 for mobile-ip-dist; Mon, 30 Jul 2001 12:52:13 -0700 (PDT) Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6UJqBY01475 for ; Mon, 30 Jul 2001 12:52: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 PAA07407 for ; Mon, 30 Jul 2001 15:52:24 -0400 (EDT) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id PAA03230 for mobile-ip@sunroof.eng.sun.com; Mon, 30 Jul 2001 15:52:50 -0400 (EDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6UIsDY01219 for ; Mon, 30 Jul 2001 11:54:14 -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 LAA06527 for ; Mon, 30 Jul 2001 11:54:27 -0700 (PDT) Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA23013 for ; Mon, 30 Jul 2001 12:55:56 -0600 (MDT) Received: from inrialpes.fr (glandon.inrialpes.fr [194.199.24.105]) by ebene.inrialpes.fr (8.11.3/8.11.3) with ESMTP id f6UIpbQ26280; Mon, 30 Jul 2001 20:51:37 +0200 (MEST) Message-ID: <3B65AD55.A3068A5E@inrialpes.fr> Date: Mon, 30 Jul 2001 20:54:13 +0200 From: Thierry Ernst Organization: INRIA Rhone-Alpes X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com CC: Charlie Perkins Subject: [mobile-ip] Concerns about draft-mipv6-14 section 4.8 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 Dear all, One of the changes of the MIPv6 draft from version 13 to 14 is the addition of a section "Mobile Routers" (section 4.8) and a new sub-option "Mobile Router Prefix Length" (section 5.5). I have some concerns about these additions that I would like to share with the WG: o I think that more issues are added than solved by this new sub-option: - security (authorization) - How is it processed by the HA and the CNs - How is it used by the HA and the CNs - ... o It does only solve part of the problems already highlighted last year in the WG meetings and in the mailing list o There are a number of other problems that we have not even noticed or at least debated. o what is the exact meaning of "any home address" in section 5.5 ? I think that the support of mobile routers and networks (let's call this "Network Mobility Support") deserves more than a section. Particularly a terminology that defines what we are speaking about and that limits the scope of the problem that could be solve by the MIP spec. would be welcome prior to this. Indeed, I am quite surprised to see a new section that has not previously been discussed nor shared with the people on this mailing list, particularly not with the authors of draft http://www.ietf.org/internet-drafts/draft-ernst-mobileip-v6-network-02.txt. This draft that I wrote highlighted some issues in the MIPv6 specification for "Network Mobility Support". As a result of past discussions, some people have agreed that MIPv6 needs clarifications for the HA to redirect packets to nodes behind the mobile router. This is not clarified in MIPv6-14, a clarification would have made more sense than the addition of a new feature in the WG doc itself. Moreover, my draft has introduced a "Mobile Network Prefix" sub-option that carries the prefix of the mobile network as part of the BU. This BU is sent to both the HA and CNs. Following this proposition, security concerns have been raised, particulalry about authorization. Authorization issues have largely accounted for the delay of the acceptance of my idea. The idea behind the sub-option introduced in MIPv6-14 seems to be taken from my draft, though a bit more limited, since it only carries the prefix length, not the prefix itself. The same authorization (and other security) concerns apply to this new sub-option, particularly when it is sent to CNs. I am quite amazed to see that no one has waved the security flag this time. Problably most people are busy, or have missed this section. Given the fact that "Network Mobility Support" is not yet a working group item and that the problem is not even perceived by the WG, the most immediate result relative to section 4.8 is that the MIPv6 specification may be further delayed. This is something we can not afford. MIPv6 has been delayed long enough, it's not the right moment to introduce new feartures in the MIPv6 document itself. The introduction of new features would in turn introduce potential new holes (particulary securiry holes) that would further delay the spec. for Proposed Standard. My conclusions are: - Section 4.8 and sub-option "Mobile Router Prefix Length" SHOULD be removed from the MIPv6 draft, - modifications to the MIPv6 draft specification MUST be discussed on the mailing list prior to their addition in a WG document, - extensions to the Mobile IPv6 specification, if not discussed on the mailing list, MUST be presented in a separate document, - Network Mobility Support SHOULD NOT be added in the MIPv6 specification itself - it is a distinct problem, it has its own solution IMHO - The problem and the requirements to solve "Network Mobility Support" SHOULD be discussed first. BTW, I have written a new draft "Network Mobility Support in IPv6: Problem Statement and Requirements" http://www.ietf.org/internet-drafts/draft-ernst-mobileip-monetv6-00.txt for the purpose of discussing the last item. If you have interest in this discussion, a post on this mailing list PRIOR to the WG meeting would be more than welcome. Regards, Thierry. -- * mailto:Thierry.Ernst@inrialpes.fr Tel +33 (0) 4 76 61 52 69 * INRIA Rhone-Alpes Projet PLANETE (fax 52 52) * and MOTOROLA Labs Paris * http://www.inrialpes.fr/planete/people/ernst/Welcome.html From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 30 16:19:18 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA21770 for ; Mon, 30 Jul 2001 16:19:17 -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 NAA19077; Mon, 30 Jul 2001 13:18: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 NAA11871; Mon, 30 Jul 2001 13:09:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6UK8aw01581 for mobile-ip-dist; Mon, 30 Jul 2001 13:08:36 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6UK8XY01574 for ; Mon, 30 Jul 2001 13:08:33 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id NAA02757; Mon, 30 Jul 2001 13:08:47 -0700 (PDT) Message-Id: <200107302008.NAA02757@heliopolis.eng.sun.com> Date: Mon, 30 Jul 2001 13:08:46 -0700 (PDT) From: James Kempf Subject: Re: [mobile-ip] Concerns about draft-mipv6-14 section 4.8 To: mobile-ip@sunroof.eng.sun.com Cc: charliep@iprg.nokia.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: k9CBNJ24fB+vWp4hHVScNQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 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: Thierry, I agree with your assessment. There has been concern expressed by outside consumers of MIP about the lack of progress on moving MIPv6 to RFC status. As with certain other recent discussions on the list (viz. fast handoff and smoothing), I think it makes sense here to separate out those technologies which are well understood and which have achieved a certain amount of concensus within the WG from those which are not well understood and have yet to achieve concensus, in the interests of moving MIPv6 to proposed standard. The only issue I can see is making sure there is nothing in the current draft that would either hinder or constrain a mobile networking solution, without putting in explicit support that might have unintended side effects. The draft must be complete within itself for mobile hosts and not put any insurmountable barriers or constraints on solving the mobile network problem. jak >Date: Mon, 30 Jul 2001 20:54:13 +0200 >From: Thierry Ernst >To: mobile-ip@sunroof.eng.sun.com >CC: Charlie Perkins >Subject: [mobile-ip] Concerns about draft-mipv6-14 section 4.8 > >Dear all, > >One of the changes of the MIPv6 draft from version 13 to 14 is the >addition of a section "Mobile Routers" (section 4.8) and a new >sub-option "Mobile Router Prefix Length" (section 5.5). I have some >concerns about these additions that I would like to share with the WG: > >o I think that more issues are added than solved by this new >sub-option: > - security (authorization) > - How is it processed by the HA and the CNs > - How is it used by the HA and the CNs > - ... > >o It does only solve part of the problems already highlighted last year >in the WG meetings and in the mailing list > >o There are a number of other problems that we have not even noticed or >at least debated. > >o what is the exact meaning of "any home address" in section 5.5 ? > > >I think that the support of mobile routers and networks (let's call this >"Network Mobility Support") deserves more than a section. Particularly >a terminology that defines what we are speaking about and that limits >the scope of the problem that could be solve by the MIP spec. would be >welcome prior to this. > >Indeed, I am quite surprised to see a new section that has not >previously been discussed nor shared with the people on this mailing >list, particularly not with the authors of draft >http://www.ietf.org/internet-drafts/draft-ernst-mobileip-v6-network-02.txt. >This draft that I wrote highlighted some issues in the MIPv6 >specification for "Network Mobility Support". As a result of past >discussions, some people have agreed that MIPv6 needs clarifications for >the HA to redirect packets to nodes behind the mobile router. This is >not clarified in MIPv6-14, a clarification would have made more sense >than the addition of a new feature in the WG doc itself. > >Moreover, my draft has introduced a "Mobile Network Prefix" sub-option >that carries the prefix of the mobile network as part of the BU. This >BU is sent to both the HA and CNs. Following this proposition, security >concerns have been raised, particulalry about authorization. >Authorization issues have largely accounted for the delay of the >acceptance of my idea. The idea behind the sub-option introduced in >MIPv6-14 seems to be taken from my draft, though a bit more limited, >since it only carries the prefix length, not the prefix itself. The >same authorization (and other security) concerns apply to this new >sub-option, particularly when it is sent to CNs. I am quite amazed to >see that no one has waved the security flag this time. Problably most >people are busy, or have missed this section. > >Given the fact that "Network Mobility Support" is not yet a working >group item and that the problem is not even perceived by the WG, the >most immediate result relative to section 4.8 is that the MIPv6 >specification may be further delayed. This is something we can not >afford. MIPv6 has been delayed long enough, it's not the right moment to >introduce new feartures in the MIPv6 document itself. The introduction >of new features would in turn introduce potential new holes (particulary >securiry holes) that would further delay the spec. for Proposed >Standard. > >My conclusions are: > >- Section 4.8 and sub-option "Mobile Router Prefix Length" SHOULD be >removed from the MIPv6 draft, > >- modifications to the MIPv6 draft specification MUST be discussed on >the mailing list prior to their addition in a WG document, > >- extensions to the Mobile IPv6 specification, if not discussed on the >mailing list, MUST be presented in a separate document, > >- Network Mobility Support SHOULD NOT be added in the MIPv6 >specification itself - it is a distinct problem, it has its own solution >IMHO > >- The problem and the requirements to solve "Network Mobility Support" >SHOULD be discussed first. > >BTW, I have written a new draft "Network Mobility Support in IPv6: >Problem Statement and Requirements" >http://www.ietf.org/internet-drafts/draft-ernst-mobileip-monetv6-00.txt >for the purpose of discussing the last item. If you have interest in >this discussion, a post on this mailing list PRIOR to the WG meeting >would be more than welcome. > >Regards, >Thierry. > >-- >* mailto:Thierry.Ernst@inrialpes.fr Tel +33 (0) 4 76 61 52 69 >* INRIA Rhone-Alpes Projet PLANETE (fax 52 52) >* and MOTOROLA Labs Paris >* http://www.inrialpes.fr/planete/people/ernst/Welcome.html From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 30 16:46:47 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA23423 for ; Mon, 30 Jul 2001 16:46:46 -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 NAA01715; Mon, 30 Jul 2001 13:47:07 -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 NAA00198; Mon, 30 Jul 2001 13:46:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6UKiBs01761 for mobile-ip-dist; Mon, 30 Jul 2001 13:44:11 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6UKi7Y01754 for ; Mon, 30 Jul 2001 13:44: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 NAA22251 for ; Mon, 30 Jul 2001 13:44:22 -0700 (PDT) Received: from zcars0m9.ca.nortel.com ([47.129.242.157]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA18849 for ; Mon, 30 Jul 2001 14:45:50 -0600 (MDT) Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f6UKhq902173 for ; Mon, 30 Jul 2001 16:43:53 -0400 (EDT) Received: from zrchb200.us.nortel.com by smtprch1.nortel.com; Mon, 30 Jul 2001 15:44:13 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 30 Jul 2001 15:43:57 -0500 Message-ID: <85AA7486A2C1D411BCA20000F8073E4302F85150@crchy271.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Concern over draft-team-mobileip-mipv6-sec-reqts- 00.txt Date: Mon, 30 Jul 2001 15:43:25 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C11938.476CCC20" 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_01C11938.476CCC20 Content-Type: text/plain; charset="iso-8859-1" Michael, You may have a point but please do us the favor of answering these questions: 1> Do you believe that the credentials associated with an SA for node mobility would ALWAYS be the same as the credentials for another SA for an application on two communicating hosts? 2> Can there be more than one ESP header in a single IP packet without tunneling? 3> Has there been any succesful work at changing the answer to question 2 or perhaps defining some new generic multi-purpose IP-layer encryption option perhaps with different properties? 4> Has there been any successful work at changing the fact that a BU can be sent in the same packet as an application PDU? Depending on these answers one might be able to influence consensus one way or the other or even create a better alternative. Answers from others are welcome too. Regards, Glenn ------_=_NextPart_001_01C11938.476CCC20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Concern over = draft-team-mobileip-mipv6-sec-reqts-00.txt

Michael,

You may have a point but please do us the favor of = answering these questions:

1> Do you believe that the credentials associated = with an SA for node mobility would ALWAYS be the same as the = credentials for another SA for an application on two communicating = hosts? 

2> Can there be more than one ESP header in a = single IP packet without tunneling?

3> Has there been any succesful work at changing = the answer to question 2 or perhaps defining some new generic = multi-purpose IP-layer encryption option perhaps with different = properties?

4> Has there been any successful work at changing = the fact that a BU can be sent in the same packet as an application = PDU?

Depending on these answers one might be able to = influence consensus one way or the other or even create a better = alternative.

Answers from others are welcome too.

Regards,

Glenn

------_=_NextPart_001_01C11938.476CCC20-- From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 30 16:49:59 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA23571 for ; Mon, 30 Jul 2001 16:49:58 -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 MAA29459; Mon, 30 Jul 2001 12:14:47 -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 LAA25448; Mon, 30 Jul 2001 11:14:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6UIDNO00460 for mobile-ip-dist; Mon, 30 Jul 2001 11:13:23 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6UIDJY00449 for ; Mon, 30 Jul 2001 11:13:20 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA14961 for ; Mon, 30 Jul 2001 11:13:35 -0700 (PDT) Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA12595 for ; Mon, 30 Jul 2001 11:13:34 -0700 (PDT) Received: from strtio1.cup.hp.com (strtio1.cup.hp.com [15.13.129.245]) by palrel1.hp.com (Postfix) with ESMTP id 5DB171824; Mon, 30 Jul 2001 11:13:33 -0700 (PDT) Received: (from jlau@localhost) by strtio1.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) id LAA29122; Mon, 30 Jul 2001 11:15:19 -0700 (PDT) Date: Mon, 30 Jul 2001 11:15:19 -0700 (PDT) From: Joe Lau Message-Id: <200107301815.LAA29122@strtio1.cup.hp.com> To: pcalhoun@diameter.org Subject: Re: [mobile-ip] Generalized MN-HA and MN-FAKey Reply Extension Cc: charliep@IPRG.nokia.com, jlau@cup.hp.com, mobile-ip@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset=X-roman8 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 Pat, > Also you will notice that the MN-FA AAA subtype does include the missing > lifetime. So, in the AAA case, both the MN-HA and the MN-FA have lifetimes. Yes, I noticed that. I was cusious on why lifetime not placed in the Generalized MN-FA header. And, as Charlie pointed out, the Home Agent may assign different values to the MN-HA and MN-FA session key lifetime? For example, MN-HA key will have a lifetime = MIP-Authorization-Lifetime AVP and the MN-FA key will have a lifetime = Registration lifetime. The HA-FA key will have a lifetime = MIP-Authoriztion-Lifetime. When the MN-FA key's lifetime expired before that of the MN-HA key, the MN will have to request another MN-FA key from the AAAH. Is this the intended scenario ? Another question, let's say there are two MNs who belong to the same Home network (ie. AAAH). Both MNs are visiting the same foreign network controlled by the same FA. Both MNs have requested and got their three pairs of session keys distributed: MN-HA key, MN-FA key, and FA-HA key. Is it possible that the FA-HA keys will have different lifetime or even different key material for these two MNs? In other words, FA-HA keys used by these two MNs are independent of each other? Thanks! Joe Lau > > PatC > On Sun, Jul 29, 2001 at 11:16:45PM -0700, Charlie Perkins wrote: > > > > Hello Joe, > > > > These are generalized key extensions. Subtypes will define more > > data fields. There is a good argument that some specific key > > subtypes of the MN-FA Key Reply extension will NOT have > > a lifetime, because the key will have the same lifetime as the > > Mobile IP registration lifetime. In fact, one could argue that > > this would be the preferred mode of operation for the security > > association between the mobile node and the foreign agent. > > > > The security association between mobile node and home > > agent is clearly different, and the lifetime of that association > > would not typically be controlled by registration factors. > > Since every security associatoin has to have a lifetime, and > > there isn't any likely implicit lifetime, it would be present for > > every subtype, and thus belongs in the generalized extension. > > > > At least that's my understanding! > > > > Regards, > > Charlie P. > > > > > > Regards, > > Charlie P. > > > > > > > > Joe Lau wrote: > > > > > Hello Charlie and Pat, > > > > > > On your latest draft , > > > I am puzzled over the asymmetry between the MN-HA Key Reply Extension > > > and the MN-FA Key Reply Extension. The former has a lifetime field > > > but the latter does not. I understand that the lifetime of the > > > MN-FA Key will come from the Unsolicited MN-FA Key Material From AAA Subtype. > > > > > > But I don't understand why these two keys have to be treated differently > > > as far as how the lifetime is placed. > > > > > > Thanks in advance for your clarification. > > > > > > Regards, > > > > > > Joe Lau > > > From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 30 16:56:23 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA24109 for ; Mon, 30 Jul 2001 16:56:23 -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 NAA02249; Mon, 30 Jul 2001 13:48:07 -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 NAA00300; Mon, 30 Jul 2001 13:46:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6UKjAx01779 for mobile-ip-dist; Mon, 30 Jul 2001 13:45:10 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6UKj5Y01772 for ; Mon, 30 Jul 2001 13:45:06 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA00016 for ; Mon, 30 Jul 2001 13:45:19 -0700 (PDT) From: Basavaraj.Patil@nokia.com Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA02117 for ; Mon, 30 Jul 2001 13:45:17 -0700 (PDT) Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f6UKjJi28408 for ; Mon, 30 Jul 2001 15:45:19 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Mon, 30 Jul 2001 15:45:16 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.1600); Mon, 30 Jul 2001 15:45:15 -0500 content-class: urn:content-classes:message Subject: RE: [mobile-ip] Concern over draft-team-mobileip-mipv6-sec-reqts-00.txt Date: Mon, 30 Jul 2001 15:45:15 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF440967DE@daebe007.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [mobile-ip] Concern over draft-team-mobileip-mipv6-sec-reqts-00.txt X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 Thread-Index: AcEZNdIdz8HUZoUlEdWBSQBQi2X+DwAAQHWg To: Cc: , X-OriginalArrivalTime: 30 Jul 2001 20:45:16.0049 (UTC) FILETIME=[89999010:01C11938] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f6UKj6Y01773 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, I do not believe we are making any constructive progress with this thread here and I would like to request that it not continue any further. We can express our opinions and views without having to get abrasive. Please refrain from making any accusations at individuals who are in the role of editors for specific WG documents. Charlie is the editor of the MIPv6 spec and as editor will only make changes that are agreed upon. If you have concerns about the changes that have been made in the current document, please raise the issue with the chairs or the ADs and we will deal with that. -Basavaraj From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 30 17:03:09 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA24595 for ; Mon, 30 Jul 2001 17:03:09 -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 PAA13427; Mon, 30 Jul 2001 15:02:47 -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 OAA05349; Mon, 30 Jul 2001 14:02:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6UL16f02039 for mobile-ip-dist; Mon, 30 Jul 2001 14:01:06 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6UL13Y02032 for ; Mon, 30 Jul 2001 14:01:03 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA26254 for ; Mon, 30 Jul 2001 14:01:18 -0700 (PDT) From: Basavaraj.Patil@nokia.com Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA06500 for ; Mon, 30 Jul 2001 14:01:17 -0700 (PDT) Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f6UL29I23724 for ; Mon, 30 Jul 2001 16:02:09 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Mon, 30 Jul 2001 16:01:17 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.1600); Mon, 30 Jul 2001 16:01:16 -0500 content-class: urn:content-classes:message Subject: RE: [mobile-ip] Concern over draft-team-mobileip-mipv6-sec-reqts-00.txt Date: Mon, 30 Jul 2001 16:01:16 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF440967DF@daebe007.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [mobile-ip] Concern over draft-team-mobileip-mipv6-sec-reqts-00.txt X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 Thread-Index: AcEZObdqvhDPBYUsEdWpVgBQi2kYTQAAGHpw To: Cc: , X-OriginalArrivalTime: 30 Jul 2001 21:01:17.0139 (UTC) FILETIME=[C6744230:01C1193A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f6UL13Y02033 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 > Yes. I object to pulling IPsec out of the MIPv6 draft and > would like to know how consensus was evaluated for that > change. > > Mike > Thank you. That is all I need to know. I will respond to your query regarding consensus on changes in version-14 in a followup e-mail. -Basavaraj From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 30 17:04:56 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA24739 for ; Mon, 30 Jul 2001 17:04:55 -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 OAA09880; Mon, 30 Jul 2001 14:03:56 -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 NAA04643; Mon, 30 Jul 2001 13:59:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6UKw4k01993 for mobile-ip-dist; Mon, 30 Jul 2001 13:58:04 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6UKw1Y01986 for ; Mon, 30 Jul 2001 13:58:01 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA22655 for ; Mon, 30 Jul 2001 13:58:15 -0700 (PDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA05198 for ; Mon, 30 Jul 2001 13:58:15 -0700 (PDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f6UKwO307145 for ; Mon, 30 Jul 2001 13:58:24 -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 ABH01282; Mon, 30 Jul 2001 13:58:11 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA12349; Mon, 30 Jul 2001 13:58:11 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15205.51811.624815.774684@thomasm-u1.cisco.com> Date: Mon, 30 Jul 2001 13:58:11 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Concern over draft-team-mobileip-mipv6-sec-reqts- 00.txt In-Reply-To: <85AA7486A2C1D411BCA20000F8073E4302F85150@crchy271.us.nortel.com> References: <85AA7486A2C1D411BCA20000F8073E4302F85150@crchy271.us.nortel.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 Glenn Morrow writes: > Michael, > > You may have a point but please do us the favor of answering these > questions: > > 1> Do you believe that the credentials associated with an SA for node > mobility would ALWAYS be the same as the credentials for another SA for an > application on two communicating hosts? Not always. Sometimes though (maybe often even). > 2> Can there be more than one ESP header in a single IP packet without > tunneling? Not to my knowledge. > 3> Has there been any succesful work at changing the answer to question 2 or > perhaps defining some new generic multi-purpose IP-layer encryption option > perhaps with different properties? Not to my knowledge. > > 4> Has there been any successful work at changing the fact that a BU can be > sent in the same packet as an application PDU? Not sure what you're asking here... Are you asking if there's been an implementation of piggybacked BU's? Mike From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 30 17:06:31 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA24864 for ; Mon, 30 Jul 2001 17:06:30 -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 OAA10975; Mon, 30 Jul 2001 14:06:06 -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 NAA03199; Mon, 30 Jul 2001 13:54:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6UKrXv01943 for mobile-ip-dist; Mon, 30 Jul 2001 13:53:33 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6UKrTY01936 for ; Mon, 30 Jul 2001 13:53:29 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA21619 for ; Mon, 30 Jul 2001 13:53:44 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA07151 for ; Mon, 30 Jul 2001 13:53:42 -0700 (PDT) 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 f6UKrpY06507; Mon, 30 Jul 2001 13:53: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 ABH01133; Mon, 30 Jul 2001 13:53:36 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA12346; Mon, 30 Jul 2001 13:53:35 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15205.51535.823948.397611@thomasm-u1.cisco.com> Date: Mon, 30 Jul 2001 13:53:35 -0700 (PDT) To: Cc: , , Subject: RE: [mobile-ip] Concern over draft-team-mobileip-mipv6-sec-reqts-00.txt In-Reply-To: <697DAA22C5004B4596E033803A7CEF440967DE@daebe007.NOE.Nokia.com> References: <697DAA22C5004B4596E033803A7CEF440967DE@daebe007.NOE.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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Basavaraj.Patil@nokia.com writes: > > Folks, > > I do not believe we are making any constructive progress with this > thread > here and I would like to request that it not continue any further. > > We can express our opinions and views without having to get abrasive. > Please refrain from making any accusations at individuals who are in the > role of editors for specific WG documents. As opposed to accusations that by disagreeing with changes as well as agreeing with the statements in the security analysis that you are trying destroy and discredit MIPv6? ::snort:: > Charlie is the editor of the MIPv6 spec and as editor will only make > changes > that are agreed upon. If you have concerns about the changes that have > been > made in the current document, please raise the issue with the chairs or > the ADs > and we will deal with that. Yes. I object to pulling IPsec out of the MIPv6 draft and would like to know how consensus was evaluated for that change. Mike From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 30 18:06:45 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA28935 for ; Mon, 30 Jul 2001 18:06: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 QAA00223; Mon, 30 Jul 2001 16:07: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 PAA29920; Mon, 30 Jul 2001 15:06:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6UM5f302241 for mobile-ip-dist; Mon, 30 Jul 2001 15:05:41 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6UM5bY02231 for ; Mon, 30 Jul 2001 15:05:37 -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 PAA11278 for ; Mon, 30 Jul 2001 15:05:52 -0700 (PDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA29880 for ; Mon, 30 Jul 2001 16:07:20 -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.11.0/8.11.0/WIREfire-1.3) with SMTP id f6UM5nN04725 for ; Tue, 31 Jul 2001 00:05:49 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Tue Jul 31 00:05:49 2001 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 30 Jul 2001 23:59:34 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008B84@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Handover Smoothing - What to Do? Date: Tue, 31 Jul 2001 00:05:43 +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: Hi Phil, > We've made a distinction in our discussions all along between fast and > smooth. To say that the fast handover proposals "don't work" because > they are not smooth seems to be confusing these two issues. > => I was giving an example of where the routing will fail due to the anticipation process introduced in the draft. After all we're soving a routing problem and we donn't want to introduce another problem because of our solution The solution should not introduce new problems. I haven't read your other mail yet, still trying to catch up. Regards, Hesham > > -----Original Message----- > > From: Hesham Soliman (ERA) [mailto:Hesham.Soliman@era.ericsson.se] > > Sent: Monday, July 30, 2001 7:35 AM > > To: 'mobile-ip@sunroof.eng.sun.com' > > Subject: RE: [mobile-ip] Handover Smoothing - What to Do? > > > > > > Hello Rajeev, > > > > > > There are so many mails I hope no one else made the same > > > > comments that I'm about to make. > > > > > > > > > I don't understand your viewpoint. Just because you > > have not heard from > > > > > buffering advocates does not imply that the alternative > > is the way to go. There > > > > > are at least two things to consider. First, you are > > proposing to add a > > > > > particular smoothing technique to FMIPv6. I am > > registering my complaint saying > > > > > that it is not the right thing to do. > > > > > > > > > => You're making a statement that is not backed > > by a reason. See more below. > > > > > > > > > > > > > > On the contrary, I was reasoning that when FMIP can > > progress without having to rely on > > > any particular smoothing technique. > > > > > => See an answer below. > > > > > > > > > FMIPv6 must be able to work independently > > > > > of bicasting. > > > > > > > > > => Why ? > > > > > > > > > > > > > > Why not ? FMIP can work without any dependency. > > > > > => It _does_not. The draft clearly states that there > > are cases (like ping pong) > > where the current solution does not work. We've said this many > > times and it's in the FMIPv6 draft. > > > > > Besides, the smoothing techniques by > > > themselves are not well-understood to be part of a > > standard. I mentioned this (in the > > > same thread somewhere) didn't I ? > > > > > => This is handwaving, I'd prefer if you point out > > specific issues. > > I don't think HC and CT has any role here. Bicasting > > adds nothing > > to the complexity of the HC CT (which is already very complex > > and of unproven value as it is). We can't build a > > solution taking into > > consideration a solution that does not exist or even agreed on. > > > > > > > > > > > Second, taking up smoothing as a > > > > > topic by itself, it is not a foregone conclusion that > > bicasting/simultaneous > > > > > binding are the only means. This is an open area and we > > need discussion and > > > > > *real experimental* evidence. Also, the header > > compression example hold here as > > > > > well. > > > > > > > > > => Well other proposals are also welcome. But I'm > > sure you can appreciate > > > > that new ideas come up all the time, that doesn't > > mean we don't make > > > > any decisions. We have to decide on what we have > > now. Unless you've > > > > done some experiments on bicasting and saw that > > it's bad for some > > > > reason. > > > > > > > > > > We are now talking about handling smoothing techniques on their own. > > > As I mentioned above, this topic by itself needs a lot of > > discussion before we can make > > > decisions. I am not convinced that we can draw definitive > > conclusions on smoothing > > > techniques to progress them on a standardization path. > > > > > => Frnkly I'm not interested in the discussion of documents and > > which doc contains what. I'm more interested in the technical > > > evaluation of a proposal. It seems like people are avoiding > > this topic. > > > > Regards, > > Hesham > > From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 30 18:16:46 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA29623 for ; Mon, 30 Jul 2001 18:16:46 -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 QAA07350; Mon, 30 Jul 2001 16:17:13 -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 PAA02795; Mon, 30 Jul 2001 15:17:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6UMFgG02323 for mobile-ip-dist; Mon, 30 Jul 2001 15:15:42 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6UMFcY02316 for ; Mon, 30 Jul 2001 15:15:38 -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 PAA22871 for ; Mon, 30 Jul 2001 15:15:54 -0700 (PDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA04542 for ; Mon, 30 Jul 2001 16:17:17 -0600 (MDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f6UMFkN06152 for ; Tue, 31 Jul 2001 00:15:46 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Tue Jul 31 00:15:46 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Tue, 31 Jul 2001 00:15:46 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008B85@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Handover Smoothing - What to Do? Date: Tue, 31 Jul 2001 00:15:41 +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: George, Just in case you missed my answer before :) The MN knows if it is in "danger" ofbicasting or not. IE. it knows if TCP MAY be affected or not. If it has the fix it doesn't matter, ifit doesn't it can request bicasting depending on whether it has any TCP connections or not. Note that I'm just going with the assumption that it is bad for TCP which is not proven. I've also pointed to an experiment that was done on the impact of bicasting on TCP (+ve impacts). Hesham > Maybe you have missed this...please see my response to Mike on the same > question... > I feel like a broken record by there you go :-0 > > George > P.S: in your question...what is "infrequent"??? the handoff? I do not think > so.... > > -----Original Message----- > From: George Tsirtsis [mailto:G.Tsirtsis@flarion.com] > Sent: Thursday, July 26, 2001 7:06 PM > To: 'mobile-ip@sunroof.eng.sun.com' > Subject: RE: [mobile-ip] Analysis of Jitter in Bicasting > > > Hi Mike, > > I think you are making the point that - end hosts already deal with > duplicate packets since this is a natural occurrence in the Internet today > so bicasting should not be a problem - > > The difference is that end nodes deal with duplicate packets up to a > point...i.e.: up to 3 re-orderings/losses etc generating 3 dupacks in a row, > before TCP starts having problems. The fact that TCP deals with 3 dupacks > and not with 5 or 10 or 100 was an engineering choice that balances > adaptivity and throughput with the chances of this happening in the Internet > or they just picked a number from thin air...wouldn't know...was not here > :-) > > My argument is that bicasting, increases the chances of duplication on top > of what the Internet naturally does and that could have bad effects if in > widespread use. Say for example, due to natural re-ordering somewhere in the > Internet, a node is about to receive 2 TCP acks, which TCP can actually deal > with no problems. At the same time the MN's packets are duplicated (due to > bicasting) at the receiving end, which results in the MN receiving 4 TCP > acks! This forces TCP to half its window thinking that there must be > congestion in the network and the packets do not get across which is clearly > not the case! > > So, the objections here are not about being able to "deal" with re-ordering > as it naturally occurs but that we should not introduce mechanisms that > artificially increase the chance duplicate acks. > > Regards > George > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Thursday, July 26, 2001 6:34 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: RE: [mobile-ip] Analysis of Jitter in Bicasting > > > Gary Kenward writes: > > > From: James Kempf [mailto:James.Kempf@Sun.COM] > > > In the case of 1, the probability of a duplicate packet has nothing > > > whatsoever to do with the radio link. It is purely a matter of traffic > > > engineering in the wired network. So the probability of a duplicate > > > packet can be reduced by properly engineering the wired network. In > > > addition, the probability is likely to increase with the topological > > > distance between the new AR and the source of the bicast (simply > > > because, the more network a packet has to traverse, the more likely > > > it is that a congestion event may cause delay). Since engineering > > > of the wired network is largely under the network operator's control, > > > this problem is fairly straightforward to solve, though it may > > > require measures such as over provisioning. > > > > Well, it takes more then over provisioning. You need to ensure > > the same number of hops between the bicasting source (the traffic > > bifurcation > > point if you will), and you also need to provide some guaranteed bounds > on > > the delay at each hop after the bicasting source. *if* you want to ensure> > no > > duplicates > > at all at the receiver. This may seem like a definition of EF, but > > consider that the constraint is much more severe then that of EF. With > > EF the bound is on inter-packet delay and delay jitter for a single > stream. > > With bicasting, the bound is on the arrival delay of two copies of the > > same packet that traverse different paths through N hops. The maximum > > delay difference, I believe, is one packet duration, T. Thus, the delay > > difference bound at each hop must roughly be T/N (the relationship is > > not linear, but this gives a rough approximation). If the source of > > the delay is from queuing, then this would imply that there can be > > no other traffic following the same path. E.g. if a bicasted packet > > arrives at an AR and is queued behind a packet that is being served > > (note: served, not queued), from a different packet stream, then > > it receives a delay of roughly T/2. > > I am very, very confused by all of this. Bicasting > at the IP layer would merely result in duplicates > which the transport/application layer would need > to deal with. In fact, it already needs to deal > with dups because IP packets are fairly regularly > duplicated anyway. While it may require some > specific tweaks to TCP (which I assume EIFEL > attempts to provide), I see no reason why one > would want to shield the receiver from this in the > network, nor do I see any reason why it requires a > difference in the per hop behavior in the tunneled > traffic to AR new, or any consideration of number > of hops, etc. The beauty of the end to end principal is > that the receiver just adapts *regardless* of > where the source of the jitter/loss/duplication/etc > came from. Trying to deal with jitter hop-by-hop is akin > to the general X.25 approach to transport which > is if nothing else against the general IP > philosphy of end to end transport. More > pragmatically, dealing with jitter in the network > will almost certainly yield a worse end to end > delay as a single jitter buffer on the receiver. > > Mike > > -----Original Message----- > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > Sent: Monday, July 30, 2001 3:00 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Handover Smoothing - What to Do? > > > > So what's my position on this? It seems that there are fairly obvious > > cases in which bicasting introduces packet duplicates with potentially > > unknown > > effects in the network. It doesn't seem the network agents will have the > > information needed to prevent this from happening. > > Just for clarification, duplicate packets already occur in the network. > > So, why is the possibility of creating duplicates at the edges, during a > handoff - which is infrequent - now become a real problem, when they > already occur in the network without handoffs? > > PatC From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 30 18:34:17 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA00579 for ; Mon, 30 Jul 2001 18:34:16 -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 PAA19770; Mon, 30 Jul 2001 15:34:44 -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 PAA06640; Mon, 30 Jul 2001 15:34:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6UMXKD02421 for mobile-ip-dist; Mon, 30 Jul 2001 15:33:20 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6UMXGY02414 for ; Mon, 30 Jul 2001 15:33:16 -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 PAA06407 for ; Mon, 30 Jul 2001 15:33:30 -0700 (PDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA12209 for ; Mon, 30 Jul 2001 16:34:59 -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.11.0/8.11.0/WIREfire-1.3) with SMTP id f6UMXRN08396 for ; Tue, 31 Jul 2001 00:33:27 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Tue Jul 31 00:33:27 2001 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 31 Jul 2001 00:27:12 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008B86@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Concerns about draft-mipv6-14 section 4.8 Date: Tue, 31 Jul 2001 00:33:22 +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 thoroughly confused by this. I previously made it clear that it would be good to include the mobile networks draft as a WG item and there was some support for this but no final decision. I think that in the interest of moving MIPv6 along rapidly we should try to eliminate significant additions to the specs, especially when there is a requirements draft about to be discussed. Hesham > -----Original Message----- > From: Thierry Ernst [SMTP:thierry.ernst@inrialpes.fr] > Sent: Monday, 30 July 2001 8:54 > To: mobile-ip@sunroof.eng.sun.com > Cc: Charlie Perkins > Subject: [mobile-ip] Concerns about draft-mipv6-14 section 4.8 > > Dear all, > > One of the changes of the MIPv6 draft from version 13 to 14 is the > addition of a section "Mobile Routers" (section 4.8) and a new > sub-option "Mobile Router Prefix Length" (section 5.5). I have some > concerns about these additions that I would like to share with the WG: > > o I think that more issues are added than solved by this new > sub-option: > - security (authorization) > - How is it processed by the HA and the CNs > - How is it used by the HA and the CNs > - ... > > o It does only solve part of the problems already highlighted last year > in the WG meetings and in the mailing list > > o There are a number of other problems that we have not even noticed or > at least debated. > > o what is the exact meaning of "any home address" in section 5.5 ? > > > I think that the support of mobile routers and networks (let's call this > "Network Mobility Support") deserves more than a section. Particularly > a terminology that defines what we are speaking about and that limits > the scope of the problem that could be solve by the MIP spec. would be > welcome prior to this. > > Indeed, I am quite surprised to see a new section that has not > previously been discussed nor shared with the people on this mailing > list, particularly not with the authors of draft > http://www.ietf.org/internet-drafts/draft-ernst-mobileip-v6-network-02.txt. > This draft that I wrote highlighted some issues in the MIPv6 > specification for "Network Mobility Support". As a result of past > discussions, some people have agreed that MIPv6 needs clarifications for > the HA to redirect packets to nodes behind the mobile router. This is > not clarified in MIPv6-14, a clarification would have made more sense > than the addition of a new feature in the WG doc itself. > > Moreover, my draft has introduced a "Mobile Network Prefix" sub-option > that carries the prefix of the mobile network as part of the BU. This > BU is sent to both the HA and CNs. Following this proposition, security > concerns have been raised, particulalry about authorization. > Authorization issues have largely accounted for the delay of the > acceptance of my idea. The idea behind the sub-option introduced in > MIPv6-14 seems to be taken from my draft, though a bit more limited, > since it only carries the prefix length, not the prefix itself. The > same authorization (and other security) concerns apply to this new > sub-option, particularly when it is sent to CNs. I am quite amazed to > see that no one has waved the security flag this time. Problably most > people are busy, or have missed this section. > > Given the fact that "Network Mobility Support" is not yet a working > group item and that the problem is not even perceived by the WG, the > most immediate result relative to section 4.8 is that the MIPv6 > specification may be further delayed. This is something we can not > afford. MIPv6 has been delayed long enough, it's not the right moment to > introduce new feartures in the MIPv6 document itself. The introduction > of new features would in turn introduce potential new holes (particulary > securiry holes) that would further delay the spec. for Proposed > Standard. > > My conclusions are: > > - Section 4.8 and sub-option "Mobile Router Prefix Length" SHOULD be> > removed from the MIPv6 draft, > > - modifications to the MIPv6 draft specification MUST be discussed on > the mailing list prior to their addition in a WG document, > > - extensions to the Mobile IPv6 specification, if not discussed on the > mailing list, MUST be presented in a separate document, > > - Network Mobility Support SHOULD NOT be added in the MIPv6 > specification itself - it is a distinct problem, it has its own solution > IMHO > > - The problem and the requirements to solve "Network Mobility Support" > SHOULD be discussed first. > > BTW, I have written a new draft "Network Mobility Support in IPv6: > Problem Statement and Requirements" > http://www.ietf.org/internet-drafts/draft-ernst-mobileip-monetv6-00.txt > for the purpose of discussing the last item. If you have interest in > this discussion, a post on this mailing list PRIOR to the WG meeting > would be more than welcome. > > Regards, > Thierry. > > -- > * mailto:Thierry.Ernst@inrialpes.fr Tel +33 (0) 4 76 61 52 69 > * INRIA Rhone-Alpes Projet PLANETE (fax 52 52) > * and MOTOROLA Labs Paris > * http://www.inrialpes.fr/planete/people/ernst/Welcome.html From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 30 18:38:36 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA00793 for ; Mon, 30 Jul 2001 18:38:36 -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 QAA21517; Mon, 30 Jul 2001 16:39:12 -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 PAA07800; Mon, 30 Jul 2001 15:38:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6UMbmZ02510 for mobile-ip-dist; Mon, 30 Jul 2001 15:37:48 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6UMbhY02496 for ; Mon, 30 Jul 2001 15:37:43 -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 PAA18338 for ; Mon, 30 Jul 2001 15:37:56 -0700 (PDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA14059 for ; Mon, 30 Jul 2001 16:39:24 -0600 (MDT) Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f6UMbrO06578 for ; Tue, 31 Jul 2001 00:37:53 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Tue Jul 31 00:37:53 2001 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 31 Jul 2001 00:31:38 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008B87@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Concern over draft-team-mobileip-mipv6-sec-reqts- 00.txt Date: Tue, 31 Jul 2001 00:37:47 +0200 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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Mike, While you're answering question (or someone else who knows IPsec better than me), are there any problems foreseen with IPsec if we simply get rid of piggybacking the BUs and send them in separate packets ? I thought not, but would like some confirmation. Thanks, Hesham > -----Original Message----- > From: Michael Thomas [SMTP:mat@cisco.com] > Sent: Monday, 30 July 2001 10:58 > To: mobile-ip@sunroof.eng.sun.com > Subject: RE: [mobile-ip] Concern over draft-team-mobileip-mipv6-sec-reqts- 00.txt > > Glenn Morrow writes: > > Michael, > > > > You may have a point but please do us the favor of answering these > > questions: > > > > 1> Do you believe that the credentials associated with an SA for node > > mobility would ALWAYS be the same as the credentials for another SA for an > > application on two communicating hosts? > > Not always. Sometimes though (maybe often even). > > > 2> Can there be more than one ESP header in a single IP packet without > > tunneling? > > Not to my knowledge. > > > 3> Has there been any succesful work at changing the answer to question 2 or > > perhaps defining some new generic multi-purpose IP-layer encryption option > > perhaps with different properties? > > Not to my knowledge. > > > > 4> Has there been any successful work at changing the fact that a BU can be > > sent in the same packet as an application PDU? > > Not sure what you're asking here... Are you asking if there's > been an implementation of piggybacked BU's? > > Mike From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 30 18:39:00 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA00867 for ; Mon, 30 Jul 2001 18:38:59 -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 QAA21731; Mon, 30 Jul 2001 16:39: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 PAA07839; Mon, 30 Jul 2001 15:39:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6UMbvS02515 for mobile-ip-dist; Mon, 30 Jul 2001 15:37:57 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6UMbhY02497 for ; Mon, 30 Jul 2001 15:37:43 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA18340 for ; Mon, 30 Jul 2001 15:37:57 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA20002 for ; Mon, 30 Jul 2001 15:37:56 -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 PAA18999 for ; Mon, 30 Jul 2001 15:37:56 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6UMbti28330 for ; Mon, 30 Jul 2001 15:37:55 -0700 X-mProtect: Mon, 30 Jul 2001 15:37:55 -0700 Nokia Silicon Valley Messaging Protection Received: from tkniveto.iprg.nokia.com (205.226.2.111, claiming to be "Kniveton.com") by darkstar.iprg.nokia.com(P1.5 smtpdOphjri; Mon, 30 Jul 2001 15:37:53 PDT Message-ID: <3B65E1C2.7E473867@Kniveton.com> Date: Mon, 30 Jul 2001 15:37:54 -0700 From: "T.J. Kniveton" Organization: NOKIA Research 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 Subject: Re: [mobile-ip] Concerns about draft-mipv6-14 section 4.8 References: <3B65AD55.A3068A5E@inrialpes.fr> 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 agree with Thierry here - the discussions on the list and at meetings have shown that there is interest in making mobile prefixes work within the context of MIPv6 handovers. The key phrase here is problem scope -- it should be broken down to a solvable level, and especially limited within the base draft (which I believe was the intention). To make it really work, security issues must be solved first. Which leads us to the question, for MIPv6 expediency's sake, why not leave it as a separate draft? -TJ Thierry Ernst wrote: > > Dear all, > > One of the changes of the MIPv6 draft from version 13 to 14 is the > addition of a section "Mobile Routers" (section 4.8) and a new > sub-option "Mobile Router Prefix Length" (section 5.5). I have some > concerns about these additions that I would like to share with the WG: > > o I think that more issues are added than solved by this new > sub-option: > - security (authorization) > - How is it processed by the HA and the CNs > - How is it used by the HA and the CNs > - ... > > o It does only solve part of the problems already highlighted last year > in the WG meetings and in the mailing list > > o There are a number of other problems that we have not even noticed or > at least debated. > > o what is the exact meaning of "any home address" in section 5.5 ? > > I think that the support of mobile routers and networks (let's call this > "Network Mobility Support") deserves more than a section. Particularly > a terminology that defines what we are speaking about and that limits > the scope of the problem that could be solve by the MIP spec. would be > welcome prior to this. > > Indeed, I am quite surprised to see a new section that has not > previously been discussed nor shared with the people on this mailing > list, particularly not with the authors of draft > http://www.ietf.org/internet-drafts/draft-ernst-mobileip-v6-network-02.txt. > This draft that I wrote highlighted some issues in the MIPv6 > specification for "Network Mobility Support". As a result of past > discussions, some people have agreed that MIPv6 needs clarifications for > the HA to redirect packets to nodes behind the mobile router. This is > not clarified in MIPv6-14, a clarification would have made more sense > than the addition of a new feature in the WG doc itself. > > Moreover, my draft has introduced a "Mobile Network Prefix" sub-option > that carries the prefix of the mobile network as part of the BU. This > BU is sent to both the HA and CNs. Following this proposition, security > concerns have been raised, particulalry about authorization. > Authorization issues have largely accounted for the delay of the > acceptance of my idea. The idea behind the sub-option introduced in > MIPv6-14 seems to be taken from my draft, though a bit more limited, > since it only carries the prefix length, not the prefix itself. The > same authorization (and other security) concerns apply to this new > sub-option, particularly when it is sent to CNs. I am quite amazed to > see that no one has waved the security flag this time. Problably most > people are busy, or have missed this section. > > Given the fact that "Network Mobility Support" is not yet a working > group item and that the problem is not even perceived by the WG, the > most immediate result relative to section 4.8 is that the MIPv6 > specification may be further delayed. This is something we can not > afford. MIPv6 has been delayed long enough, it's not the right moment to > introduce new feartures in the MIPv6 document itself. The introduction > of new features would in turn introduce potential new holes (particulary > securiry holes) that would further delay the spec. for Proposed > Standard. > > My conclusions are: > > - Section 4.8 and sub-option "Mobile Router Prefix Length" SHOULD be > removed from the MIPv6 draft, > > - modifications to the MIPv6 draft specification MUST be discussed on > the mailing list prior to their addition in a WG document, > > - extensions to the Mobile IPv6 specification, if not discussed on the > mailing list, MUST be presented in a separate document, > > - Network Mobility Support SHOULD NOT be added in the MIPv6 > specification itself - it is a distinct problem, it has its own solution > IMHO > > - The problem and the requirements to solve "Network Mobility Support" > SHOULD be discussed first. > > BTW, I have written a new draft "Network Mobility Support in IPv6: > Problem Statement and Requirements" > http://www.ietf.org/internet-drafts/draft-ernst-mobileip-monetv6-00.txt > for the purpose of discussing the last item. If you have interest in > this discussion, a post on this mailing list PRIOR to the WG meeting > would be more than welcome. > > Regards, > Thierry. > > -- > * mailto:Thierry.Ernst@inrialpes.fr Tel +33 (0) 4 76 61 52 69 > * INRIA Rhone-Alpes Projet PLANETE (fax 52 52) > * and MOTOROLA Labs Paris > * http://www.inrialpes.fr/planete/people/ernst/Welcome.html -- T.J. Kniveton Communications Systems Lab Nokia Research Center From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 30 19:47:45 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA03107 for ; Mon, 30 Jul 2001 19:47:44 -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 RAA00640; Mon, 30 Jul 2001 17:48: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 QAA00860; Mon, 30 Jul 2001 16:47:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6UNhbT02725 for mobile-ip-dist; Mon, 30 Jul 2001 16:43:37 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6UNhYY02718 for ; Mon, 30 Jul 2001 16:43: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 QAA00300 for ; Mon, 30 Jul 2001 16:43:48 -0700 (PDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA10530 for ; Mon, 30 Jul 2001 17:45:17 -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.11.0/8.11.0/WIREfire-1.3) with SMTP id f6UNhjN18723 for ; Tue, 31 Jul 2001 01:43:45 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Tue Jul 31 01:43:45 2001 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 31 Jul 2001 01:37:30 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008B8B@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Handover Smoothing - What to Do? Date: Tue, 31 Jul 2001 01:43:40 +0200 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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hello Wolfgang, > to a certain extend, I understand your impatience - > you want to go on with your idea. > But let me, in order to illustrate the gravity of the situation, > develop an analogy: > => Sorry if I appeared impatient, I didn't want to give that impression, the impression I wanted to give was frustration because I think we're discussing secondary issues (like which doc it should go in) or going around in circles on the technical side (like "it's bad for TCP", "but here's a fix", "but it's bad for TCP" !!!! ..etc) I'm not blaming anyone, just hoping that we solve first things first. - Acknowledge that there is a problem (already partially mentioned in FMIPv6) - Agree on a solution > Assume that you have a gun > => OK ! I'm not familiar with them but I'll do my best :) > and you want to shoot a bullet (i.e. data packet) to a target. > If the target is stationary - no problem. > If it is mobile, you have to perform quite complicated computations > which take velocity of bullet > and velocity as well as direction of target into account. > > Since you don't know the latter (neither the former), > => Well the assumption is that we do know where the target is going. This is the assumption in both FMIPv4 and FMIPv6. Otherwise we would have to use multicast. Hold your fire ! > you may take a machine gun which produces > lots of copies of the bullet/packet. > Obviously, this increases the probabilty that you hit the target. > > > Alternatively, you may introduce 'redirection guns' > which intercept your packet > and redirect it to some new position of the target. > Or you may use retardation devices > to hold back the packet if it is too early. > => The problem is exactly that (the redirection). How do you know when to redirect. Once notified (BU), you can not assume that you can immediately redirect. There is a gap here in which the target may still be connected to the oAR or disconnected then came back, or never disconnected at all (failure). > (Maybe, there are acceleration devices, too.) > You may also combine all these mechanisms into 'enhanced machine guns'. > And the final solution would be to 'broadcast' everywhere - > at least one bullet/packet would reach the target in any case. > > Well, you can do that. > However, because of possible collateral damages, > you have to carefully analyze what you are doing. > => Agreed > Where is such an analysis? > => There is a theoritical one in the draft and I've pointed to a practical one earlier. I do agree 100 % with doing as much analysis as possible, however I also like consistency. Inconsistency causes frustration and confusion. For example, where is the analysis that Fast Handoffs will work at all ? More importantly where is the theoritical analysis that contradicts the existing one in the draft ? > Note that an analysis is the harder > the more complicated your mechanism is. > You have to take into account not only velocity and direction of the bullet, > but also the effects of all the intermediate devices. > => This is not something we can do for a standard. We will never be able to analyse all situations for all link layers that exist. System designers need to optimise the "tool sets" provided according to their respective systems. Note also that analysis you mention below is also more relevant to the concept of Fast handoffs in both drafts. > Do you really believe that 'practical tests' are sufficient? > => I think it's a pretty good start. The more the better of course. Regs, Hesham From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 30 20:12:56 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA03609 for ; Mon, 30 Jul 2001 20:12:56 -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 SAA14870; Mon, 30 Jul 2001 18:13:26 -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 RAA24889; Mon, 30 Jul 2001 17:13:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6V0C3M02829 for mobile-ip-dist; Mon, 30 Jul 2001 17:12:03 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.83.130] (may be forged)) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6V0BxY02822 for ; Mon, 30 Jul 2001 17:11:59 -0700 (PDT) Received: from locked (locked.Eng.Sun.COM [129.146.85.189]) by jurassic.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with SMTP id f6V0CES303870 for ; Mon, 30 Jul 2001 17:12:14 -0700 (PDT) Message-Id: <200107310012.f6V0CES303870@jurassic.eng.sun.com> Date: Mon, 30 Jul 2001 17:10:47 -0700 (PDT) From: Mohan Parthasarathy Subject: RE: [mobile-ip] Concern over draft-team-mobileip-mipv6-sec-reqts- 00.txt To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Se3+qCF33pPgVDJUOZiMnQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 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: > > Mike, > > While you're answering question (or someone else who knows > IPsec better than me), are there any problems foreseen with IPsec > if we simply get rid of piggybacking the BUs and send them > in separate packets ? > I thought not, but would like some confirmation. > The only other constraint is that there is no selector for protecting just binding update. IPsec policy allows you to select based on the IPv6 "nxt" headers. In this case, it would be a destination option. But binding update is just one type of such an option. So, all destination options would be protected if you use IPsec as it exists today. Others that were mentioned in the past are : 1) Why only AH ? It is too restrictive. 2) May be there are others.. -mohan > Thanks, > Hesham > > > > -----Original Message----- > > From: Michael Thomas [SMTP:mat@cisco.com] > > Sent: Monday, 30 July 2001 10:58 > > To: mobile-ip@sunroof.eng.sun.com > > Subject: RE: [mobile-ip] Concern over draft-team-mobileip-mipv6-sec-reqts- 00.txt > > > > Glenn Morrow writes: > > > Michael, > > > > > > You may have a point but please do us the favor of answering these > > > questions: > > > > > > 1> Do you believe that the credentials associated with an SA for node > > > mobility would ALWAYS be the same as the credentials for another SA for an > > > application on two communicating hosts? > > > > Not always. Sometimes though (maybe often even). > > > > > 2> Can there be more than one ESP header in a single IP packet without > > > tunneling? > > > > Not to my knowledge. > > > > > 3> Has there been any succesful work at changing the answer to question 2 or > > > perhaps defining some new generic multi-purpose IP-layer encryption option > > > perhaps with different properties? > > > > Not to my knowledge. > > > > > > 4> Has there been any successful work at changing the fact that a BU can be > > > sent in the same packet as an application PDU? > > > > Not sure what you're asking here... Are you asking if there's > > been an implementation of piggybacked BU's? > > > > Mike From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 30 20:20:20 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA03811 for ; Mon, 30 Jul 2001 20:20: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 RAA25911; Mon, 30 Jul 2001 17:20: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 RAA26087; Mon, 30 Jul 2001 17:20:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6V0JGD02889 for mobile-ip-dist; Mon, 30 Jul 2001 17:19:16 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6V0JCY02882 for ; Mon, 30 Jul 2001 17:19:12 -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 RAA06764 for ; Mon, 30 Jul 2001 17:19:27 -0700 (PDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA25309 for ; Mon, 30 Jul 2001 18:20: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.11.0/8.11.0/WIREfire-1.3) with SMTP id f6V0JON24167 for ; Tue, 31 Jul 2001 02:19:24 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Tue Jul 31 02:19:24 2001 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 31 Jul 2001 02:13:09 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008B8F@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Concern over draft-team-mobileip-mipv6-sec-reqts- 00.txt Date: Tue, 31 Jul 2001 02:19:19 +0200 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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > > > While you're answering question (or someone else who knows > > IPsec better than me), are there any problems foreseen with IPsec > > if we simply get rid of piggybacking the BUs and send them > > in separate packets ? > > I thought not, but would like some confirmation. > > > The only other constraint is that there is no selector for protecting > just binding update. IPsec policy allows you to select based on > the IPv6 "nxt" headers. In this case, it would be a destination > option. But binding update is just one type of such an option. > So, all destination options would be protected if you use > IPsec as it exists today. > => Sure but we can have a new type header for it, that is if you can't increase the granulaity of the policies. Is this really a problem ? > > Others that were mentioned in the past are : > > 1) Why only AH ? It is too restrictive. > => Yes, that's another issue. I just wanted to know if there were any show stoppers, it seems like the selectors are the only issue. Hesham > > > > > > > -----Original Message----- > > > From: Michael Thomas [SMTP:mat@cisco.com] > > > Sent: Monday, 30 July 2001 10:58 > > > To: mobile-ip@sunroof.eng.sun.com > > > Subject: RE: [mobile-ip] Concern over > draft-team-mobileip-mipv6-sec-reqts- 00.txt > > > > > > Glenn Morrow writes: > > > > Michael, > > > > > > > > You may have a point but please do us the favor of answering these > > > > questions: > > > > > > > > 1> Do you believe that the credentials associated with an SA for node > > > > mobility would ALWAYS be the same as the credentials for another SA for > an > > > > application on two communicating hosts? > > > > > > Not always. Sometimes though (maybe often even). > > > > > > > 2> Can there be more than one ESP header in a single IP packet without > > > > tunneling? > > > > > > Not to my knowledge. > > > > > > > 3> Has there been any succesful work at changing the answer to question 2 > or > > > > perhaps defining some new generic multi-purpose IP-layer encryption > option > > > > perhaps with different properties? > > > > > > Not to my knowledge. > > > > > > > > 4> Has there been any successful work at changing the fact that a BU > can be > > > > sent in the same packet as an application PDU? > > > > > > Not sure what you're asking here... Are you asking if there's > > > been an implementation of piggybacked BU's? > > > > > > Mike From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 30 20:36:38 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA04229 for ; Mon, 30 Jul 2001 20:36:37 -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 SAA26804; Mon, 30 Jul 2001 18:37: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 RAA09628; Mon, 30 Jul 2001 17:36:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6V0ZaS02979 for mobile-ip-dist; Mon, 30 Jul 2001 17:35:36 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.81.144] (may be forged)) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6V0ZXY02972 for ; Mon, 30 Jul 2001 17:35:33 -0700 (PDT) Received: from locked (locked.Eng.Sun.COM [129.146.85.189]) by jurassic.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with SMTP id f6V0ZlS309932 for ; Mon, 30 Jul 2001 17:35:48 -0700 (PDT) Message-Id: <200107310035.f6V0ZlS309932@jurassic.eng.sun.com> Date: Mon, 30 Jul 2001 17:34:20 -0700 (PDT) From: Mohan Parthasarathy Subject: RE: [mobile-ip] Concern over draft-team-mobileip-mipv6-sec-reqts- 00.txt To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: wjW0QvguRMbVmLUGc8djkg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 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: > > > > > > > > While you're answering question (or someone else who knows > > > IPsec better than me), are there any problems foreseen with IPsec > > > if we simply get rid of piggybacking the BUs and send them > > > in separate packets ? > > > I thought not, but would like some confirmation. > > > > > The only other constraint is that there is no selector for protecting > > just binding update. IPsec policy allows you to select based on > > the IPv6 "nxt" headers. In this case, it would be a destination > > option. But binding update is just one type of such an option. > > So, all destination options would be protected if you use > > IPsec as it exists today. > > > => Sure but we can have a new type header for it, that is > if you can't increase the granulaity of the policies. Is this > really a problem ? > > Are you sure that it is that simple to get a new type header ? I am assuming you meant a new "nxt" header value. > > Others that were mentioned in the past are : > > > > 1) Why only AH ? It is too restrictive. > > > => Yes, that's another issue. I just wanted > to know if there were any show stoppers, it > seems like the selectors are the only issue. > I guess so. I just verified that one could use other forms of key distribution and not just IKE with IPsec. -mohan > Hesham > > > > > > > > > > > -----Original Message----- > > > > From: Michael Thomas [SMTP:mat@cisco.com] > > > > Sent: Monday, 30 July 2001 10:58 > > > > To: mobile-ip@sunroof.eng.sun.com > > > > Subject: RE: [mobile-ip] Concern over > > draft-team-mobileip-mipv6-sec-reqts- 00.txt > > > > > > > > Glenn Morrow writes: > > > > > Michael, > > > > > > > > > > You may have a point but please do us the favor of answering these > > > > > questions: > > > > > > > > > > 1> Do you believe that the credentials associated with an SA for node > > > > > mobility would ALWAYS be the same as the credentials for another SA for > > an > > > > > application on two communicating hosts? > > > > > > > > Not always. Sometimes though (maybe often even). > > > > > > > > > 2> Can there be more than one ESP header in a single IP packet without > > > > > tunneling? > > > > > > > > Not to my knowledge. > > > > > > > > > 3> Has there been any succesful work at changing the answer to question 2 > > or > > > > > perhaps defining some new generic multi-purpose IP-layer encryption > > option > > > > > perhaps with different properties? > > > > > > > > Not to my knowledge. > > > > > > > > > > 4> Has there been any successful work at changing the fact that a BU > > can be > > > > > sent in the same packet as an application PDU? > > > > > > > > Not sure what you're asking here... Are you asking if there's > > > > been an implementation of piggybacked BU's? > > > > > > > > Mike From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 30 20:38:59 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA04265 for ; Mon, 30 Jul 2001 20:38:53 -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 RAA01567; Mon, 30 Jul 2001 17:39: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 RAA09970; Mon, 30 Jul 2001 17:39:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6V0cLG03020 for mobile-ip-dist; Mon, 30 Jul 2001 17:38:21 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6V0cHY03012 for ; Mon, 30 Jul 2001 17:38:17 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA09831 for ; Mon, 30 Jul 2001 17:38:32 -0700 (PDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id RAA18622 for ; Mon, 30 Jul 2001 17:38:32 -0700 (PDT) Received: (qmail 1757 invoked by uid 500); 31 Jul 2001 00:26:41 -0000 Date: Mon, 30 Jul 2001 17:26:41 -0700 From: Pat Calhoun To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Handover Smoothing - What to Do? Message-ID: <20010730172641.D1019@charizard.diameter.org> References: <034BEFD03799D411A59F00508BDF754603008B8B@esealnt448.al.sw.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: <034BEFD03799D411A59F00508BDF754603008B8B@esealnt448.al.sw.ericsson.se>; from Hesham.Soliman@era.ericsson.se on Tue, Jul 31, 2001 at 01:43:40AM +0200 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 Tue, Jul 31, 2001 at 01:43:40AM +0200, Hesham Soliman (ERA) wrote: > => Sorry if I appeared impatient, I didn't want to give > that impression, the impression I wanted to give was > frustration because I think we're discussing secondary > issues (like which doc it should go in) or going around > in circles on the technical side (like "it's bad for TCP", > "but here's a fix", "but it's bad for TCP" !!!! ..etc) > I'm not blaming anyone, just hoping that we solve first > things first. > - Acknowledge that there is a problem (already partially mentioned > in FMIPv6) > - Agree on a solution Sure, but some folks will not agree on a solution because all they see is that bicasting doesn't work because of a problem with TCP that is being addressed. My intention is to try to get that issue out of the way so we can discuss actual solutions. It is rather difficult to discuss solutions, when folks cannot agree that one proposed alternatie is in fact a solution due to some perceived problem PatC From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 30 20:40:16 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA04322 for ; Mon, 30 Jul 2001 20:40:16 -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 SAA28413; Mon, 30 Jul 2001 18:40:43 -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 RAA10280; Mon, 30 Jul 2001 17:40:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6V0daW03054 for mobile-ip-dist; Mon, 30 Jul 2001 17:39:36 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6V0dWY03047 for ; Mon, 30 Jul 2001 17:39:32 -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 RAA10098 for ; Mon, 30 Jul 2001 17:39:42 -0700 (PDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA27879 for ; Mon, 30 Jul 2001 18:39:39 -0600 (MDT) Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f6V0ddO24233 for ; Tue, 31 Jul 2001 02:39:40 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Tue Jul 31 02:39:39 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Tue, 31 Jul 2001 02:39:39 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008B91@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Concern over draft-team-mobileip-mipv6-sec-reqts- 00.txt Date: Tue, 31 Jul 2001 02:39:34 +0200 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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > > > > > > > > > While you're answering question (or someone else who knows > > > > IPsec better than me), are there any problems foreseen with IPsec > > > > if we simply get rid of piggybacking the BUs and send them > > > > in separate packets ? > > > > I thought not, but would like some confirmation. > > > > > > > The only other constraint is that there is no selector for protecting > > > just binding update. IPsec policy allows you to select based on > > > the IPv6 "nxt" headers. In this case, it would be a destination > > > option. But binding update is just one type of such an option. > > > So, all destination options would be protected if you use > > > IPsec as it exists today. > > > > > => Sure but we can have a new type header for it, that is > > if you can't increase the granulaity of the policies. Is this > > really a problem ? > > > > Are you sure that it is that simple to get a new type header ? I am > assuming you meant a new "nxt" header value. > => Yes that's what I meant, sorry for confusing the terminology Hesham > > Hesham > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Michael Thomas [SMTP:mat@cisco.com] > > > > > Sent: Monday, 30 July 2001 10:58 > > > > > To: mobile-ip@sunroof.eng.sun.com > > > > > Subject: RE: [mobile-ip] Concern over > > > draft-team-mobileip-mipv6-sec-reqts- 00.txt > > > > > > > > > > Glenn Morrow writes: > > > > > > Michael, > > > > > > > > > > > > You may have a point but please do us the favor of answering these > > > > > > questions: > > > > > > > > > > > > 1> Do you believe that the credentials associated with an SA for node > > > > > > mobility would ALWAYS be the same as the credentials for another SA > for > > > an > > > > > > application on two communicating hosts? > > > > > > > > > > Not always. Sometimes though (maybe often even). > > > > > > > > > > > 2> Can there be more than one ESP header in a single IP packet > without > > > > > > tunneling? > > > > > > > > > > Not to my knowledge. > > > > > > > > > > > 3> Has there been any succesful work at changing the answer to > question 2 > > > or > > > > > > perhaps defining some new generic multi-purpose IP-layer encryption > > > option > > > > > > perhaps with different properties? > > > > > > > > > > Not to my knowledge. > > > > > > > > > > > > 4> Has there been any successful work at changing the fact that a > BU > > > can be > > > > > > sent in the same packet as an application PDU? > > > > > > > > > > Not sure what you're asking here... Are you asking if there's > > > > > been an implementation of piggybacked BU's? > > > > > > > > > > Mike From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 30 20:43:56 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA04486 for ; Mon, 30 Jul 2001 20:43: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 SAA00009; Mon, 30 Jul 2001 18:44: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 RAA11095; Mon, 30 Jul 2001 17:44:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6V0hPS03148 for mobile-ip-dist; Mon, 30 Jul 2001 17:43:25 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6V0hLY03141 for ; Mon, 30 Jul 2001 17:43:22 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA20785 for ; Mon, 30 Jul 2001 17:43:36 -0700 (PDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA20413 for ; Mon, 30 Jul 2001 17:43:34 -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.11.0/8.11.0/WIREfire-1.3) with SMTP id f6V0hXN26925 for ; Tue, 31 Jul 2001 02:43:33 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Tue Jul 31 02:43:33 2001 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 31 Jul 2001 02:37:18 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008B92@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Handover Smoothing - What to Do? Date: Tue, 31 Jul 2001 02:43:21 +0200 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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > On Tue, Jul 31, 2001 at 01:43:40AM +0200, Hesham Soliman (ERA) wrote: > > => Sorry if I appeared impatient, I didn't want to give > > that impression, the impression I wanted to give was > > frustration because I think we're discussing secondary > > issues (like which doc it should go in) or going around > > in circles on the technical side (like "it's bad for TCP", > > "but here's a fix", "but it's bad for TCP" !!!! ..etc) > > I'm not blaming anyone, just hoping that we solve first > > things first. > > - Acknowledge that there is a problem (already partially mentioned > > in FMIPv6) > > - Agree on a solution > > Sure, but some folks will not agree on a solution because all they > see is that bicasting doesn't work because of a problem with TCP that > is being addressed. My intention is to try to get that issue out of > the way so we can discuss actual solutions. > => I hope you succeed ! I don't know what more can be said about that. > It is rather difficult to discuss solutions, when folks cannot agree > that one proposed alternatie is in fact a solution due to some > perceived problem > => Can't agree more. "Perceived" is the keyword here. Hesham From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 30 20:47:01 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA04640 for ; Mon, 30 Jul 2001 20:47:00 -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 SAA01540; Mon, 30 Jul 2001 18:47:35 -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 RAA11720; Mon, 30 Jul 2001 17:47:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6V0kBp03214 for mobile-ip-dist; Mon, 30 Jul 2001 17:46:11 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6V0k8Y03207 for ; Mon, 30 Jul 2001 17:46:08 -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 RAA21177 for ; Mon, 30 Jul 2001 17:46:23 -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 SAA00915 for ; Mon, 30 Jul 2001 18:46: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 RAA01888 for ; Mon, 30 Jul 2001 17:46:21 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6V0kLT26537 for ; Mon, 30 Jul 2001 17:46:21 -0700 X-mProtect: Mon, 30 Jul 2001 17:46:21 -0700 Nokia Silicon Valley Messaging Protection Received: from vijayd.iprg.nokia.com (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpditoBdp; Mon, 30 Jul 2001 17:46:19 PDT Message-ID: <3B65FFDB.65150A96@iprg.nokia.com> Date: Mon, 30 Jul 2001 17:46:19 -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: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Concern over draft-team-mobileip-mipv6-sec-reqts-00.txt References: <034BEFD03799D411A59F00508BDF754603008B8F@esealnt448.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, take a look at this. http://www.ietf.org/proceedings/01mar/ietf50-91.htm#TopOfPage look at Jeff Schiller's comments. vijay "Hesham Soliman (ERA)" wrote: > > > > > > > While you're answering question (or someone else who knows > > > IPsec better than me), are there any problems foreseen with IPsec > > > if we simply get rid of piggybacking the BUs and send them > > > in separate packets ? > > > I thought not, but would like some confirmation. > > > > > The only other constraint is that there is no selector for protecting > > just binding update. IPsec policy allows you to select based on > > the IPv6 "nxt" headers. In this case, it would be a destination > > option. But binding update is just one type of such an option. > > So, all destination options would be protected if you use > > IPsec as it exists today. > > > => Sure but we can have a new type header for it, that is > if you can't increase the granulaity of the policies. Is this > really a problem ? > > > > Others that were mentioned in the past are : > > > > 1) Why only AH ? It is too restrictive. > > > => Yes, that's another issue. I just wanted > to know if there were any show stoppers, it > seems like the selectors are the only issue. > > Hesham > > > > > > > > > > > -----Original Message----- > > > > From: Michael Thomas [SMTP:mat@cisco.com] > > > > Sent: Monday, 30 July 2001 10:58 > > > > To: mobile-ip@sunroof.eng.sun.com > > > > Subject: RE: [mobile-ip] Concern over > > draft-team-mobileip-mipv6-sec-reqts- 00.txt > > > > > > > > Glenn Morrow writes: > > > > > Michael, > > > > > > > > > > You may have a point but please do us the favor of answering these > > > > > questions: > > > > > > > > > > 1> Do you believe that the credentials associated with an SA for node > > > > > mobility would ALWAYS be the same as the credentials for another SA for > > an > > > > > application on two communicating hosts? > > > > > > > > Not always. Sometimes though (maybe often even). > > > > > > > > > 2> Can there be more than one ESP header in a single IP packet without > > > > > tunneling? > > > > > > > > Not to my knowledge. > > > > > > > > > 3> Has there been any succesful work at changing the answer to question 2 > > or > > > > > perhaps defining some new generic multi-purpose IP-layer encryption > > option > > > > > perhaps with different properties? > > > > > > > > Not to my knowledge. > > > > > > > > > > 4> Has there been any successful work at changing the fact that a BU > > can be > > > > > sent in the same packet as an application PDU? > > > > > > > > Not sure what you're asking here... Are you asking if there's > > > > been an implementation of piggybacked BU's? > > > > > > > > Mike From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 30 20:47:07 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA04651 for ; Mon, 30 Jul 2001 20:47:07 -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 NAA15220; Mon, 30 Jul 2001 13:10:30 -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 NAA11195; Mon, 30 Jul 2001 13:06:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6UK48N01556 for mobile-ip-dist; Mon, 30 Jul 2001 13:04:08 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6UK45Y01549 for ; Mon, 30 Jul 2001 13:04:05 -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 NAA10783 for ; Mon, 30 Jul 2001 13:04:19 -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 OAA27597 for ; Mon, 30 Jul 2001 14:04:17 -0600 (MDT) 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 f6UK4Mg28882; Mon, 30 Jul 2001 13:04:22 -0700 (PDT) Received: from thomasm-u1.cisco.com ([128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ABE00206; Mon, 30 Jul 2001 13:04:15 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA12335; Mon, 30 Jul 2001 13:03:29 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15205.48529.779861.234981@thomasm-u1.cisco.com> Date: Mon, 30 Jul 2001 13:03:29 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Cc: Michael Thomas Subject: Re: [mobile-ip] Concern over draft-team-mobileip-mipv6-sec-reqts-00.txt In-Reply-To: <3B625B5B.37D83B7D@iprg.nokia.com> References: <3B61C80D.4DA456B0@iprg.nokia.com> <15201.51986.555615.673177@thomasm-u1.cisco.com> <3B61D678.CA0C67AB@iprg.nokia.com> <15201.58214.80975.246707@thomasm-u1.cisco.com> <3B621A1B.EECE6DAE@iprg.nokia.com> <15202.13525.495386.619084@thomasm-u1.cisco.com> <3B625B5B.37D83B7D@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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Charlie Perkins writes: > I use these when I am speaking for myself and > trying to counter your personal accusations. It must be very convenient for you to trot out this personal offense nonsense instead of replying to substance of my posts. > As co-author of the specification, which was in Last Call, > it is my job to try to fix problems with the specification, > and since it is a working group document, I follow > working group consensus when determining a solution. > If something needs to be changed, let's change it. Is it your claim that there was working group consensus to remove IPsec from the draft? > Well, that was my understanding from the last working > group meeting in Minneapolis, and it seems to have been > shared by other people too. You are saying there is > disagreement. That means the discussion isn't over. I have yet to see any *disagreement* that IPsec not be used in some cases (HA/MN, some MN/CN). Yet the use of IPsec was removed from the -14 draft. > > I have made literally dozens of posts on this subject > > and if this is your simplistic take on my view of this > > matter you are either unwilling or unable to grasp > > what is at issue here. I have *never* said that I > > think that IPsec is inappropriate in all circumstances > > and I challenge you to find where I have said so. > > I didn't put those words in your mouth. I just said that > I don't remember you offering any support for keeping IPsec > last year. That does not at all mean that I knew what your > real position was. I have stated quite plainly in many posts what my position on the use of IPsec is. Many were in response to posts you made. I cannot force you to read them, but for you to say that I have not voiced support is verifyably false. And your accusation of my trying to "discredit" mobile ipv6 is a load of whooey, and is not supported by the long list of posts -- not to mention two drafts -- that I've done. > > I have said that I'd prefer ESP over AH, but again if > > that leads you to believe that I don't support use > > of IPsec in some situations, then you are clearly > > not grasping the subtleties here. > > bzzt. Bzzt, what? I do not see how you could come to the conclusions you have if you were a) paying attention, and b) able to properly subdivide the different aspect of the problem. For this, I get awarded the Charlie Perkins MIPv6 Destroyer Award. > > Yet, and there was no list consensus to do so, and this > > is the result. > > ...? That means that you changed a major aspect of the spec -- not just an editorial nit, etc -- without working group consensus. You don't see a problem here? > If a Binding Update needs to be authenticated using > algorithm X, and AH says to use algorithm Y, then there > would be a problem. I don't view this as serious. You can always have multiple SA's with different selectors for different 5-tuples. This is not a problem. > The reqs draft says that Mobile IPv6 is vulnerable to > misuse from unauthenticated Binding Updates. > Mobile IPv6 says that unauthenticated Binding Updates > have to be ignored. The claimed vulnerability does > not exist by the rules of the the Mobile IPv6 spec. > It would exist by other rules, sure. This is a very > serious issue. The spec may say that they must be ignored, but it does not provide a workable method for how a node determines that they are unauthenticated Thus the analysis states the situation correctly. > > So do tell, Charlie: what *was* the purpose of > > your "please tone it down" request? You are the > > *only* person who has disputed their findings. > > My purpose was to suggest improvements to the draft. > I believe that the draft is misleading insofar as it might > lead one to believe that Mobile IPv6 has a problem with > allowing nodes to accept unauthenticated Binding Updates. > Mobile IPv6 specifies that such behavior is illegal, thus > avoiding the vulnerability. But the spec *does* have the claimed vulnerabilities, regardless of your wanting to downplay them, or saying that an incomplete and unanalyzed revision fixes all of the problems. > > Also: it is rather disingenuous to argue with them > > after the fact since their analysis was made on the > > -13 draft. The -14 draft, until a week ago or so, was not > > available to them or anybody else to comment on. > > Their analysis of the -13 draft was pretty spot > > on from what I can tell, and it's completely unclear > > whether -14 -- which hasn't incorporated any > > feedback from the working group -- is any > > better. > > Their analysis is equally valid for drafts 13 and 14. > Draft 14 is not appreciably better from the standpoint > of specifying any way of establishing keys. This is *completely* false. The current draft has *no* means of using IKE or KINK! That in my mind is appreciably *worse*! > One unvarnished truth is that Binding Updates have to be > authenticated, and the honest evaluation is that Mobile IPv6 > doesn't currently suffer from the claimed vulnerabililty. Honest evaluation by whom? Certainly not the authors of the analysis draft. > Another unvarnished truth > is that your postings to this mailing list are insulting, > unconstructive, ignore or twist my words, and lately have > been a waste of my time. If you expect me or anybody else to just roll over while you try to get the authors to soft peddle their message, I am delighted that you are insulted because you deserve to be insulted for such a sleazy request. > Further, as much as I dislike your > way of insulting me, I have not intentionally insulted you. Well, I dislike your trying turn technical disagreements into a faux-personal afront to shift the subject. It's an extremely dishonest debating tactic. Mike From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 31 00:07:52 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA15888 for ; Tue, 31 Jul 2001 00:07:52 -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 VAA14048; Mon, 30 Jul 2001 21:08: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 VAA02276; Mon, 30 Jul 2001 21:06:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6V45ZO03500 for mobile-ip-dist; Mon, 30 Jul 2001 21:05:35 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6V45VY03493 for ; Mon, 30 Jul 2001 21:05:31 -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 VAA02221 for ; Mon, 30 Jul 2001 21:05:46 -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 WAA14374 for ; Mon, 30 Jul 2001 22:05: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 VAA14952; Mon, 30 Jul 2001 21:05:41 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6V45fj30558; Mon, 30 Jul 2001 21:05:41 -0700 X-mProtect: Mon, 30 Jul 2001 21:05:41 -0700 Nokia Silicon Valley Messaging Protection Received: from maxdialin14.iprg.nokia.com (205.226.20.244, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdDxniV5; Mon, 30 Jul 2001 21:05:36 PDT Message-ID: <3B662EAB.EE182C21@iprg.nokia.com> Date: Mon, 30 Jul 2001 21:06:03 -0700 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Michael Thomas CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Concern over draft-team-mobileip-mipv6-sec-reqts-00.txt References: <3B61C80D.4DA456B0@iprg.nokia.com> <15201.51986.555615.673177@thomasm-u1.cisco.com> <3B61D678.CA0C67AB@iprg.nokia.com> <15201.58214.80975.246707@thomasm-u1.cisco.com> <3B621A1B.EECE6DAE@iprg.nokia.com> <15202.13525.495386.619084@thomasm-u1.cisco.com> <3B625B5B.37D83B7D@iprg.nokia.com> <15205.48529.779861.234981@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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Here's a technical point... >> The reqs draft says that Mobile IPv6 is vulnerable to >> misuse from unauthenticated Binding Updates. >> Mobile IPv6 says that unauthenticated Binding Updates >> have to be ignored. The claimed vulnerability does >> not exist by the rules of the the Mobile IPv6 spec. >> It would exist by other rules, sure. This is a very >> serious issue. > The spec may say that they must be ignored, but it > does not provide a workable method for how a node > determines that they are unauthenticated Thus the > analysis states the situation correctly. If a node has no security association with a mobile node, it cannot authenticate the Binding Update and it must be ignored. What else needs to be said? I don't think this is at all ambiguous. Thus, it is not correct to characterize Mobile IPv6 as suffering from this vulnerability. The rest of the note doesn't have any technical discussion, but for those who insist on not skipping it, I'll supply some other sorts of corrections. ===================================== Michael Thomas wrote: > Charlie Perkins writes: > > I use these when I am speaking for myself and > > trying to counter your personal accusations. > > It must be very convenient for you to trot out > this personal offense nonsense instead of > replying to substance of my posts. I found your posts personally offensive. Nevertheless I have tried to respond to the technical substance of your posts. > > As co-author of the specification, which was in Last Call, > > it is my job to try to fix problems with the specification, > > and since it is a working group document, I follow > > working group consensus when determining a solution. > > If something needs to be changed, let's change it. > > Is it your claim that there was working group > consensus to remove IPsec from the draft? My claim is that I believe the last two working group meetings clearly indicated the need to do exactly that. Given the recent situation, I don't think we have consensus for either position at the current time. > > Well, that was my understanding from the last working > > group meeting in Minneapolis, and it seems to have been > > shared by other people too. You are saying there is > > disagreement. That means the discussion isn't over. > > I have yet to see any *disagreement* that IPsec > not be used in some cases (HA/MN, some MN/CN). Yet > the use of IPsec was removed from the -14 draft. I guess that Vijay's pointer supplied something that you might wish to consider. > > > I have made literally dozens of posts on this subject > > > and if this is your simplistic take on my view of this > > > matter you are either unwilling or unable to grasp > > > what is at issue here. I have *never* said that I > > > think that IPsec is inappropriate in all circumstances > > > and I challenge you to find where I have said so. > > > > I didn't put those words in your mouth. I just said that > > I don't remember you offering any support for keeping IPsec > > last year. That does not at all mean that I knew what your > > real position was. > > I have stated quite plainly in many posts what my > position on the use of IPsec is. Many were in response > to posts you made. I cannot force you to read them, > but for you to say that I have not voiced support is > verifyably false. And your accusation of my > trying to "discredit" mobile ipv6 is a load of > whooey, and is not supported by the long list > of posts -- not to mention two drafts -- that > I've done. Yes you have. And no-one would claim that you have failed to recently support the continued use of IPsec. I was talking about last year, and just that I didn't remember you supporting my attempts to retain IPsec. Maybe you did and I didn't remember. And I did not claim that you have tried to discredit Mobile IPv6, merely all the work I have tried to do on it recently. > > > I have said that I'd prefer ESP over AH, but again if > > > that leads you to believe that I don't support use > > > of IPsec in some situations, then you are clearly > > > not grasping the subtleties here. > > > > bzzt. > > Bzzt, what? I do not see how you could come to > the conclusions you have if you were a) paying > attention, and b) able to properly subdivide > the different aspect of the problem. For this, > I get awarded the Charlie Perkins MIPv6 > Destroyer Award. Which of my conclusions were wrong? And I did not claim you were the Mobile IPv6 destroyer, but instead that you made many attempts to discredit my attempts to resolve difficulties with authenticating Binding Updates. > > > Yet, and there was no list consensus to do so, and this > > > is the result. > > > > ...? > > That means that you changed a major aspect of > the spec -- not just an editorial nit, etc -- > without working group consensus. You don't see > a problem here? I could not parse your sentence. Do I have to say more? > > My purpose was to suggest improvements to the draft. > > I believe that the draft is misleading insofar as it might > > lead one to believe that Mobile IPv6 has a problem with > > allowing nodes to accept unauthenticated Binding Updates. > > Mobile IPv6 specifies that such behavior is illegal, thus > > avoiding the vulnerability. > > But the spec *does* have the claimed vulnerabilities, > regardless of your wanting to downplay them, or saying > that an incomplete and unanalyzed revision fixes all > of the problems. Problems can be fixed, and of course I wouldn't claim that the specification is problem free. Constructive dialog is needed. I maintain that the specification doesn't have the particular vulnerability that I previously wrote about. Instead of writing notes like this to counter false (and overtly personal) charges, I'd rather have the constructive dialog. > > Their analysis is equally valid for drafts 13 and 14. > > Draft 14 is not appreciably better from the standpoint > > of specifying any way of establishing keys. > > This is *completely* false. The current draft has *no* > means of using IKE or KINK! That in my mind is appreciably > *worse*! ? O.K. You think it's worse. I guess we've established that. > > One unvarnished truth is that Binding Updates have to be > > authenticated, and the honest evaluation is that Mobile IPv6 > > doesn't currently suffer from the claimed vulnerabililty. > > Honest evaluation by whom? Certainly not the authors of > the analysis draft. It's my honest evaluation, and I am trying to make the case. So far, there haven't been too many other people addressing this point, and I don't see any merit in your position. > > Another unvarnished truth > > is that your postings to this mailing list are insulting, > > unconstructive, ignore or twist my words, and lately have > > been a waste of my time. > > If you expect me or anybody else to just roll > over while you try to get the authors to soft > peddle their message, I am delighted that you > are insulted because you deserve to be insulted > for such a sleazy request. I continue to try to explain that Mobile IPv6 does not suffer from that particular vulnerability. I again find your words to be insulting, non-constructive, and unfit for proper discourse. If a node CANNOT accept an unauthenticated Binding Update, you have no reason to claim that such a thing can threaten a node. > > Further, as much as I dislike your > > way of insulting me, I have not intentionally insulted you. > > Well, I dislike your trying turn technical > disagreements into a faux-personal afront to shift > the subject. It's an extremely dishonest debating > tactic. I'll bet that everyone reading these notes would believe that you have intentionally been insulting to me. Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 31 03:21:06 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA08587 for ; Tue, 31 Jul 2001 03:21:06 -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 BAA25909; Tue, 31 Jul 2001 01:21: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 AAA05047; Tue, 31 Jul 2001 00:21:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6V7K6903812 for mobile-ip-dist; Tue, 31 Jul 2001 00:20:06 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6V7K3Y03805 for ; Tue, 31 Jul 2001 00:20:03 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA16234 for ; Tue, 31 Jul 2001 00:20:17 -0700 (PDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA10239 for ; Tue, 31 Jul 2001 00:20:16 -0700 (PDT) Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f6V7KFO12692 for ; Tue, 31 Jul 2001 09:20:15 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Tue Jul 31 09:20:15 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Tue, 31 Jul 2001 09:20:15 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008B94@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Concern over draft-team-mobileip-mipv6-sec-reqts- 00.txt Date: Tue, 31 Jul 2001 09:20:05 +0200 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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Vijay, > take a look at this. > > http://www.ietf.org/proceedings/01mar/ietf50-91.htm#TopOfPage > > look at Jeff Schiller's comments. > => My point is this: - If we disallow piggybacking, - develop some other key exchange mechnism (like BAKE or one of Mike's proposals) Then I don't see why we can't use IPsec provided that the granularity of the IPsec selectors is fixed. Seems like an implementation issue (the policy part). Have I missed something ? Hesham > "Hesham Soliman (ERA)" wrote: > > > > > > > > > > While you're answering question (or someone else who knows > > > > IPsec better than me), are there any problems foreseen with IPsec > > > > if we simply get rid of piggybacking the BUs and send them > > > > in separate packets ? > > > > I thought not, but would like some confirmation. > > > > > > > The only other constraint is that there is no selector for protecting > > > just binding update. IPsec policy allows you to select based on > > > the IPv6 "nxt" headers. In this case, it would be a destination > > > option. But binding update is just one type of such an option. > > > So, all destination options would be protected if you use > > > IPsec as it exists today. > > > > > => Sure but we can have a new type header for it, that is > > if you can't increase the granulaity of the policies. Is this > > really a problem ? > > > > > > Others that were mentioned in the past are : > > > > > > 1) Why only AH ? It is too restrictive. > > > > > => Yes, that's another issue. I just wanted > > to know if there were any show stoppers, it > > seems like the selectors are the only issue. > > > > Hesham > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Michael Thomas [SMTP:mat@cisco.com] > > > > > Sent: Monday, 30 July 2001 10:58 > > > > > To: mobile-ip@sunroof.eng.sun.com > > > > > Subject: RE: [mobile-ip] Concern over > > > draft-team-mobileip-mipv6-sec-reqts- 00.txt > > > > > > > > > > Glenn Morrow writes: > > > > > > Michael, > > > > > > > > > > > > You may have a point but please do us the favor of answering these > > > > > > questions: > > > > > > > > > > > > 1> Do you believe that the credentials associated with an SA for node > > > > > > mobility would ALWAYS be the same as the credentials for another SA for > > > an > > > > > > application on two communicating hosts? > > > > > > > > > > Not always. Sometimes though (maybe often even). > > > > > > > > > > > 2> Can there be more than one ESP header in a single IP packet without > > > > > > tunneling? > > > > > > > > > > Not to my knowledge. > > > > > > > > > > > 3> Has there been any succesful work at changing the answer to question 2 > > > or > > > > > > perhaps defining some new generic multi-purpose IP-layer encryption > > > option > > > > > > perhaps with different properties? > > > > > > > > > > Not to my knowledge. > > > > > > > > > > > > 4> Has there been any successful work at changing the fact that a BU > > > can be > > > > > > sent in the same packet as an application PDU? > > > > > > > > > > Not sure what you're asking here... Are you asking if there's > > > > > been an implementation of piggybacked BU's? > > > > > > > > > > Mike From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 31 03:38:22 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA08799 for ; Tue, 31 Jul 2001 03:38:21 -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 AAA23242; Tue, 31 Jul 2001 00:38: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 AAA06746; Tue, 31 Jul 2001 00:38:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6V7YEJ04041 for mobile-ip-dist; Tue, 31 Jul 2001 00:34:14 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6V7YAY04030 for ; Tue, 31 Jul 2001 00:34:10 -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 AAA17759 for ; Tue, 31 Jul 2001 00:34:09 -0700 (PDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA14173 for ; Tue, 31 Jul 2001 01:35:40 -0600 (MDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id f6V7Y6O20712; Tue, 31 Jul 2001 09:34:06 +0200 (MEST) Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.38.50]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f6V7Y5504717; Tue, 31 Jul 2001 10:34:06 +0300 (EET DST) Message-ID: <3B665F6D.AE6836DB@lmf.ericsson.se> Date: Tue, 31 Jul 2001 10:34:05 +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: Hesham.Soliman@era.ericsson.se, charliep@iprg.nokia.com, mat@cisco.com CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Concern over draft-team-mobileip-mipv6-sec-reqts-00.txt References: <034BEFD03799D411A59F00508BDF754603008B8F@esealnt448.al.sw.ericsson.se> <3B65FFDB.65150A96@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 Hesham wrote: >While you're answering question (or someone else who knows >IPsec better than me), are there any problems foreseen with IPsec >if we simply get rid of piggybacking the BUs and send them >in separate packets ? >I thought not, but would like some confirmation. >... >Seems like an implementation issue (the policy part). Assuming BUs are in separate packets and that a new next header value is allocated for them, I see no problems in using AH. With today's RFCs and products. Of course, we must remember to keep separate the packet protection and the key management problems. The minutes from IETF #50 that Vijay referred to discussed mostly the key management issues. It seems very clear that there is working group consensus on that BUs can't use IKE, KINK, PKI, AAA etc. But back to the BUs themselves. If it is not possible to allocate a new next header value, the granularity of standard IPsec policies isn't today sufficient (no destination options looked). The change to add a look at the destination options is trivial implementation-wise, though it has been stated that standards-wise adding such things would take a long time (I'm not really sure why this is the case). Going further: if it is not possible to keep the BUs in separate packets, then the above change to the granularity of packets would be sufficient to send even piggypacked BUs. In this case the IPsec policies would state that packets from anywhere to us would have to have protection if they contained a BU option. Jari From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 31 04:03:10 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA09257 for ; Tue, 31 Jul 2001 04:03:10 -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 CAA14661; Tue, 31 Jul 2001 02:02: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 BAA08668; Tue, 31 Jul 2001 01:02:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6V814904258 for mobile-ip-dist; Tue, 31 Jul 2001 01:01:04 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6V80xY04251 for ; Tue, 31 Jul 2001 01:00:59 -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 BAA20110 for ; Tue, 31 Jul 2001 01:01:10 -0700 (PDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA13842 for ; Tue, 31 Jul 2001 02:01:08 -0600 (MDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id f6V818O08147; Tue, 31 Jul 2001 10:01:08 +0200 (MEST) Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.38.50]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f6V817505640; Tue, 31 Jul 2001 11:01:07 +0300 (EET DST) Message-ID: <3B6665C3.8587EF71@lmf.ericsson.se> Date: Tue, 31 Jul 2001 11:01:07 +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: Hesham.Soliman@era.ericsson.se, charliep@iprg.nokia.com, mat@cisco.com CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Concern over draft-team-mobileip-mipv6-sec-reqts-00.txt References: <034BEFD03799D411A59F00508BDF754603008B8F@esealnt448.al.sw.ericsson.se> <3B65FFDB.65150A96@iprg.nokia.com> <3B665F6D.AE6836DB@lmf.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 have been informed that what I said about the piggypacked case wasn't quite correct. If there are other policies besides those dealing with BUs, it might happen that two policies apply to a single packet. Such a case would need some more thinking how it can be handled; definition of how the SAs should be ordered etc. My conclusions on the separate-packet-with-new-next-header and separate-packet-with-option cases stay the same. Jari From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 31 05:48:38 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA10764 for ; Tue, 31 Jul 2001 05:48:38 -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 DAA07148; Tue, 31 Jul 2001 03:48:58 -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 CAA11691; Tue, 31 Jul 2001 02:48:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6V9lA804442 for mobile-ip-dist; Tue, 31 Jul 2001 02:47:10 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6V9l6Y04435 for ; Tue, 31 Jul 2001 02:47:07 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA11616 for ; Tue, 31 Jul 2001 02:47:22 -0700 (PDT) Received: from sonne.darmstadt.gmd.de (sonne.darmstadt.gmd.de [141.12.62.20]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA26240 for ; Tue, 31 Jul 2001 02:47:21 -0700 (PDT) Received: from ipsi.fraunhofer.de (pc-morion [141.12.35.155]) by sonne.darmstadt.gmd.de (8.8.8/8.8.5) with ESMTP id LAA23317; Tue, 31 Jul 2001 11:47:19 +0200 (MET DST) Message-ID: <3B667FAA.4825EE7E@ipsi.fraunhofer.de> Date: Tue, 31 Jul 2001 11:51:38 +0200 From: Wolfgang Schoenfeld Organization: FhG IPSI X-Mailer: Mozilla 4.7 [de] (WinNT; I) X-Accept-Language: en,de MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Handover Smoothing - What to Do? References: <034BEFD03799D411A59F00508BDF754603008B8B@esealnt448.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, I accept nearly all you are saying :-) Few comments below. Regards Wolfgang > ... > > Alternatively, you may introduce 'redirection guns' > > which intercept your packet > > and redirect it to some new position of the target. > > Or you may use retardation devices > > to hold back the packet if it is too early. > > > => The problem is exactly that (the redirection). > How do you know when to redirect. Once notified (BU), > you can not assume that you can immediately > redirect. There is a gap here in which the target > may still be connected to the oAR or disconnected > then came back, or never disconnected at all (failure). Yes, even if you have precise knowledge of the mobile's moves (and even of how link layer connectivity develops) you may be unable to compute from that knowledge when to redirect where because there are much more sources for uncertainty. But you will agree in that we should do our best here and rely to bi-/multicasting only if other means fail. (BTW, in my picture, I should have used a usual gun with pellets instead of machine gun.) > ... > > Where is such an analysis? > > > => There is a theoritical one in the draft and I've pointed to a > practical one earlier. I do agree 100 % with doing as much > analysis as possible, however I also like consistency. > Inconsistency causes frustration and confusion. > For example, where is the analysis that Fast Handoffs There is none, as far as I can see :-( > will work at all ? More importantly where is the theoritical > analysis that contradicts the existing one in the draft ? > > > Note that an analysis is the harder > > the more complicated your mechanism is. > > You have to take into account not only velocity and direction of the bullet, > > but also the effects of all the intermediate devices. > > > => This is not something we can do for a standard. We will > never be able to analyse all situations for all link layers Unfortunately, you are right. > ... -- Wolfgang Schoenfeld, Fraunhofer IPSI, Dolivostr. 15, D-64293 Darmstadt Office: +49-6151-869-865 FAX: -6847 Mobile: +49-174-7093455 From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 31 07:49:10 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA13286 for ; Tue, 31 Jul 2001 07:49:09 -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 FAA29809; Tue, 31 Jul 2001 05: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 EAA21187; Tue, 31 Jul 2001 04:49:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6VBlhV04813 for mobile-ip-dist; Tue, 31 Jul 2001 04:47:43 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6VBleY04806 for ; Tue, 31 Jul 2001 04:47:40 -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 EAA26044 for ; Tue, 31 Jul 2001 04:47:53 -0700 (PDT) Received: from cichlid.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA24866 for ; Tue, 31 Jul 2001 05:49:23 -0600 (MDT) Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.2/8.9.3) with ESMTP id f6VBo9X04471 for ; Tue, 31 Jul 2001 07:50:09 -0400 Message-Id: <200107311150.f6VBo9X04471@cichlid.adsl.duke.edu> To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Concern over draft-team-mobileip-mipv6-sec-reqts-00.txt In-Reply-To: Message from "Charles E. Perkins" of "Fri, 27 Jul 2001 12:59:09 PDT." <3B61C80D.4DA456B0@iprg.nokia.com> Date: Tue, 31 Jul 2001 07:50:08 -0400 From: Thomas Narten 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: "Charles E. Perkins" writes: > This is because it is declared several times in the draft that mobility > opens security vulnerabilities when home agents and correspondent > nodes accept Binding Updates without any authentication. One point that we all could probably be much more clear about is that it is the route optimization part of MIPv6 that has the security issues. I agree with Charlie that it is not MIPv6 in general. This distinction is very important, because MIPv4 has *exactly* the same problem. Yet, very few people (and especially not those in the press) seem to be noticing this. This has to some extent caused additional PR problems for MIPv6, since many folks don't distinguish MIPv6 from just the route optimization. It would be good for all of us to continually educate folks that don't make this distinction. So why has MIPv6 security being targeted and not MIPv4? For one thing, in MIPv4, the route optimization stuff is in a separate draft, so it is not part of the base spec. Second, in conversations I have had with folks interested in MIPv6, they seem to generally think that the route optimization part of MIPv6 *is* important, and that MIPv6 in general is significantly less attractive without it. I don't fully understand this reasoning, given that MIPv4 (without route optimization) is being deployed today, and route optization in MIPv4 is not being pursued by any of the carriers (from what I can tell - please correct me if I'm wrong). > More generally, I would suggest that every scenario should have > an additional "STATUS" subtopic heading. That is, for each of > the scenarios, the current status of the threat should be listed. > So, for instance, each of the remote redirect scenarios (in addition > to being reworded) could contain the following paragraph: > STATUS: prevented within Mobile IPv6 by the requirement that > all Binding Updates MUST be validated using the > unforgeable Authentication Data provided along with > the Binding Update. This is an interesting suggestion. But rather than making the threat analysis document do this for the various proposals, it might be better for each proposed solution to describe how (and whether) it deals with each of the described threats. Certainly, one of the intents of the threat analysis document was to provide a straightforward way of comparing various proposed solutions to see exactly which threats they guarded against. Thomas From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 31 09:43:28 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA15743 for ; Tue, 31 Jul 2001 09:43:27 -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 GAA04607; Tue, 31 Jul 2001 06:42: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 GAA07873; Tue, 31 Jul 2001 06:42:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6VDesE05130 for mobile-ip-dist; Tue, 31 Jul 2001 06:40:54 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6VDeoY05123 for ; Tue, 31 Jul 2001 06:40:50 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA02297 for ; Tue, 31 Jul 2001 06:41:05 -0700 (PDT) Received: from idcpa4.pa.interdigital.com ([12.32.197.142]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA12162 for ; Tue, 31 Jul 2001 06:41:04 -0700 (PDT) Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19) id ; Tue, 31 Jul 2001 09:39:54 -0400 Message-ID: From: "Shahrier, Sharif M." To: "'mobile-ip@sunroof.eng.sun.com'" Cc: "'proberts@megisto.com'" , "'basavaraj.patil@nokia.com'" Subject: RE: [mobile-ip] Question on draft-team-mobileip-mipv6-sec-reqts-0 0.txt Date: Tue, 31 Jul 2001 09:39:51 -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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Is there a design team to establish the security requirements for MIPv6? I have not been following this lately. If there is, could I be added to the team. I also need more information on how the team is run, so I would appreciate it if the team leader can send me information, teleconference schedules etc. Thanks. -Sharif From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 31 09:50:10 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA15875 for ; Tue, 31 Jul 2001 09:50:09 -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 GAA07105; Tue, 31 Jul 2001 06:49:03 -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 GAA03399; Tue, 31 Jul 2001 06:48:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6VDlOw05180 for mobile-ip-dist; Tue, 31 Jul 2001 06:47:24 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6VDlLY05173 for ; Tue, 31 Jul 2001 06:47:21 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA08599 for ; Tue, 31 Jul 2001 06:47:35 -0700 (PDT) Received: from idcpa4.pa.interdigital.com ([12.32.197.142]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA15832 for ; Tue, 31 Jul 2001 06:47:34 -0700 (PDT) Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19) id ; Tue, 31 Jul 2001 09:46:24 -0400 Message-ID: From: "Shahrier, Sharif M." To: "'mobile-ip@sunroof.eng.sun.com'" Cc: "'proberts@megisto.com'" , "'basavaraj.patil@nokia.com'" Subject: [mobile-ip] Billing requirements for MIPv6 Date: Tue, 31 Jul 2001 09:46: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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Seems an important problem that needs to be tackled is "billing in a MIPv6 environment". This applies to mobile host restricted to domain controlled by a singe operator and also the case where the mobile is allowed to roam accross domains controlled by different network operators. I was wondering if this problem has been discussed to any degree, and if there are current plans to look into a requirements draft. Natually, billing is an important issue for the operator ...... -Sharif. From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 31 10:51:54 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19213 for ; Tue, 31 Jul 2001 10:51:53 -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 HAA05159; Tue, 31 Jul 2001 07:51:17 -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 HAA17179; Tue, 31 Jul 2001 07:50:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6VEnvd05300 for mobile-ip-dist; Tue, 31 Jul 2001 07:49:57 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6VEnsY05293 for ; Tue, 31 Jul 2001 07:49:54 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA17080 for ; Tue, 31 Jul 2001 07:50:06 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA13893 for ; Tue, 31 Jul 2001 07:50:06 -0700 (PDT) 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 f6VEoJY12284 for ; Tue, 31 Jul 2001 07:50:20 -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 ABK06290; Tue, 31 Jul 2001 07:50:04 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA12676; Tue, 31 Jul 2001 07:50:04 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15206.50587.999137.293269@thomasm-u1.cisco.com> Date: Tue, 31 Jul 2001 07:50:03 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Concern over draft-team-mobileip-mipv6-sec-reqts- 00.txt In-Reply-To: <034BEFD03799D411A59F00508BDF754603008B87@esealnt448.al.sw.ericsson.se> References: <034BEFD03799D411A59F00508BDF754603008B87@esealnt448.al.sw.ericsson.se> 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 Hesham Soliman (ERA) writes: > > Mike, > > While you're answering question (or someone else who knows > IPsec better than me), are there any problems foreseen with IPsec > if we simply get rid of piggybacking the BUs and send them > in separate packets ? > I thought not, but would like some confirmation. I believe that if you remove the constraint that only BU's be protected (vs other destination options), then no, I don't think there's a problem. Even if you could do such a thing, I'm having a very hard time imagining _why_ you would want to do such a thing. Indeed, if you used ESP instead, you'd get better protection in all cases (assuming you're not using ESP-NULL, of course). Mike From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 31 10:56:31 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19464 for ; Tue, 31 Jul 2001 10:56:30 -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 HAA07196; Tue, 31 Jul 2001 07:55: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 HAA17643; Tue, 31 Jul 2001 07:54:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6VErhh05345 for mobile-ip-dist; Tue, 31 Jul 2001 07:53:43 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6VErdY05338 for ; Tue, 31 Jul 2001 07:53:39 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA02467 for ; Tue, 31 Jul 2001 07:53:52 -0700 (PDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA15474 for ; Tue, 31 Jul 2001 07:53:52 -0700 (PDT) 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 f6VEpdJ00803 for ; Tue, 31 Jul 2001 07:51:39 -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 ABK06326; Tue, 31 Jul 2001 07:52:34 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA12679; Tue, 31 Jul 2001 07:52:34 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15206.50738.588722.757995@thomasm-u1.cisco.com> Date: Tue, 31 Jul 2001 07:52:34 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Concerns about draft-mipv6-14 section 4.8 In-Reply-To: <3B65E1C2.7E473867@Kniveton.com> References: <3B65AD55.A3068A5E@inrialpes.fr> <3B65E1C2.7E473867@Kniveton.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 I'll throw my support backing it out again too. Mobile routers are going to involve a lot of consideration, because they have some pretty far reaching implications. They should be taken up as a separate working group item instead of letting it bog down mipv6. Mike T.J. Kniveton writes: > I agree with Thierry here - the discussions on the list and at meetings > have shown that there is interest in making mobile prefixes work within > the context of MIPv6 handovers. The key phrase here is problem scope -- > it should be broken down to a solvable level, and especially limited > within the base draft (which I believe was the intention). To make it > really work, security issues must be solved first. Which leads us to the > question, for MIPv6 expediency's sake, why not leave it as a separate > draft? > > -TJ > > > > Thierry Ernst wrote: > > > > Dear all, > > > > One of the changes of the MIPv6 draft from version 13 to 14 is the > > addition of a section "Mobile Routers" (section 4.8) and a new > > sub-option "Mobile Router Prefix Length" (section 5.5). I have some > > concerns about these additions that I would like to share with the WG: > > > > o I think that more issues are added than solved by this new > > sub-option: > > - security (authorization) > > - How is it processed by the HA and the CNs > > - How is it used by the HA and the CNs > > - ... > > > > o It does only solve part of the problems already highlighted last year > > in the WG meetings and in the mailing list > > > > o There are a number of other problems that we have not even noticed or > > at least debated. > > > > o what is the exact meaning of "any home address" in section 5.5 ? > > > > I think that the support of mobile routers and networks (let's call this > > "Network Mobility Support") deserves more than a section. Particularly > > a terminology that defines what we are speaking about and that limits > > the scope of the problem that could be solve by the MIP spec. would be > > welcome prior to this. > > > > Indeed, I am quite surprised to see a new section that has not > > previously been discussed nor shared with the people on this mailing > > list, particularly not with the authors of draft > > http://www.ietf.org/internet-drafts/draft-ernst-mobileip-v6-network-02.txt. > > This draft that I wrote highlighted some issues in the MIPv6 > > specification for "Network Mobility Support". As a result of past > > discussions, some people have agreed that MIPv6 needs clarifications for > > the HA to redirect packets to nodes behind the mobile router. This is > > not clarified in MIPv6-14, a clarification would have made more sense > > than the addition of a new feature in the WG doc itself. > > > > Moreover, my draft has introduced a "Mobile Network Prefix" sub-option > > that carries the prefix of the mobile network as part of the BU. This > > BU is sent to both the HA and CNs. Following this proposition, security > > concerns have been raised, particulalry about authorization. > > Authorization issues have largely accounted for the delay of the > > acceptance of my idea. The idea behind the sub-option introduced in > > MIPv6-14 seems to be taken from my draft, though a bit more limited, > > since it only carries the prefix length, not the prefix itself. The > > same authorization (and other security) concerns apply to this new > > sub-option, particularly when it is sent to CNs. I am quite amazed to > > see that no one has waved the security flag this time. Problably most > > people are busy, or have missed this section. > > > > Given the fact that "Network Mobility Support" is not yet a working > > group item and that the problem is not even perceived by the WG, the > > most immediate result relative to section 4.8 is that the MIPv6 > > specification may be further delayed. This is something we can not > > afford. MIPv6 has been delayed long enough, it's not the right moment to > > introduce new feartures in the MIPv6 document itself. The introduction > > of new features would in turn introduce potential new holes (particulary > > securiry holes) that would further delay the spec. for Proposed > > Standard. > > > > My conclusions are: > > > > - Section 4.8 and sub-option "Mobile Router Prefix Length" SHOULD be > > removed from the MIPv6 draft, > > > > - modifications to the MIPv6 draft specification MUST be discussed on > > the mailing list prior to their addition in a WG document, > > > > - extensions to the Mobile IPv6 specification, if not discussed on the > > mailing list, MUST be presented in a separate document, > > > > - Network Mobility Support SHOULD NOT be added in the MIPv6 > > specification itself - it is a distinct problem, it has its own solution > > IMHO > > > > - The problem and the requirements to solve "Network Mobility Support" > > SHOULD be discussed first. > > > > BTW, I have written a new draft "Network Mobility Support in IPv6: > > Problem Statement and Requirements" > > http://www.ietf.org/internet-drafts/draft-ernst-mobileip-monetv6-00.txt > > for the purpose of discussing the last item. If you have interest in > > this discussion, a post on this mailing list PRIOR to the WG meeting > > would be more than welcome. > > > > Regards, > > Thierry. > > > > -- > > * mailto:Thierry.Ernst@inrialpes.fr Tel +33 (0) 4 76 61 52 69 > > * INRIA Rhone-Alpes Projet PLANETE (fax 52 52) > > * and MOTOROLA Labs Paris > > * http://www.inrialpes.fr/planete/people/ernst/Welcome.html > > -- > T.J. Kniveton > Communications Systems Lab > Nokia Research Center From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 31 11:05:53 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA20063 for ; Tue, 31 Jul 2001 11:05:52 -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 JAA09014; Tue, 31 Jul 2001 09:04: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 IAA19210; Tue, 31 Jul 2001 08:04:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6VF34Z05465 for mobile-ip-dist; Tue, 31 Jul 2001 08:03:04 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6VF31Y05458 for ; Tue, 31 Jul 2001 08:03:01 -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 IAA02760 for ; Tue, 31 Jul 2001 08:03:14 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA07924 for ; Tue, 31 Jul 2001 09:03:12 -0600 (MDT) 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 f6VF3QY22392 for ; Tue, 31 Jul 2001 08:03:26 -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 ABK06500; Tue, 31 Jul 2001 08:03:11 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA12684; Tue, 31 Jul 2001 08:03:10 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15206.51374.731671.354856@thomasm-u1.cisco.com> Date: Tue, 31 Jul 2001 08:03:10 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Concern over draft-team-mobileip-mipv6-sec-reqts-00.txt In-Reply-To: <3B65FFDB.65150A96@iprg.nokia.com> References: <034BEFD03799D411A59F00508BDF754603008B8F@esealnt448.al.sw.ericsson.se> <3B65FFDB.65150A96@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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Vijay Devarapalli writes: > Hesham, > > take a look at this. > > http://www.ietf.org/proceedings/01mar/ietf50-91.htm#TopOfPage > > look at Jeff Schiller's comments. I believe that Jeff's opening comment about IPsec is overly broad. RFC 2401 compliant IPsec's do have the ability to classify traffic based on the normal 5-tuple which should be sufficient for MIP if it doesn't *violate* that requirement, which it was in two ways. Both of those violations seem quite easy to change within the MIP spec itself to accommodate use of IPsec within limited authentication realms. Mike > > vijay > > "Hesham Soliman (ERA)" wrote: > > > > > > > > > > While you're answering question (or someone else who knows > > > > IPsec better than me), are there any problems foreseen with IPsec > > > > if we simply get rid of piggybacking the BUs and send them > > > > in separate packets ? > > > > I thought not, but would like some confirmation. > > > > > > > The only other constraint is that there is no selector for protecting > > > just binding update. IPsec policy allows you to select based on > > > the IPv6 "nxt" headers. In this case, it would be a destination > > > option. But binding update is just one type of such an option. > > > So, all destination options would be protected if you use > > > IPsec as it exists today. > > > > > => Sure but we can have a new type header for it, that is > > if you can't increase the granulaity of the policies. Is this > > really a problem ? > > > > > > Others that were mentioned in the past are : > > > > > > 1) Why only AH ? It is too restrictive. > > > > > => Yes, that's another issue. I just wanted > > to know if there were any show stoppers, it > > seems like the selectors are the only issue. > > > > Hesham > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Michael Thomas [SMTP:mat@cisco.com] > > > > > Sent: Monday, 30 July 2001 10:58 > > > > > To: mobile-ip@sunroof.eng.sun.com > > > > > Subject: RE: [mobile-ip] Concern over > > > draft-team-mobileip-mipv6-sec-reqts- 00.txt > > > > > > > > > > Glenn Morrow writes: > > > > > > Michael, > > > > > > > > > > > > You may have a point but please do us the favor of answering these > > > > > > questions: > > > > > > > > > > > > 1> Do you believe that the credentials associated with an SA for node > > > > > > mobility would ALWAYS be the same as the credentials for another SA for > > > an > > > > > > application on two communicating hosts? > > > > > > > > > > Not always. Sometimes though (maybe often even). > > > > > > > > > > > 2> Can there be more than one ESP header in a single IP packet without > > > > > > tunneling? > > > > > > > > > > Not to my knowledge. > > > > > > > > > > > 3> Has there been any succesful work at changing the answer to question 2 > > > or > > > > > > perhaps defining some new generic multi-purpose IP-layer encryption > > > option > > > > > > perhaps with different properties? > > > > > > > > > > Not to my knowledge. > > > > > > > > > > > > 4> Has there been any successful work at changing the fact that a BU > > > can be > > > > > > sent in the same packet as an application PDU? > > > > > > > > > > Not sure what you're asking here... Are you asking if there's > > > > > been an implementation of piggybacked BU's? > > > > > > > > > > Mike From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 31 11:26:59 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA21280 for ; Tue, 31 Jul 2001 11:26:58 -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 IAA21272; Tue, 31 Jul 2001 08:22: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 IAA22345; Tue, 31 Jul 2001 08:21:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6VFK4Z05628 for mobile-ip-dist; Tue, 31 Jul 2001 08:20:04 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6VFK0Y05621 for ; Tue, 31 Jul 2001 08:20:00 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id IAA07195 for ; Tue, 31 Jul 2001 08:20:13 -0700 (PDT) Message-Id: <200107311520.IAA07195@heliopolis.eng.sun.com> Date: Tue, 31 Jul 2001 08:20:11 -0700 (PDT) From: James Kempf Subject: RE: [mobile-ip] Handover Smoothing - What to Do? To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: WH5pTo5ISSgOZtssXfMD/A== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 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: Hesham, > > For example, where is the analysis that Fast Handoffs > will work at all ? More importantly where is the theoritical > analysis that contradicts the existing one in the draft ? > Appendix A of draft-kempf-beth-ipv6-01.txt in fact does contain an analysis of FMIPv6. The numbers there are not encouraging. This and the POST-REG work in FMIPv4 motivated the BETH work. jak From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 31 11:31:28 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA21539 for ; Tue, 31 Jul 2001 11:31:28 -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 JAA01888; Tue, 31 Jul 2001 09:30: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 IAA21336; Tue, 31 Jul 2001 08:29:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6VFSoG05715 for mobile-ip-dist; Tue, 31 Jul 2001 08:28:51 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6VFSlY05708 for ; Tue, 31 Jul 2001 08:28:47 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA08376 for ; Tue, 31 Jul 2001 08:29:00 -0700 (PDT) Received: from idcpa4.pa.interdigital.com ([12.32.197.142]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA13241 for ; Tue, 31 Jul 2001 08:28:59 -0700 (PDT) Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19) id ; Tue, 31 Jul 2001 11:27:49 -0400 Message-ID: From: "Shahrier, Sharif M." To: "'Basavaraj.Patil@nokia.com'" , "Shahrier, Sharif M." , mobile-ip@sunroof.eng.sun.com Cc: proberts@megisto.com Subject: RE: [mobile-ip] Question on draft-team-mobileip-mipv6-sec-reqts-0 0.txt Date: Tue, 31 Jul 2001 11:27:47 -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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: JUst wondering if there are any design teams to persue the solutions. Or are individual drafts to be submitted at this time, and later a design team is to come up with the final version. -Sharif. -----Original Message----- From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com] Sent: Tuesday, July 31, 2001 11:00 AM To: Sharif.Shahrier@interdigital.com; mobile-ip@sunroof.eng.sun.com Cc: proberts@megisto.com Subject: RE: [mobile-ip] Question on draft-team-mobileip-mipv6-sec-reqts-0 0.txt > > Is there a design team to establish the security requirements > for MIPv6? There is no design team. The security requirements document has been published and the requirements in this document should be used as the basis for designing solutions. Of course we still need to get consensus from WG members w.r.t these requirements. The requirements document is : draft-team-mobileip-mipv6-sec-reqts-00.txt > I have not been following this lately. If there is, could I be > added to the > team. I also need more information on how the team is run, so I would > appreciate it if the team leader can send me information, > teleconference > schedules etc. Thanks. > > -Sharif > -Basavaraj From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 31 11:31:32 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA21555 for ; Tue, 31 Jul 2001 11:31:31 -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 JAA01541; Tue, 31 Jul 2001 09:29: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 IAA21138; Tue, 31 Jul 2001 08:29:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6VFSFP05697 for mobile-ip-dist; Tue, 31 Jul 2001 08:28:15 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6VFSBY05690 for ; Tue, 31 Jul 2001 08:28:12 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA07077 for ; Tue, 31 Jul 2001 08:28:25 -0700 (PDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA12935 for ; Tue, 31 Jul 2001 08:28:24 -0700 (PDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f6VFSW312471; Tue, 31 Jul 2001 08:28: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 ABK06943; Tue, 31 Jul 2001 08:28:19 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA12688; Tue, 31 Jul 2001 08:28:19 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15206.52882.864047.699551@thomasm-u1.cisco.com> Date: Tue, 31 Jul 2001 08:28:18 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Cc: Michael Thomas Subject: Re: [mobile-ip] Concern over draft-team-mobileip-mipv6-sec-reqts-00.txt In-Reply-To: <3B662EAB.EE182C21@iprg.nokia.com> References: <3B61C80D.4DA456B0@iprg.nokia.com> <15201.51986.555615.673177@thomasm-u1.cisco.com> <3B61D678.CA0C67AB@iprg.nokia.com> <15201.58214.80975.246707@thomasm-u1.cisco.com> <3B621A1B.EECE6DAE@iprg.nokia.com> <15202.13525.495386.619084@thomasm-u1.cisco.com> <3B625B5B.37D83B7D@iprg.nokia.com> <15205.48529.779861.234981@thomasm-u1.cisco.com> <3B662EAB.EE182C21@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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Charlie Perkins writes: > Here's a technical point... > > >> The reqs draft says that Mobile IPv6 is vulnerable to > >> misuse from unauthenticated Binding Updates. > >> Mobile IPv6 says that unauthenticated Binding Updates > >> have to be ignored. The claimed vulnerability does > >> not exist by the rules of the the Mobile IPv6 spec. > >> It would exist by other rules, sure. This is a very > >> serious issue. > > > The spec may say that they must be ignored, but it > > does not provide a workable method for how a node > > determines that they are unauthenticated Thus the > > analysis states the situation correctly. > > If a node has no security association with a mobile > node, it cannot authenticate the Binding Update and > it must be ignored. What else needs to be said? > I don't think this is at all ambiguous. Thus, it is not > correct to characterize Mobile IPv6 as suffering from > this vulnerability. Since there isn't sufficient information on _how_ to authenticated binding updates, the only way to interpret what you wrote in light of the analysis is that MIPv6 does not have this vulnerability because it does not support route optimization. This is clearly not very helpful as it's obvious that the goal is to have a secure route optimization feature as part of the base spec, and I'll guess that that was their take on the matter as well. I'm sorry if you feel frustrated with all of this because the MIP WG has unwittingly fallen into a trap with an extremely hard puzzle that needs to be solved before it gets out. Things like this happen, and security/identity/authorization is very fertile ground for these sorts of pit traps. My attitude is we're here, we're hosed, we need to get on with solving the puzzle. It does no good to parse differing degrees of hoseitude, and indeed detracts from the real job at hand. My sin is that I did not pursue this more vigorously than sending off a note well over a year ago to Steve Deering and Fred Baker about whether the IESG was going to step up to the plate given the global implication of IP address ownership that MIPv6 brings to the fore. To me, this was as plain as the nose on my face and I assumed that the MIP WG had already been through this and come to its own inner peace about which of the set of bad options it was willing to live with. I was wrong, and now I look like a Cassandra for raising what should have been raised years ago. I am but the messanger though, and it's a good thing this was widely realized before it went to proposed standard since we *really* would have looked foolish if it were realized after the fact. Mike From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 31 11:36:43 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA21847 for ; Tue, 31 Jul 2001 11:36:42 -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 JAA07334; Tue, 31 Jul 2001 09:36: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 IAA23616; Tue, 31 Jul 2001 08:35:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6VFYQL05858 for mobile-ip-dist; Tue, 31 Jul 2001 08:34:26 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6VFYMY05851 for ; Tue, 31 Jul 2001 08:34:22 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA09651 for ; Tue, 31 Jul 2001 08:34:35 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA16765 for ; Tue, 31 Jul 2001 08:34:33 -0700 (PDT) Received: from mira-sjcm-3.cisco.com (mira-sjcm-3.cisco.com [171.69.24.15]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f6VFYVY19103 for ; Tue, 31 Jul 2001 08:34:36 -0700 (PDT) Received: from GDOMMETY-W2K2.cisco.com (gdommety-dsl5.cisco.com [10.19.17.142]) by mira-sjcm-3.cisco.com (Mirapoint) with ESMTP id AAI00043; Tue, 31 Jul 2001 08:34:14 -0700 (PDT) Message-Id: <4.3.2.7.2.20010731082556.01e8f650@mira-sjcm-3.cisco.com> X-Sender: gdommety@mira-sjcm-3.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 31 Jul 2001 08:36:59 -0700 To: mobile-ip@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com From: Gopal Dommety Subject: Re: [mobile-ip] Re:Comments on draft-ietf-mobileip-fast-mipv6-02.txt In-Reply-To: <3B65A33F.B66C7553@usa.alcatel.com> References: <200107301836.LAA28316@heliopolis.eng.sun.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: Thanks Behcet. I have corrected the Captions. Also let me know if you find other mistakes. As for the DAD handling, how about the the following statement at the end of second paragraph of section 5.1. Let me know.... "Links wherein the uniqueness of the interface identifier is ensured with in the subnet (by means beyond the scope of this document), DAD handling procedures could be avoided." thanks -Gopal At 02:11 PM 7/30/2001 -0400, Behcet Sarikaya wrote: >The draft: >draft-ietf-mobileip-fast-mipv6-02.txt >has so many editorial problems including the following: >No table of contents. Figures 1-3 captions should end with handover, e.g. >Stateless Handover. >More importantly section 5.1 on Dad handling should include some text on >the links >that do not require any DAD such as 3GPP links as per >draft-manyfolks-ipv6-cellular-host-00.txt. > >Regards, > >-- >Behcet From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 31 11:37:09 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA21864 for ; Tue, 31 Jul 2001 11:37:09 -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 JAA06311; Tue, 31 Jul 2001 09:34:59 -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 IAA23122; Tue, 31 Jul 2001 08:34:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6VFXKL05832 for mobile-ip-dist; Tue, 31 Jul 2001 08:33:20 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6VFXGY05824 for ; Tue, 31 Jul 2001 08:33:16 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA08025 for ; Tue, 31 Jul 2001 08:33:29 -0700 (PDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA15732 for ; Tue, 31 Jul 2001 08:33:23 -0700 (PDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f6VFWu315568; Tue, 31 Jul 2001 08:32:56 -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 ABK06096; Tue, 31 Jul 2001 07:32:24 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA12673; Tue, 31 Jul 2001 07:32:24 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15206.49527.863582.976611@thomasm-u1.cisco.com> Date: Tue, 31 Jul 2001 07:32:23 -0700 (PDT) To: Jari Arkko Cc: Hesham.Soliman@era.ericsson.se, charliep@iprg.nokia.com, mat@cisco.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Concern over draft-team-mobileip-mipv6-sec-reqts-00.txt In-Reply-To: <3B665F6D.AE6836DB@lmf.ericsson.se> References: <034BEFD03799D411A59F00508BDF754603008B8F@esealnt448.al.sw.ericsson.se> <3B65FFDB.65150A96@iprg.nokia.com> <3B665F6D.AE6836DB@lmf.ericsson.se> 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 Jari Arkko writes: > Of course, we must remember to keep separate the > packet protection and the key management problems. > The minutes from IETF #50 that Vijay referred to > discussed mostly the key management issues. It > seems very clear that there is working group consensus > on that BUs can't use IKE, KINK, PKI, AAA etc. Actually, I don't think there's consensus about _not_ using IKE etc. There is clear direction from the IESG that PKI/centralized keying cannot be the _only_ method of protecting BU's, especially for random MN/CN situations. Where you can use strong crypto (same administrative domain, say), it should be used in preference to a scheme based on a return routability test. One other nit with notes: IPsec (IKE/strong authentication, really) does protect against man in the middle attacks, something that a return routablity test based scheme would not be able to defend against. > But back to the BUs themselves. If it is not possible > to allocate a new next header value, the granularity > of standard IPsec policies isn't today sufficient (no > destination options looked). I don't understand this: destination options are not supposed to be touched in the middle. Requiring all destination options to be protected -- not just BU's -- sounds like a *feature* to me. This requires no changes to IPsec. > Going further: if it is not possible to keep the BUs > in separate packets, then the above change to the > granularity of packets would be sufficient to send > even piggypacked BUs. In this case the IPsec policies > would state that packets from anywhere to us would > have to have protection if they contained a BU option. If you set up a selector which only selected based on IP addresses, you could piggyback with IPsec as it stands today. I'm not sure that piggybacking is really worth the grief that it's causing though. Mike From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 31 11:46:46 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22455 for ; Tue, 31 Jul 2001 11:46:46 -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 JAA16100; Tue, 31 Jul 2001 09:45:18 -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 IAA25752; Tue, 31 Jul 2001 08:45:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6VFhUZ05994 for mobile-ip-dist; Tue, 31 Jul 2001 08:43:30 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6VFhRY05987 for ; Tue, 31 Jul 2001 08:43:27 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA09823 for ; Tue, 31 Jul 2001 08:43:40 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA22478 for ; Tue, 31 Jul 2001 08:43:40 -0700 (PDT) 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 f6VFhrY26615 for ; Tue, 31 Jul 2001 08:43:53 -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 ABK07205; Tue, 31 Jul 2001 08:43:37 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA12691; Tue, 31 Jul 2001 08:43:37 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15206.53800.913350.908941@thomasm-u1.cisco.com> Date: Tue, 31 Jul 2001 08:43:36 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Concern over draft-team-mobileip-mipv6-sec-reqts-00.txt In-Reply-To: <200107311150.f6VBo9X04471@cichlid.adsl.duke.edu> References: <3B61C80D.4DA456B0@iprg.nokia.com> <200107311150.f6VBo9X04471@cichlid.adsl.duke.edu> 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 Thomas Narten writes: > So why has MIPv6 security being targeted and not MIPv4? For one thing, > in MIPv4, the route optimization stuff is in a separate draft, so it > is not part of the base spec. Second, in conversations I have had with > folks interested in MIPv6, they seem to generally think that the route > optimization part of MIPv6 *is* important, and that MIPv6 in general > is significantly less attractive without it. I don't fully understand > this reasoning, given that MIPv4 (without route optimization) is being > deployed today, and route optization in MIPv4 is not being pursued by > any of the carriers (from what I can tell - please correct me if I'm > wrong). It seems hard for me to imagine why an operator wouldn't like the prospect of not having to buy expensive, single-point-of-failure, etc, network elbow joints if they didn't have to. Since MIP is mainly a host OS deployment issue, and assuming that the usual suspects start supporting route optimization, I imagine that they'd be delighted to spend less money. I could be wrong though; people willingly force OE on people which defies logic too. Mike From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 31 11:57:33 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22883 for ; Tue, 31 Jul 2001 11:57: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 IAA08136; Tue, 31 Jul 2001 08:54:35 -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 IAA27596; Tue, 31 Jul 2001 08:54:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6VFrJE06087 for mobile-ip-dist; Tue, 31 Jul 2001 08:53:19 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6VFrGY06080 for ; Tue, 31 Jul 2001 08:53:16 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA13857 for ; Tue, 31 Jul 2001 08:53:24 -0700 (PDT) Received: from zrc2s03g.us.nortel.com ([47.103.122.66]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA16750 for ; Tue, 31 Jul 2001 08:53:24 -0700 (PDT) Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id KAA25012 for ; Tue, 31 Jul 2001 10:53:21 -0500 (CDT) Received: from zrchb200.us.nortel.com by smtprch1.nortel.com; Tue, 31 Jul 2001 10:53:08 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 31 Jul 2001 10:52:52 -0500 Message-ID: <85AA7486A2C1D411BCA20000F8073E4302F85708@crchy271.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com, Jari Arkko Cc: Hesham.Soliman@era.ericsson.se, charliep@iprg.nokia.com Subject: RE: [mobile-ip] Concern over draft-team-mobileip-mipv6-sec-reqts- 00.txt Date: Tue, 31 Jul 2001 10:52:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C119D8.D911D760" 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_01C119D8.D911D760 Content-Type: text/plain; charset="iso-8859-1" I believe that piggybacking is very important and would prefer to keep the existing proposal than get rid of it. You can always spend time later developing something generic. The current proposal is on-scope and quite pragmatic without giving anything up other than it just doesn't use IPSEC. -----Original Message----- From: Michael Thomas [mailto:mat@cisco.com] Sent: Tuesday, July 31, 2001 9:32 AM To: Jari Arkko Cc: Hesham.Soliman@era.ericsson.se; charliep@iprg.nokia.com; mat@cisco.com; mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Concern over draft-team-mobileip-mipv6-sec-reqts-00.txt Jari Arkko writes: > Of course, we must remember to keep separate the > packet protection and the key management problems. > The minutes from IETF #50 that Vijay referred to > discussed mostly the key management issues. It > seems very clear that there is working group consensus > on that BUs can't use IKE, KINK, PKI, AAA etc. Actually, I don't think there's consensus about _not_ using IKE etc. There is clear direction from the IESG that PKI/centralized keying cannot be the _only_ method of protecting BU's, especially for random MN/CN situations. Where you can use strong crypto (same administrative domain, say), it should be used in preference to a scheme based on a return routability test. One other nit with notes: IPsec (IKE/strong authentication, really) does protect against man in the middle attacks, something that a return routablity test based scheme would not be able to defend against. > But back to the BUs themselves. If it is not possible > to allocate a new next header value, the granularity > of standard IPsec policies isn't today sufficient (no > destination options looked). I don't understand this: destination options are not supposed to be touched in the middle. Requiring all destination options to be protected -- not just BU's -- sounds like a *feature* to me. This requires no changes to IPsec. > Going further: if it is not possible to keep the BUs > in separate packets, then the above change to the > granularity of packets would be sufficient to send > even piggypacked BUs. In this case the IPsec policies > would state that packets from anywhere to us would > have to have protection if they contained a BU option. If you set up a selector which only selected based on IP addresses, you could piggyback with IPsec as it stands today. I'm not sure that piggybacking is really worth the grief that it's causing though. Mike ------_=_NextPart_001_01C119D8.D911D760 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Concern over = draft-team-mobileip-mipv6-sec-reqts-00.txt

I believe that piggybacking is very important and = would prefer to keep the existing proposal than get rid of it. You can = always spend time later developing something generic. The current = proposal is on-scope and quite pragmatic without giving anything up = other than it just doesn't use IPSEC.

-----Original Message-----
From: Michael Thomas [mailto:mat@cisco.com]
Sent: Tuesday, July 31, 2001 9:32 AM
To: Jari Arkko
Cc: Hesham.Soliman@era.ericsson.se; = charliep@iprg.nokia.com;
mat@cisco.com; mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Concern over
draft-team-mobileip-mipv6-sec-reqts-00.txt


Jari Arkko writes:
 > Of course, we must remember to keep = separate the
 > packet protection and the key management = problems.
 > The minutes from IETF #50 that Vijay = referred to
 > discussed mostly the key management = issues. It
 > seems very clear that there is working = group consensus
 > on that BUs can't use IKE, KINK, PKI, AAA = etc.

   Actually, I don't think there's = consensus about
   _not_ using IKE etc. There is clear = direction
   from the IESG that PKI/centralized = keying cannot
   be the _only_ method of protecting = BU's, especially
   for random MN/CN situations. Where you = can use
   strong crypto (same administrative = domain, say),
   it should be used in preference to a = scheme based
   on a return routability test.

   One other nit with notes: IPsec = (IKE/strong
   authentication, really) does protect = against
   man in the middle attacks, something = that a
   return routablity test based scheme = would not
   be able to defend against.

 > But back to the BUs themselves. If it is = not possible
 > to allocate a new next header value, the = granularity
 > of standard IPsec policies isn't today = sufficient (no
 > destination options looked).

   I don't understand this: destination = options are not
   supposed to be touched in the middle. = Requiring
   all destination options to be protected = -- not just
   BU's -- sounds like a *feature* to me. = This requires
   no changes to IPsec.

 > Going further: if it is not possible to = keep the BUs
 > in separate packets, then the above = change to the
 > granularity of packets would be = sufficient to send
 > even piggypacked BUs. In this case the = IPsec policies
 > would state that packets from anywhere to = us would
 > have to have protection if they contained = a BU option.

   If you set up a selector which only = selected
   based on IP addresses, you could = piggyback
   with IPsec as it stands today. I'm not = sure
   that piggybacking is really worth the = grief
   that it's causing though.

             Mike

------_=_NextPart_001_01C119D8.D911D760-- From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 31 12:15:39 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24009 for ; Tue, 31 Jul 2001 12:15:38 -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 KAA12535; Tue, 31 Jul 2001 10:14:30 -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 JAA02578; Tue, 31 Jul 2001 09:14:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6VGDHx06229 for mobile-ip-dist; Tue, 31 Jul 2001 09:13:17 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6VGDDY06222 for ; Tue, 31 Jul 2001 09:13:13 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA18414 for ; Tue, 31 Jul 2001 09:13:27 -0700 (PDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA27469 for ; Tue, 31 Jul 2001 09:13:27 -0700 (PDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f6VGDa315843; Tue, 31 Jul 2001 09:13:36 -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 ABK07854; Tue, 31 Jul 2001 09:13:25 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA12697; Tue, 31 Jul 2001 09:13:23 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15206.55587.103072.911418@thomasm-u1.cisco.com> Date: Tue, 31 Jul 2001 09:13:23 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Cc: Jari Arkko , Hesham.Soliman@era.ericsson.se, charliep@iprg.nokia.com Subject: RE: [mobile-ip] Concern over draft-team-mobileip-mipv6-sec-reqts- 00.txt In-Reply-To: <85AA7486A2C1D411BCA20000F8073E4302F85708@crchy271.us.nortel.com> References: <85AA7486A2C1D411BCA20000F8073E4302F85708@crchy271.us.nortel.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 Glenn Morrow writes: > I believe that piggybacking is very important and would prefer to keep the > existing proposal than get rid of it. You can always spend time later > developing something generic. The current proposal is on-scope and quite > pragmatic without giving anything up other than it just doesn't use IPSEC. It's giving up standard key distribution which is always by far the hardest problem with crypto. I have a real problem with that. Mike > > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Tuesday, July 31, 2001 9:32 AM > To: Jari Arkko > Cc: Hesham.Soliman@era.ericsson.se; charliep@iprg.nokia.com; > mat@cisco.com; mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Concern over > draft-team-mobileip-mipv6-sec-reqts-00.txt > > > Jari Arkko writes: > > Of course, we must remember to keep separate the > > packet protection and the key management problems. > > The minutes from IETF #50 that Vijay referred to > > discussed mostly the key management issues. It > > seems very clear that there is working group consensus > > on that BUs can't use IKE, KINK, PKI, AAA etc. > > Actually, I don't think there's consensus about > _not_ using IKE etc. There is clear direction > from the IESG that PKI/centralized keying cannot > be the _only_ method of protecting BU's, especially > for random MN/CN situations. Where you can use > strong crypto (same administrative domain, say), > it should be used in preference to a scheme based > on a return routability test. > > One other nit with notes: IPsec (IKE/strong > authentication, really) does protect against > man in the middle attacks, something that a > return routablity test based scheme would not > be able to defend against. > > > But back to the BUs themselves. If it is not possible > > to allocate a new next header value, the granularity > > of standard IPsec policies isn't today sufficient (no > > destination options looked). > > I don't understand this: destination options are not > supposed to be touched in the middle. Requiring > all destination options to be protected -- not just > BU's -- sounds like a *feature* to me. This requires > no changes to IPsec. > > > Going further: if it is not possible to keep the BUs > > in separate packets, then the above change to the > > granularity of packets would be sufficient to send > > even piggypacked BUs. In this case the IPsec policies > > would state that packets from anywhere to us would > > have to have protection if they contained a BU option. > > If you set up a selector which only selected > based on IP addresses, you could piggyback > with IPsec as it stands today. I'm not sure > that piggybacking is really worth the grief > that it's causing though. > > Mike > > > > > > RE: [mobile-ip] Concern over draft-team-mobileip-mipv6-sec-reqts-00.txt > > > >

I believe that piggybacking is very important and would prefer to keep the existing proposal than get rid of it. You can always spend time later developing something generic. The current proposal is on-scope and quite pragmatic without giving anything up other than it just doesn't use IPSEC.

> >

-----Original Message----- >
From: Michael Thomas [mailto:mat@cisco.com] >
Sent: Tuesday, July 31, 2001 9:32 AM >
To: Jari Arkko >
Cc: Hesham.Soliman@era.ericsson.se; charliep@iprg.nokia.com; >
mat@cisco.com; mobile-ip@sunroof.eng.sun.com >
Subject: Re: [mobile-ip] Concern over >
draft-team-mobileip-mipv6-sec-reqts-00.txt >

>
> >

Jari Arkko writes: >
 > Of course, we must remember to keep separate the >
 > packet protection and the key management problems. >
 > The minutes from IETF #50 that Vijay referred to >
 > discussed mostly the key management issues. It >
 > seems very clear that there is working group consensus >
 > on that BUs can't use IKE, KINK, PKI, AAA etc. >

> >

   Actually, I don't think there's consensus about >
   _not_ using IKE etc. There is clear direction >
   from the IESG that PKI/centralized keying cannot >
   be the _only_ method of protecting BU's, especially >
   for random MN/CN situations. Where you can use >
   strong crypto (same administrative domain, say), >
   it should be used in preference to a scheme based >
   on a return routability test. >

> >

   One other nit with notes: IPsec (IKE/strong >
   authentication, really) does protect against >
   man in the middle attacks, something that a >
   return routablity test based scheme would not >
   be able to defend against. >

> >

 > But back to the BUs themselves. If it is not possible >
 > to allocate a new next header value, the granularity >
 > of standard IPsec policies isn't today sufficient (no >
 > destination options looked). >

> >

   I don't understand this: destination options are not >
   supposed to be touched in the middle. Requiring >
   all destination options to be protected -- not just >
   BU's -- sounds like a *feature* to me. This requires >
   no changes to IPsec. >

> >

 > Going further: if it is not possible to keep the BUs >
 > in separate packets, then the above change to the >
 > granularity of packets would be sufficient to send >
 > even piggypacked BUs. In this case the IPsec policies >
 > would state that packets from anywhere to us would >
 > have to have protection if they contained a BU option. >

> >

   If you set up a selector which only selected >
   based on IP addresses, you could piggyback >
   with IPsec as it stands today. I'm not sure >
   that piggybacking is really worth the grief >
   that it's causing though. >

> >

             Mike >

> > > From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 31 12:15:53 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24026 for ; Tue, 31 Jul 2001 12:15:52 -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 JAA17154; Tue, 31 Jul 2001 09:11:57 -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 JAA02001; Tue, 31 Jul 2001 09:11:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6VG9vV06197 for mobile-ip-dist; Tue, 31 Jul 2001 09:09:57 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6VG9sY06190 for ; Tue, 31 Jul 2001 09:09:54 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA15129 for ; Tue, 31 Jul 2001 09:10:08 -0700 (PDT) Received: from meshpdc.meshnetworks.com ([205.245.27.196]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA09177 for ; Tue, 31 Jul 2001 09:10:05 -0700 (PDT) Received: by meshpdc.meshnetworks.com with Internet Mail Service (5.5.2653.19) id ; Tue, 31 Jul 2001 12:10:02 -0400 Message-ID: <0DF9FBC42474A24CA50F7A27FB08E0484455F8@meshpdc.meshnetworks.com> From: Phillip Neumiller To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Concerns about draft-mipv6-14 section 4.8 Date: Tue, 31 Jul 2001 12:09:58 -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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: I agree and a more appropriate place to discuss it may be the MANET group where it has been pretty quiet lately. -Phil > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Tuesday, July 31, 2001 10:53 AM > To: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Concerns about draft-mipv6-14 section 4.8 > > > I'll throw my support backing it out again > too. Mobile routers are going to involve a lot of > consideration, because they have some pretty far > reaching implications. They should be taken up as > a separate working group item instead of letting > it bog down mipv6. > > Mike > > T.J. Kniveton writes: > > I agree with Thierry here - the discussions on the list > and at meetings > > have shown that there is interest in making mobile > prefixes work within > > the context of MIPv6 handovers. The key phrase here is > problem scope -- > > it should be broken down to a solvable level, and > especially limited > > within the base draft (which I believe was the intention). > To make it > > really work, security issues must be solved first. Which > leads us to the > > question, for MIPv6 expediency's sake, why not leave it as > a separate > > draft? > > > > -TJ > > > > > > > > Thierry Ernst wrote: > > > > > > Dear all, > > > > > > One of the changes of the MIPv6 draft from version 13 to > 14 is the > > > addition of a section "Mobile Routers" (section 4.8) and a new > > > sub-option "Mobile Router Prefix Length" (section 5.5). > I have some > > > concerns about these additions that I would like to > share with the WG: > > > > > > o I think that more issues are added than solved by this new > > > sub-option: > > > - security (authorization) > > > - How is it processed by the HA and the CNs > > > - How is it used by the HA and the CNs > > > - ... > > > > > > o It does only solve part of the problems already > highlighted last year > > > in the WG meetings and in the mailing list > > > > > > o There are a number of other problems that we have not > even noticed or > > > at least debated. > > > > > > o what is the exact meaning of "any home address" in > section 5.5 ? > > > > > > I think that the support of mobile routers and networks > (let's call this > > > "Network Mobility Support") deserves more than a > section. Particularly > > > a terminology that defines what we are speaking about > and that limits > > > the scope of the problem that could be solve by the MIP > spec. would be > > > welcome prior to this. > > > > > > Indeed, I am quite surprised to see a new section that has not > > > previously been discussed nor shared with the people on > this mailing > > > list, particularly not with the authors of draft > > > > http://www.ietf.org/internet-drafts/draft-ernst-mobileip-v6-ne > twork-02.txt. > > > This draft that I wrote highlighted some issues in the MIPv6 > > > specification for "Network Mobility Support". As a > result of past > > > discussions, some people have agreed that MIPv6 needs > clarifications for > > > the HA to redirect packets to nodes behind the mobile > router. This is > > > not clarified in MIPv6-14, a clarification would have > made more sense > > > than the addition of a new feature in the WG doc itself. > > > > > > Moreover, my draft has introduced a "Mobile Network > Prefix" sub-option > > > that carries the prefix of the mobile network as part of > the BU. This > > > BU is sent to both the HA and CNs. Following this > proposition, security > > > concerns have been raised, particulalry about authorization. > > > Authorization issues have largely accounted for the delay of the > > > acceptance of my idea. The idea behind the sub-option > introduced in > > > MIPv6-14 seems to be taken from my draft, though a bit > more limited, > > > since it only carries the prefix length, not the prefix > itself. The > > > same authorization (and other security) concerns apply > to this new > > > sub-option, particularly when it is sent to CNs. I am > quite amazed to > > > see that no one has waved the security flag this time. > Problably most > > > people are busy, or have missed this section. > > > > > > Given the fact that "Network Mobility Support" is not > yet a working > > > group item and that the problem is not even perceived by > the WG, the > > > most immediate result relative to section 4.8 is that the MIPv6 > > > specification may be further delayed. This is > something we can not > > > afford. MIPv6 has been delayed long enough, it's not the > right moment to > > > introduce new feartures in the MIPv6 document itself. > The introduction > > > of new features would in turn introduce potential new > holes (particulary > > > securiry holes) that would further delay the spec. for Proposed > > > Standard. > > > > > > My conclusions are: > > > > > > - Section 4.8 and sub-option "Mobile Router Prefix > Length" SHOULD be > > > removed from the MIPv6 draft, > > > > > > - modifications to the MIPv6 draft specification MUST be > discussed on > > > the mailing list prior to their addition in a WG document, > > > > > > - extensions to the Mobile IPv6 specification, if not > discussed on the > > > mailing list, MUST be presented in a separate document, > > > > > > - Network Mobility Support SHOULD NOT be added in the MIPv6 > > > specification itself - it is a distinct problem, it has > its own solution > > > IMHO > > > > > > - The problem and the requirements to solve "Network > Mobility Support" > > > SHOULD be discussed first. > > > > > > BTW, I have written a new draft "Network Mobility > Support in IPv6: > > > Problem Statement and Requirements" > > > > http://www.ietf.org/internet-drafts/draft-ernst-mobileip-monet v6-00.txt > > for the purpose of discussing the last item. If you have interest in > > this discussion, a post on this mailing list PRIOR to the WG meeting > > would be more than welcome. > > > > Regards, > > Thierry. > > > > -- > > * mailto:Thierry.Ernst@inrialpes.fr Tel +33 (0) 4 76 61 52 69 > > * INRIA Rhone-Alpes Projet PLANETE (fax 52 52) > > * and MOTOROLA Labs Paris > > * http://www.inrialpes.fr/planete/people/ernst/Welcome.html > > -- > T.J. Kniveton > Communications Systems Lab > Nokia Research Center From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 31 12:20:49 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24313 for ; Tue, 31 Jul 2001 12:20: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 KAA16879; Tue, 31 Jul 2001 10:19:23 -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 JAA03523; Tue, 31 Jul 2001 09:19:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6VGHod06365 for mobile-ip-dist; Tue, 31 Jul 2001 09:17:50 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6VGHlY06358 for ; Tue, 31 Jul 2001 09:17:47 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA16446 for ; Tue, 31 Jul 2001 09:18:01 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA13697 for ; Tue, 31 Jul 2001 09:18:00 -0700 (PDT) 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 f6VGHxg14225; Tue, 31 Jul 2001 09:17:59 -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 ABK07978; Tue, 31 Jul 2001 09:17:59 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA12700; Tue, 31 Jul 2001 09:17:59 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15206.55862.881880.527946@thomasm-u1.cisco.com> Date: Tue, 31 Jul 2001 09:17:58 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Cc: Jari Arkko , Hesham.Soliman@era.ericsson.se, charliep@iprg.nokia.com Subject: RE: [mobile-ip] Concern over draft-team-mobileip-mipv6-sec-reqts- 00.txt In-Reply-To: <85AA7486A2C1D411BCA20000F8073E4302F85708@crchy271.us.nortel.com> References: <85AA7486A2C1D411BCA20000F8073E4302F85708@crchy271.us.nortel.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 Glenn Morrow writes: > I believe that piggybacking is very important and would prefer to keep the > existing proposal than get rid of it. Piggybacking may not be as important as it seems. Layer 2 concatenation of transmit frames -- a generally good feature with slow uplinks -- may mitigate the desire for piggybacking, and certainly plays better on the KISS front. Mike From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 31 12:26:31 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24693 for ; Tue, 31 Jul 2001 12:26:30 -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 JAA24233; Tue, 31 Jul 2001 09:25:24 -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 JAA04649; Tue, 31 Jul 2001 09:23:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6VGLeZ06436 for mobile-ip-dist; Tue, 31 Jul 2001 09:21:40 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6VGLbY06428 for ; Tue, 31 Jul 2001 09:21:37 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA17118 for ; Tue, 31 Jul 2001 09:21:46 -0700 (PDT) Received: from netmail2.alcatel.com (netmail2.alcatel.com [128.251.168.51]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA15706 for ; Tue, 31 Jul 2001 09:21:40 -0700 (PDT) Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80]) by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id LAA22998 for ; Tue, 31 Jul 2001 11:21:38 -0500 (CDT) Received: from usa.alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f6VGLbl02893 for ; Tue, 31 Jul 2001 11:21:37 -0500 (CDT) Message-ID: <3B66CC23.2B59913C@usa.alcatel.com> Date: Tue, 31 Jul 2001 11:17:55 -0400 From: Behcet Sarikaya X-Mailer: Mozilla 4.76 [en]C-CCK-MCD BDPjm-Sony3 (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Concerns about draft-mipv6-14 section 4.8 References: <0DF9FBC42474A24CA50F7A27FB08E0484455F8@meshpdc.meshnetworks.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 Phil, Let me disagree. What is wrong with the base protocol spec providing base solutions? This is the case for handover. Should we discard the handover text also? Afterall mipv4 spec contains some discussion on Mobile Routers, maybe Charlie wanted to provide compatibility (just second guessing). Thierry's work can and should continue and I am sure this 'll solve his objection. Phillip Neumiller wrote: > I agree and a more appropriate place to discuss it may be the > MANET group where it has been pretty quiet lately. > > -Phil > > > -----Original Message----- > > From: Michael Thomas [mailto:mat@cisco.com] > > Sent: Tuesday, July 31, 2001 10:53 AM > > To: mobile-ip@sunroof.eng.sun.com > > Subject: Re: [mobile-ip] Concerns about draft-mipv6-14 section 4.8 > > > > > > I'll throw my support backing it out again > > too. Mobile routers are going to involve a lot of > > consideration, because they have some pretty far > > reaching implications. They should be taken up as > > a separate working group item instead of letting > > it bog down mipv6. > > > > Mike > > > > T.J. Kniveton writes: > > > I agree with Thierry here - the discussions on the list > > and at meetings > > > have shown that there is interest in making mobile > > prefixes work within > > > the context of MIPv6 handovers. The key phrase here is > > problem scope -- > > > it should be broken down to a solvable level, and > > especially limited > > > within the base draft (which I believe was the intention). > > To make it > > > really work, security issues must be solved first. Which > > leads us to the > > > question, for MIPv6 expediency's sake, why not leave it as > > a separate > > > draft? > > > > > > -TJ > > > > > > > > > > > > Thierry Ernst wrote: > > > > > > > > Dear all, > > > > > > > > One of the changes of the MIPv6 draft from version 13 to > > 14 is the > > > > addition of a section "Mobile Routers" (section 4.8) and a new > > > > sub-option "Mobile Router Prefix Length" (section 5.5). > > I have some > > > > concerns about these additions that I would like to > > share with the WG: > > > > > > > > o I think that more issues are added than solved by this new > > > > sub-option: > > > > - security (authorization) > > > > - How is it processed by the HA and the CNs > > > > - How is it used by the HA and the CNs > > > > - ... > > > > > > > > o It does only solve part of the problems already > > highlighted last year > > > > in the WG meetings and in the mailing list > > > > > > > > o There are a number of other problems that we have not > > even noticed or > > > > at least debated. > > > > > > > > o what is the exact meaning of "any home address" in > > section 5.5 ? > > > > > > > > I think that the support of mobile routers and networks > > (let's call this > > > > "Network Mobility Support") deserves more than a > > section. Particularly > > > > a terminology that defines what we are speaking about > > and that limits > > > > the scope of the problem that could be solve by the MIP > > spec. would be > > > > welcome prior to this. > > > > > > > > Indeed, I am quite surprised to see a new section that has not > > > > previously been discussed nor shared with the people on > > this mailing > > > > list, particularly not with the authors of draft > > > > > > http://www.ietf.org/internet-drafts/draft-ernst-mobileip-v6-ne > > twork-02.txt. > > > > This draft that I wrote highlighted some issues in the MIPv6 > > > > specification for "Network Mobility Support". As a > > result of past > > > > discussions, some people have agreed that MIPv6 needs > > clarifications for > > > > the HA to redirect packets to nodes behind the mobile > > router. This is > > > > not clarified in MIPv6-14, a clarification would have > > made more sense > > > > than the addition of a new feature in the WG doc itself. > > > > > > > > Moreover, my draft has introduced a "Mobile Network > > Prefix" sub-option > > > > that carries the prefix of the mobile network as part of > > the BU. This > > > > BU is sent to both the HA and CNs. Following this > > proposition, security > > > > concerns have been raised, particulalry about authorization. > > > > Authorization issues have largely accounted for the delay of the > > > > acceptance of my idea. The idea behind the sub-option > > introduced in > > > > MIPv6-14 seems to be taken from my draft, though a bit > > more limited, > > > > since it only carries the prefix length, not the prefix > > itself. The > > > > same authorization (and other security) concerns apply > > to this new > > > > sub-option, particularly when it is sent to CNs. I am > > quite amazed to > > > > see that no one has waved the security flag this time. > > Problably most > > > > people are busy, or have missed this section. > > > > > > > > Given the fact that "Network Mobility Support" is not > > yet a working > > > > group item and that the problem is not even perceived by > > the WG, the > > > > most immediate result relative to section 4.8 is that the MIPv6 > > > > specification may be further delayed. This is > > something we can not > > > > afford. MIPv6 has been delayed long enough, it's not the > > right moment to > > > > introduce new feartures in the MIPv6 document itself. > > The introduction > > > > of new features would in turn introduce potential new > > holes (particulary > > > > securiry holes) that would further delay the spec. for Proposed > > > > Standard. > > > > > > > > My conclusions are: > > > > > > > > - Section 4.8 and sub-option "Mobile Router Prefix > > Length" SHOULD be > > > > removed from the MIPv6 draft, > > > > > > > > - modifications to the MIPv6 draft specification MUST be > > discussed on > > > > the mailing list prior to their addition in a WG document, > > > > > > > > - extensions to the Mobile IPv6 specification, if not > > discussed on the > > > > mailing list, MUST be presented in a separate document, > > > > > > > > - Network Mobility Support SHOULD NOT be added in the MIPv6 > > > > specification itself - it is a distinct problem, it has > > its own solution > > > > IMHO > > > > > > > > - The problem and the requirements to solve "Network > > Mobility Support" > > > > SHOULD be discussed first. > > > > > > > > BTW, I have written a new draft "Network Mobility > > Support in IPv6: > > > > Problem Statement and Requirements" > > > > > > http://www.ietf.org/internet-drafts/draft-ernst-mobileip-monet > v6-00.txt > > > for the purpose of discussing the last item. If you have interest in > > > this discussion, a post on this mailing list PRIOR to the WG meeting > > > would be more than welcome. > > > > > > Regards, > > > Thierry. > > > > > > -- > > > * mailto:Thierry.Ernst@inrialpes.fr Tel +33 (0) 4 76 61 52 69 > > > * INRIA Rhone-Alpes Projet PLANETE (fax 52 52) > > > * and MOTOROLA Labs Paris > > > * http://www.inrialpes.fr/planete/people/ernst/Welcome.html > > > > -- > > T.J. Kniveton > > Communications Systems Lab > > Nokia Research Center Kind regards, -- Behcet From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 31 12:26:51 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24724 for ; Tue, 31 Jul 2001 12:26:50 -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 JAA24332; Tue, 31 Jul 2001 09:25:35 -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 JAA04984; Tue, 31 Jul 2001 09:24:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6VGNII06466 for mobile-ip-dist; Tue, 31 Jul 2001 09:23:18 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.86.31] (may be forged)) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6VGNFY06459 for ; Tue, 31 Jul 2001 09:23:15 -0700 (PDT) Received: from locked (locked.Eng.Sun.COM [129.146.85.189]) by jurassic.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with SMTP id f6VGNLS494942; Tue, 31 Jul 2001 09:23:21 -0700 (PDT) Message-Id: <200107311623.f6VGNLS494942@jurassic.eng.sun.com> Date: Tue, 31 Jul 2001 09:21:54 -0700 (PDT) From: Mohan Parthasarathy Subject: RE: [mobile-ip] Concern over draft-team-mobileip-mipv6-sec-reqts- 00.txt To: mobile-ip@sunroof.eng.sun.com, Jari.Arkko@lmf.ericsson.se Cc: Hesham.Soliman@era.ericsson.se, charliep@iprg.nokia.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: CeA87URTU7bpFQvPElIFMQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 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: > > I believe that piggybacking is very important and would prefer to keep the > existing proposal than get rid of it. You can always spend time later > developing something generic. The current proposal is on-scope and quite > pragmatic without giving anything up other than it just doesn't use IPSEC. > Could you explain more on why piggybacking is important ? When MIPv6 is deployed, do we know how often a binding update will be sent ? Is it your concern that there will be too many binding update packets on the network ? -thanks mohan > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Tuesday, July 31, 2001 9:32 AM > To: Jari Arkko > Cc: Hesham.Soliman@era.ericsson.se; charliep@iprg.nokia.com; > mat@cisco.com; mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Concern over > draft-team-mobileip-mipv6-sec-reqts-00.txt > > > Jari Arkko writes: > > Of course, we must remember to keep separate the > > packet protection and the key management problems. > > The minutes from IETF #50 that Vijay referred to > > discussed mostly the key management issues. It > > seems very clear that there is working group consensus > > on that BUs can't use IKE, KINK, PKI, AAA etc. > > Actually, I don't think there's consensus about > _not_ using IKE etc. There is clear direction > from the IESG that PKI/centralized keying cannot > be the _only_ method of protecting BU's, especially > for random MN/CN situations. Where you can use > strong crypto (same administrative domain, say), > it should be used in preference to a scheme based > on a return routability test. > > One other nit with notes: IPsec (IKE/strong > authentication, really) does protect against > man in the middle attacks, something that a > return routablity test based scheme would not > be able to defend against. > > > But back to the BUs themselves. If it is not possible > > to allocate a new next header value, the granularity > > of standard IPsec policies isn't today sufficient (no > > destination options looked). > > I don't understand this: destination options are not > supposed to be touched in the middle. Requiring > all destination options to be protected -- not just > BU's -- sounds like a *feature* to me. This requires > no changes to IPsec. > > > Going further: if it is not possible to keep the BUs > > in separate packets, then the above change to the > > granularity of packets would be sufficient to send > > even piggypacked BUs. In this case the IPsec policies > > would state that packets from anywhere to us would > > have to have protection if they contained a BU option. > > If you set up a selector which only selected > based on IP addresses, you could piggyback > with IPsec as it stands today. I'm not sure > that piggybacking is really worth the grief > that it's causing though. > > Mike From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 31 13:24:42 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA01727 for ; Tue, 31 Jul 2001 13:24:41 -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 KAA24666; Tue, 31 Jul 2001 10:23: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 KAA20452; Tue, 31 Jul 2001 10:23:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6VHM2506811 for mobile-ip-dist; Tue, 31 Jul 2001 10:22:02 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6VHLwY06800 for ; Tue, 31 Jul 2001 10:21:58 -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 KAA19380 for ; Tue, 31 Jul 2001 10:22:05 -0700 (PDT) Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA26556 for ; Tue, 31 Jul 2001 11:23:33 -0600 (MDT) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id NAA24410 for ; Tue, 31 Jul 2001 13:16:15 -0400 Received: from rotala.raleigh.ibm.com (root@rotala.raleigh.ibm.com [9.37.60.3]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id NAA29376 for ; Tue, 31 Jul 2001 13:21:58 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.9.3/8.7/RTP-ral-1.0) with ESMTP id NAA12323 for ; Tue, 31 Jul 2001 13:20:22 -0400 Message-Id: <200107311720.NAA12323@rotala.raleigh.ibm.com> To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] on using IPsec to secure Binding Updates In-Reply-To: Message from Michael Thomas of "Tue, 31 Jul 2001 07:32:23 PDT." <15206.49527.863582.976611@thomasm-u1.cisco.com> Date: Tue, 31 Jul 2001 13:20:22 -0400 From: Thomas Narten 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: Michael Thomas writes: > Actually, I don't think there's consensus about _not_ using IKE > etc. There is clear direction from the IESG that PKI/centralized > keying cannot be the _only_ method of protecting BU's, especially > for random MN/CN situations. Where you can use strong crypto > (same administrative domain, say), it should be used in > preference to a scheme based on a return routability test. This is from the top of my head, and may be incomplete, but there have been a number of issues raised with using IPsec. That doesn't mean that using IPsec for securing BUs is completely DOA, but it does mean we may well want to to consider an alternate approach. Some people feel more strongly about this than others. Issues: 1) absence of global PKI (which is needed to avoid MITM) note: this is likely a "problem" with all proposals. Unless the two endpoints have some sort of shared knowledge (e.g, key, CA, etc.), there is no way to avoid MITM. Thus, IPsec (if used between MN and CN) would not in practice avoid MITM. Thus, it may provide less protection that folks assume, and may be a bit more expensive than other approaches that provide the same protection. 2) cpu cost of operations is significant, and perhaps overkill given the function. (see point 3) 3) cost/number of packets involved in setting up SAs. Again, this seems to be overkill for the need at hand. It takes a lot of work and packets to set up proper state before the BU can be authenticated. Has someone done the math to make this clear? Maintenance of state on large servers is also an issue that has been raised. It is one thing to setup state for flows that will use that state heavily (e.g., a TCP connection that encrypts the entire flow). It is another to setup state that is only used for occasional packets (i.e, the ones with BUs). 4) incompatability of how filters are coded compared to what is needed As currently specified (and implemented), the IPsec policy database doesn't support the desired granularity of filtering. For example: - It doesn't allow filtering on packets with just a BU. - The current filtering rules do not support selective filtering of packets. I.e., either all the packets for a particular flow would need to be protected by IPsec (in case one contained a BU) or none would (in which case the BU would need to be ignored) Note: some these issues could be addressed by writing a MIP-specific IPsec document that added more functionality. This would need to be done for correspondances between the MN and HA, but that might be OK. I.e, implementations of MNs aren HAs are presumably special devices and putting extra requirements on them are perhaps acceptable. However, it is not clear that it would be appropriate (in general) to require all CNs (and by implication *all* nodes) to also implement this. But we *are* looking for a solution that allows arbitrary MNs and CNs to do route optimization. In any case, the current (and previous) version of the spec didn't have enough details on how to use IPsec in this manner and these issues would need to be clarified to fully evaluate this approach. Thus, while one certainly could imagine making IPsec fit, it is not at all clear that it is the most desirable approach given the actual function at hand. The idea of only allowing BUs as standalone issues would appear to address some of the issues above, but not all. Of course, eliminating piggy backing, removes an optimization that also has benefits. Thomas From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 31 13:42:48 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA02691 for ; Tue, 31 Jul 2001 13:42:47 -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 IAA13021; Tue, 31 Jul 2001 08:08: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 IAA18952; Tue, 31 Jul 2001 08:02:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6VF0nb05443 for mobile-ip-dist; Tue, 31 Jul 2001 08:00:49 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6VF0jY05436 for ; Tue, 31 Jul 2001 08:00:45 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA03859 for ; Tue, 31 Jul 2001 08:00:55 -0700 (PDT) From: Basavaraj.Patil@nokia.com Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA26243 for ; Tue, 31 Jul 2001 08:00:41 -0700 (PDT) Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f6VF0Wi22358 for ; Tue, 31 Jul 2001 10:00:44 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Tue, 31 Jul 2001 10:00:28 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.1600); Tue, 31 Jul 2001 10:00:28 -0500 content-class: urn:content-classes:message Subject: RE: [mobile-ip] Question on draft-team-mobileip-mipv6-sec-reqts-0 0.txt Date: Tue, 31 Jul 2001 10:00:27 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF44086139@daebe007.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [mobile-ip] Question on draft-team-mobileip-mipv6-sec-reqts-0 0.txt X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 Thread-Index: AcEZxnYQQEz4OYW5EdWJUgAIx6TWpQACq9TA To: , Cc: X-OriginalArrivalTime: 31 Jul 2001 15:00:28.0233 (UTC) FILETIME=[891D1B90:01C119D1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f6VF0kY05437 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 > > Is there a design team to establish the security requirements > for MIPv6? There is no design team. The security requirements document has been published and the requirements in this document should be used as the basis for designing solutions. Of course we still need to get consensus from WG members w.r.t these requirements. The requirements document is : draft-team-mobileip-mipv6-sec-reqts-00.txt > I have not been following this lately. If there is, could I be > added to the > team. I also need more information on how the team is run, so I would > appreciate it if the team leader can send me information, > teleconference > schedules etc. Thanks. > > -Sharif > -Basavaraj From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 31 13:59:07 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA03774 for ; Tue, 31 Jul 2001 13:59:07 -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 KAA12274; Tue, 31 Jul 2001 10:58: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 KAA28582; Tue, 31 Jul 2001 10:58:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6VHtmx06924 for mobile-ip-dist; Tue, 31 Jul 2001 10:55:48 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6VHthY06917 for ; Tue, 31 Jul 2001 10:55:43 -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 KAA27475 for ; Tue, 31 Jul 2001 10:55:57 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA09489 for ; Tue, 31 Jul 2001 11:55:55 -0600 (MDT) 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 f6VHu9Y21964 for ; Tue, 31 Jul 2001 10:56: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 ABK11093; Tue, 31 Jul 2001 10:55:54 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA12706; Tue, 31 Jul 2001 10:55:51 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15206.61734.965790.717631@thomasm-u1.cisco.com> Date: Tue, 31 Jul 2001 10:55:50 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] on using IPsec to secure Binding Updates In-Reply-To: <200107311720.NAA12323@rotala.raleigh.ibm.com> References: <15206.49527.863582.976611@thomasm-u1.cisco.com> <200107311720.NAA12323@rotala.raleigh.ibm.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 Any alternate scheme for allowing strong crypto for BU's where that is appropriate (eg, MN/HA) would need to have answers for doing automated key distribution. IPsec currently has ways of using PKI, pre-shared keys, and Kerberos (both the GSSAPI mode of IKE and directly using KINK). There are none for an alternative scheme. None of the issues you raise, IMHO, come anywhere close to the extremely high hurdle of building or extending existing key distribution protocols. A few more comments in line: Thomas Narten writes: > Michael Thomas writes: > > > Actually, I don't think there's consensus about _not_ using IKE > > etc. There is clear direction from the IESG that PKI/centralized > > keying cannot be the _only_ method of protecting BU's, especially > > for random MN/CN situations. Where you can use strong crypto > > (same administrative domain, say), it should be used in > > preference to a scheme based on a return routability test. > > This is from the top of my head, and may be incomplete, but there have > been a number of issues raised with using IPsec. That doesn't mean > that using IPsec for securing BUs is completely DOA, but it does mean > we may well want to to consider an alternate approach. Some people > feel more strongly about this than others. > > Issues: > > 1) absence of global PKI (which is needed to avoid MITM) note: this is > likely a "problem" with all proposals. Unless the two endpoints > have some sort of shared knowledge (e.g, key, CA, etc.), there is > no way to avoid MITM. > > Thus, IPsec (if used between MN and CN) would not in practice avoid > MITM. Thus, it may provide less protection that folks assume, and > may be a bit more expensive than other approaches that provide the > same protection. What I think we all need to keep in mind is that there are really *two* separate problem spaces with securing BU's. The one is where authentication localization is practical and the other where it is not. The MN/HA and _some_ situations with MN/CN (say, within an enterprise) fit category 1. The second problem is not practically solved by PKI, etc, and as such needs to have some of the requirements relaxed (namely, MITM). > 2) cpu cost of operations is significant, and perhaps overkill given > the function. (see point 3) > 3) cost/number of packets involved in setting up SAs. Again, this > seems to be overkill for the need at hand. It takes a lot of work > and packets to set up proper state before the BU can be > authenticated. Has someone done the math to make this clear? > Maintenance of state on large servers is also an issue that has > been raised. The state is inherent in symmetric key crypto, not IPsec per se. Also: KINK and AAA based keying are much better than IKE's 6 message main mode/quick mode exchange. AlsoL any alternate keying scheme would face the same problems. Again, this only applies where you can take advantage of strong authentication. > It is one thing to setup state for flows that will use that state > heavily (e.g., a TCP connection that encrypts the entire flow). It > is another to setup state that is only used for occasional packets > (i.e, the ones with BUs). Unless you are willing to require public key signed BU's, there is no way to avoid this problem. And public key signed BU's would be no panecea: public key operations are *very* CPU intensive. > 4) incompatability of how filters are coded compared to what is needed > As currently specified (and implemented), the IPsec policy > database doesn't support the desired granularity of filtering. For > example: > > - It doesn't allow filtering on packets with just a BU. > - The current filtering rules do not support selective filtering of > packets. I.e., either all the packets for a particular flow would > need to be protected by IPsec (in case one contained a BU) or > none would (in which case the BU would need to be ignored) It seems that you're just restating that IPsec filters on 5-tuples. Correct? > Note: some these issues could be addressed by writing a > MIP-specific IPsec document that added more functionality. As I've said before, I have no idea why you would only want to protect BU's, but not other destination options. If the destination options weren't piggybacked, they could easily be selectively authenticated using standard IPsec. > Thus, while one certainly could imagine making IPsec fit, it is not at > all clear that it is the most desirable approach given the actual > function at hand. This needs to be weighed primarily against the key distribution problem. I am willing to bet $1 that there isn't going to be a lot of enthusiasm for writing a BU specific DOI for IKE, KINK, etc. Mike From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 31 13:59:15 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA03787 for ; Tue, 31 Jul 2001 13:59:14 -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 LAA11566; Tue, 31 Jul 2001 11: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 KAA28575; Tue, 31 Jul 2001 10:58:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6VHuKe06933 for mobile-ip-dist; Tue, 31 Jul 2001 10:56:20 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6VHuHY06926 for ; Tue, 31 Jul 2001 10:56:17 -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 KAA28174 for ; Tue, 31 Jul 2001 10:56:31 -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 LAA14878 for ; Tue, 31 Jul 2001 11:58: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 KAA11823 for ; Tue, 31 Jul 2001 10:56:30 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6VHuT500662 for ; Tue, 31 Jul 2001 10:56:29 -0700 X-mProtect: Tue, 31 Jul 2001 10:56:29 -0700 Nokia Silicon Valley Messaging Protection Received: from vijayd.iprg.nokia.com (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpd5EWBJ6; Tue, 31 Jul 2001 10:56:28 PDT Message-ID: <3B66F14C.A00A0B96@iprg.nokia.com> Date: Tue, 31 Jul 2001 10:56:28 -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: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Concern over draft-team-mobileip-mipv6-sec-reqts-00.txt References: <034BEFD03799D411A59F00508BDF754603008B94@esealnt448.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: > > Vijay, > > > take a look at this. > > > > http://www.ietf.org/proceedings/01mar/ietf50-91.htm#TopOfPage > > > > look at Jeff Schiller's comments. > > > => My point is this: > - If we disallow piggybacking, > - develop some other key exchange mechnism (like BAKE or one of Mike's proposals) > > Then I don't see why we can't use IPsec provided that the granularity > of the IPsec selectors is fixed. Seems like an implementation > issue (the policy part). Have I missed something ? i partly agree with you. i have personally implemented this fix. but the problem is that this fix needs to be implemented in every correspondent node. i wouldnt calls this an implementation issue. vijay > > Hesham > > > "Hesham Soliman (ERA)" wrote: > > > > > > > > > > > > > While you're answering question (or someone else who knows > > > > > IPsec better than me), are there any problems foreseen with IPsec > > > > > if we simply get rid of piggybacking the BUs and send them > > > > > in separate packets ? > > > > > I thought not, but would like some confirmation. > > > > > > > > > The only other constraint is that there is no selector for protecting > > > > just binding update. IPsec policy allows you to select based on > > > > the IPv6 "nxt" headers. In this case, it would be a destination > > > > option. But binding update is just one type of such an option. > > > > So, all destination options would be protected if you use > > > > IPsec as it exists today. > > > > > > > => Sure but we can have a new type header for it, that is > > > if you can't increase the granulaity of the policies. Is this > > > really a problem ? > > > > > > > > Others that were mentioned in the past are : > > > > > > > > 1) Why only AH ? It is too restrictive. > > > > > > > => Yes, that's another issue. I just wanted > > > to know if there were any show stoppers, it > > > seems like the selectors are the only issue. > > > > > > Hesham > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Michael Thomas [SMTP:mat@cisco.com] > > > > > > Sent: Monday, 30 July 2001 10:58 > > > > > > To: mobile-ip@sunroof.eng.sun.com > > > > > > Subject: RE: [mobile-ip] Concern over > > > > draft-team-mobileip-mipv6-sec-reqts- 00.txt > > > > > > > > > > > > Glenn Morrow writes: > > > > > > > Michael, > > > > > > > > > > > > > > You may have a point but please do us the favor of answering these > > > > > > > questions: > > > > > > > > > > > > > > 1> Do you believe that the credentials associated with an SA for node > > > > > > > mobility would ALWAYS be the same as the credentials for another SA for > > > > an > > > > > > > application on two communicating hosts? > > > > > > > > > > > > Not always. Sometimes though (maybe often even). > > > > > > > > > > > > > 2> Can there be more than one ESP header in a single IP packet without > > > > > > > tunneling? > > > > > > > > > > > > Not to my knowledge. > > > > > > > > > > > > > 3> Has there been any succesful work at changing the answer to question 2 > > > > or > > > > > > > perhaps defining some new generic multi-purpose IP-layer encryption > > > > option > > > > > > > perhaps with different properties? > > > > > > > > > > > > Not to my knowledge. > > > > > > > > > > > > > > 4> Has there been any successful work at changing the fact that a BU > > > > can be > > > > > > > sent in the same packet as an application PDU? > > > > > > > > > > > > Not sure what you're asking here... Are you asking if there's > > > > > > been an implementation of piggybacked BU's? > > > > > > > > > > > > Mike From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 31 14:26:08 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA06178 for ; Tue, 31 Jul 2001 14:26:07 -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 MAA03148; Tue, 31 Jul 2001 12:25: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 LAA04631; Tue, 31 Jul 2001 11:25:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6VINln07103 for mobile-ip-dist; Tue, 31 Jul 2001 11:23:48 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6VINiY07096 for ; Tue, 31 Jul 2001 11:23:44 -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 LAA04507 for ; Tue, 31 Jul 2001 11:23:57 -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 MAA01739 for ; Tue, 31 Jul 2001 12:23: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 LAA15116 for ; Tue, 31 Jul 2001 11:23:55 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6VINsC04400 for ; Tue, 31 Jul 2001 11:23:54 -0700 X-mProtect: Tue, 31 Jul 2001 11:23:54 -0700 Nokia Silicon Valley Messaging Protection Received: from vijayd.iprg.nokia.com (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdVLfG3t; Tue, 31 Jul 2001 11:23:53 PDT Message-ID: <3B66F7B9.51090EC0@iprg.nokia.com> Date: Tue, 31 Jul 2001 11:23:53 -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: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Authentication Data as a BU suboption References: <200107311720.NAA12323@rotala.raleigh.ibm.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, I like authentication data as a BU suboption. this authentication data protects the BU option and the home address option alone. nothing else. draft-14 gives a cleaner solution for authenticating BU's IMO. advantages ---------- 1. we dont have to get a new next header value for the destination options header containing the BU 2. we dont have to modify the ipsec selectors 3. we dont have to protect the whole packet 4. we dont have bother about the traffic flows between the MN and the CN. 5. we can piggyback BU's. somebody asked a question if BU's are sent often. YES, BUs could be sent often to refresh the bindings. its not necessary the home agents agree to very large lifetimes for BUs. and BUs are sent to everybody in your binding update list everytime you move. 6. we dont have to store the security association for protecting the BU in the ipsec database. lookup is expensive. it could be stored in the binding update list entries. you already have access to the key. 7. authentication checksum calculation can be done very early (ie when the BU is being formed). in the current implementations you pull the packet out from the ip6_output function, calculate the checksum and put it out again in the ip6_output function. this is because you cant calculate the checksum until the whole packet has been formed. 8. mobile ip code just calls hmac_md5 function supplying the text and the key. thats all. so THIS is better. why dont we forget IPSec. hope you guys have read Thomas Narten's mail. draft-14 gives a cleaner alternative solution to IPsec Vijay From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 31 14:34:52 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA06918 for ; Tue, 31 Jul 2001 14:34:51 -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 LAA29611; Tue, 31 Jul 2001 11:34:05 -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 LAA06630; Tue, 31 Jul 2001 11:33:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6VIW9007169 for mobile-ip-dist; Tue, 31 Jul 2001 11:32:09 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6VIW0Y07162 for ; Tue, 31 Jul 2001 11:32:00 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA22554 for ; Tue, 31 Jul 2001 11:32:08 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA06243 for ; Tue, 31 Jul 2001 11:32: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 LAA15898 for ; Tue, 31 Jul 2001 11:32:07 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6VIW6k24080 for ; Tue, 31 Jul 2001 11:32:06 -0700 X-mProtect: Tue, 31 Jul 2001 11:32:06 -0700 Nokia Silicon Valley Messaging Protection Received: from vijayd.iprg.nokia.com (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdKVzhCh; Tue, 31 Jul 2001 11:32:05 PDT Message-ID: <3B66F9A5.3C2B4000@iprg.nokia.com> Date: Tue, 31 Jul 2001 11:32: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: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Re: Authentication Data as a BU suboption References: <200107311720.NAA12323@rotala.raleigh.ibm.com> <3B66F7B9.51090EC0@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 and the keys are obtained through BAKE or whichever proposal that gets accepted. dont bother IPSec and IKE folks. let them build their VPNs. vijay Vijay Devarapalli wrote: > > hi, > > I like authentication data as a BU suboption. this > authentication data protects the BU option and the > home address option alone. nothing else. draft-14 > gives a cleaner solution for authenticating BU's IMO. > > advantages > ---------- > > 1. we dont have to get a new next header value for the > destination options header containing the BU > > 2. we dont have to modify the ipsec selectors > > 3. we dont have to protect the whole packet > > 4. we dont have bother about the traffic flows between > the MN and the CN. > > 5. we can piggyback BU's. somebody asked a question if > BU's are sent often. YES, BUs could be sent often to > refresh the bindings. its not necessary the home agents > agree to very large lifetimes for BUs. and BUs are sent > to everybody in your binding update list everytime you > move. > > 6. we dont have to store the security association for > protecting the BU in the ipsec database. lookup is > expensive. it could be stored in the binding update > list entries. you already have access to the key. > > 7. authentication checksum calculation can be done > very early (ie when the BU is being formed). in the > current implementations you pull the packet out from > the ip6_output function, calculate the checksum and > put it out again in the ip6_output function. this is > because you cant calculate the checksum until the > whole packet has been formed. > > 8. mobile ip code just calls hmac_md5 function > supplying the text and the key. thats all. > > so THIS is better. why dont we forget IPSec. hope > you guys have read Thomas Narten's mail. draft-14 > gives a cleaner alternative solution to IPsec > > Vijay From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 31 14:37:52 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07141 for ; Tue, 31 Jul 2001 14:37:51 -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 LAA01103; Tue, 31 Jul 2001 11:37: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 LAA07428; Tue, 31 Jul 2001 11:36:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6VIYbA07197 for mobile-ip-dist; Tue, 31 Jul 2001 11:34:37 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6VIYXY07190 for ; Tue, 31 Jul 2001 11:34:33 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA23220 for ; Tue, 31 Jul 2001 11:34:41 -0700 (PDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA07503 for ; Tue, 31 Jul 2001 11:34:36 -0700 (PDT) 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 f6VIWnJ20832 for ; Tue, 31 Jul 2001 11:32:49 -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 ABK12476; Tue, 31 Jul 2001 11:33:41 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA12712; Tue, 31 Jul 2001 11:33:41 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15206.64005.34473.57514@thomasm-u1.cisco.com> Date: Tue, 31 Jul 2001 11:33:41 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Authentication Data as a BU suboption In-Reply-To: <3B66F7B9.51090EC0@iprg.nokia.com> References: <200107311720.NAA12323@rotala.raleigh.ibm.com> <3B66F7B9.51090EC0@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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Disadvantages: 1) no standard key distribution 2) no means of encryption 3) no means of cipher suite negotiation 4) no standard key distribution Mike Vijay Devarapalli writes: > hi, > > I like authentication data as a BU suboption. this > authentication data protects the BU option and the > home address option alone. nothing else. draft-14 > gives a cleaner solution for authenticating BU's IMO. > > advantages > ---------- > > 1. we dont have to get a new next header value for the > destination options header containing the BU > > 2. we dont have to modify the ipsec selectors > > 3. we dont have to protect the whole packet > > 4. we dont have bother about the traffic flows between > the MN and the CN. > > 5. we can piggyback BU's. somebody asked a question if > BU's are sent often. YES, BUs could be sent often to > refresh the bindings. its not necessary the home agents > agree to very large lifetimes for BUs. and BUs are sent > to everybody in your binding update list everytime you > move. > > 6. we dont have to store the security association for > protecting the BU in the ipsec database. lookup is > expensive. it could be stored in the binding update > list entries. you already have access to the key. > > 7. authentication checksum calculation can be done > very early (ie when the BU is being formed). in the > current implementations you pull the packet out from > the ip6_output function, calculate the checksum and > put it out again in the ip6_output function. this is > because you cant calculate the checksum until the > whole packet has been formed. > > 8. mobile ip code just calls hmac_md5 function > supplying the text and the key. thats all. > > so THIS is better. why dont we forget IPSec. hope > you guys have read Thomas Narten's mail. draft-14 > gives a cleaner alternative solution to IPsec > > Vijay From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 31 14:40:58 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07521 for ; Tue, 31 Jul 2001 14:40:58 -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 MAA15776; Tue, 31 Jul 2001 12:40:19 -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 LAA08385; Tue, 31 Jul 2001 11:40:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6VIcrI07281 for mobile-ip-dist; Tue, 31 Jul 2001 11:38:53 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6VIcnY07274 for ; Tue, 31 Jul 2001 11:38:49 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA08065 for ; Tue, 31 Jul 2001 11:38:58 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA09379 for ; Tue, 31 Jul 2001 11:38:58 -0700 (PDT) Received: from mchandra-u10.cisco.com (mchandra-u10.cisco.com [64.102.66.20]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f6VIcQg05341; Tue, 31 Jul 2001 11:38:26 -0700 (PDT) Received: (mchandra@localhost) by mchandra-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA05859; Tue, 31 Jul 2001 14:38:10 -0400 (EDT) Date: Tue, 31 Jul 2001 14:38:10 -0400 From: "Madhavi W. Chandra" To: "Charles E. Perkins" Cc: "Madhavi W. Chandra" , Mobile IP Working Group , Pat Calhoun , Alpesh Patel , "Kent K. Leung" Subject: [mobile-ip] Re: mobile-ip] Re: mobile-ip] WG last call: draft-ietf-mobileip-gen-key-00.txt Message-ID: <20010731143810.B5836@cisco.com> References: <20010718115752.A689@cisco.com> <3B61D37F.A75CF9B4@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: <3B61D37F.A75CF9B4@iprg.nokia.com>; from charliep@iprg.nokia.com on Fri, Jul 27, 2001 at 01:47:59PM -0700 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 and Pat, On Fri, Jul 27, 2001 at 01:47:59PM -0700, Charles E. Perkins wrote: > > > Hello folks, > > I submitted a version of the genkey draft, but I turned off my laptop > before the mail had gone out and so I missed last week's deadline. > It turns out that I had forgotten to cite RFC 2119 anyway, and so > it might have been rejected by the IESG. I have re-revised the draft, > and I will resubmit it at the next opportunity. > > The new draft is available at: > http://people.nokia.net/charliep/txt/genkey/genkey.txt > > Here are some additional comments. > > > "Madhavi W. Chandra" wrote: > > > > Hi Charlie and Pat, > > > > We've just started following this draft and are trying to grasp its > > intent. We have a few questions/comments: > > > > 1. Since it is not specified, can the 'Reply' Key extensions be > > appended to both RPYs and RRQs? > > As Pat noted, there should be restrictions. I have added text > to that effect near the end of the Introduction. I'm not clear on the need for the restrictions. Being able to append a 'Request' Key or 'Reply' Key extension to either a RRQ or RPY provides more flexibility. Say, for example, that hierarchical FAs want to share a key...they can append the FA-FA Key Reply Extension to a RRQ as it propagates. Of course, the extensions must be properly secured. > > 2. Section 7, 'FA-FA Key Reply Subtype Data' sounds like a > > description for MN-HA Reply. > > Fixed. > > > > 4. Can the 'Reply' Key extensions in Sections 3 and 5 be sent > > unsolicited to the MN...meaning, not in response to a 'Request' Key > > extension. > if it is requested, then it is returned. However, it *could* be unsolicited. It will be helpful to explicity state this in the draft. We want to be able to push keys to different entities, and hence would like support for unsolicted key exchange. > > 6. When MN sends 'MN-HA Key Request' extension in RRQ, does it append > > MN-AAA AE since no MHAE? So, AAA is doing proxy authentication of MN > > for the HA? Then, HA sends RPY with 'MN-HA Key Reply' > > extension...what AE is used to secure the RPY? > They are independent. If the MN includes the MN-HA Key Request with the > AAA subtype (see AAA keys draft), then it really should include the > MN-AAA extension. However, these are separate drafts, and it makes sense > to leave it that way. > You are correct, though, that the HA would include the MN-HA Key Reply > extenion in the reply message, with the MN-HA auth ext generated using the > newly distributed key. But, how does the MN know this newly generated key to authenticate the MHAE in the RPY? Doesn't the MN first have to parse the RPY to extract the 'MN-HA Key Reply extension' for the key, and then authenticate the RPY. Is this in line with RFC2002? Or am I completely misunderstanding something. > > 7. We would like a mobility agent, say MA-1, to pass key to MA-2 for > > MA-2 to use with MN. If MAs are FAs, then probably the FA-FA Key > > Reply Extension would be used...appended to what MIP message? What if > > the MAs are HAs? > > I agree with Pat's comments about hierarchical FAs being the > motivation for this extension, which seems to belong here. > For the case of home agents, no one ever made such a request, > and I haven't seen any protocol that would use such a thing as > part of any Mobile IPv4 registration message. Even though it's > a bit late, it's not completely impossible to add such a feature. > However, I reckon the burden of proof would be on you to make > the case. The need for HA-HA communication will become important in the case of HA redundancy or load-balancing. The HAs will need to share a security association, which can be dynamically assigned via a AAA server. It's analogous to the hierarchical FA case for future use. We'd like to request this feature to be included. We realize the late nature of this request, and are more than willing to help with text, motivation, etc. Thanks, Madhavi > > Regards, > Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 31 16:18:35 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA18280 for ; Tue, 31 Jul 2001 16:18:34 -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 NAA16467; Tue, 31 Jul 2001 13:17:56 -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 NAA15767; Tue, 31 Jul 2001 13:15:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6VKBTo07760 for mobile-ip-dist; Tue, 31 Jul 2001 13:11:29 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6VKBOY07753 for ; Tue, 31 Jul 2001 13:11:24 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA08042 for ; Tue, 31 Jul 2001 13:11:14 -0700 (PDT) Received: from zcars0m9.ca.nortel.com ([47.129.242.157]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA14543 for ; Tue, 31 Jul 2001 13:11:13 -0700 (PDT) Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f6VKAi928768 for ; Tue, 31 Jul 2001 16:10:44 -0400 (EDT) Received: from zrchb200.us.nortel.com by smtprch1.nortel.com; Tue, 31 Jul 2001 13:00:10 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 31 Jul 2001 12:59:53 -0500 Message-ID: <85AA7486A2C1D411BCA20000F8073E4302F858D6@crchy271.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com, Jari.Arkko@lmf.ericsson.se Cc: Hesham.Soliman@era.ericsson.se, charliep@iprg.nokia.com Subject: RE: [mobile-ip] Concern over draft-team-mobileip-mipv6-sec-reqts- 00.txt Date: Tue, 31 Jul 2001 12:59:45 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C119EA.94A70520" 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_01C119EA.94A70520 Content-Type: text/plain; charset="iso-8859-1" Well simply put, piggybacking allows two things to be accomplished with one packet. I think this is efficient. It seems that if there is a packet on the queue headed for where the BU needs to be sent - might as well kill 2 birds with one stone. I also think that if you need to reserve resources of some sort, the combination might be useful either in conjunction with other options or protocols. I also think you could kill 3 birds with one stone. Glenn > -----Original Message----- Could you explain more on why piggybacking is important ? When MIPv6 is deployed, do we know how often a binding update will be sent ? Is it your concern that there will be too many binding update packets on the network ? -thanks mohan ------_=_NextPart_001_01C119EA.94A70520 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Concern over = draft-team-mobileip-mipv6-sec-reqts- 00.txt

Well simply put, piggybacking allows two things to be = accomplished with one packet. I think this is efficient. It seems that = if there is a packet on the queue headed for where the BU needs to be = sent - might as well kill 2 birds with one stone. I also think that if = you need to reserve resources of some sort, the combination might be = useful either in conjunction with other options or protocols. I also = think you could kill 3 birds with one stone.

Glenn


> -----Original Message-----
Could you explain more on why piggybacking is = important ? When MIPv6
is deployed, do we know how often a binding update = will be sent ?
Is it your concern that there will be too many = binding update packets
on the network ?

-thanks
mohan

------_=_NextPart_001_01C119EA.94A70520-- From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 31 16:26:31 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA18885 for ; Tue, 31 Jul 2001 16:26:31 -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 NAA19892; Tue, 31 Jul 2001 13:25: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 NAA17618; Tue, 31 Jul 2001 13:23:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6VKKBE07810 for mobile-ip-dist; Tue, 31 Jul 2001 13:20:11 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6VKK7Y07803 for ; Tue, 31 Jul 2001 13:20:07 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA28420 for ; Tue, 31 Jul 2001 13:20:16 -0700 (PDT) Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA23479 for ; Tue, 31 Jul 2001 13:20:16 -0700 (PDT) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id QAA28162 for ; Tue, 31 Jul 2001 16:20:11 -0400 Received: from rotala.raleigh.ibm.com (root@rotala.raleigh.ibm.com [9.37.60.3]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id QAA33368 for ; Tue, 31 Jul 2001 16:20:10 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.9.3/8.7/RTP-ral-1.0) with ESMTP id QAA13188 for ; Tue, 31 Jul 2001 16:18:32 -0400 Message-Id: <200107312018.QAA13188@rotala.raleigh.ibm.com> To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] on using IPsec to secure Binding Updates In-Reply-To: Message from Michael Thomas of "Tue, 31 Jul 2001 10:55:50 PDT." <15206.61734.965790.717631@thomasm-u1.cisco.com> Date: Tue, 31 Jul 2001 16:18:32 -0400 From: Thomas Narten 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: Michael Thomas writes: > None of the issues you raise, IMHO, come anywhere close to the > extremely high hurdle of building or extending existing key > distribution protocols. I expect that having this group design a new key negotiation protocol in an attempt to do better/different than IKE is fraught with risks that have been pointed out by many. We should not consider going there without really good cause. I do not know that we are at a point where such a direction is called for or such a decision needs to be made. > > 1) absence of global PKI (which is needed to avoid MITM) note: this is > > likely a "problem" with all proposals. Unless the two endpoints > > have some sort of shared knowledge (e.g, key, CA, etc.), there is > > no way to avoid MITM. > > > > Thus, IPsec (if used between MN and CN) would not in practice avoid > > MITM. Thus, it may provide less protection that folks assume, and > > may be a bit more expensive than other approaches that provide the > > same protection. > What I think we all need to keep in mind is that there are really > *two* separate problem spaces with securing BU's. The one is > where authentication localization is practical and the other > where it is not. I would like to better understand environments where this is makes sense. What are some target deployment scenarios where using pre-shared keys, a local PKI, etc., would make sense? Also, how would the MN & CN *negotiate* which SA to use? Would it have to assume one and then not work in any other environment? What happens when a MN moves outside of the environment where the private PKI is being used? Can a MN operate in two different realms at differnt times? How scalable is all this? I.e., it is not immediately clear to me how useful/desirable it is to to target the first environment (while ignoring the other) and how one would handle the case where one moves from one location to another where different kinds of authentication are appropriate. I.e, would this satisify the needs of those that want MIPv6 route optimization? > The state is inherent in symmetric key crypto, > not IPsec per se. Right. But the cost of the IPsec state and messages is specific to IPsec/IKE. I think *that* is what is at issue, not that there is state. Clearly there has to be some state. > > 4) incompatability of how filters are coded compared to what is needed > > As currently specified (and implemented), the IPsec policy > > database doesn't support the desired granularity of filtering. For > > example: > > > > - It doesn't allow filtering on packets with just a BU. > > - The current filtering rules do not support selective filtering of > > packets. I.e., either all the packets for a particular flow would > > need to be protected by IPsec (in case one contained a BU) or > > none would (in which case the BU would need to be ignored) > It seems that you're just restating that IPsec > filters on 5-tuples. Correct? Yes. > > Note: some these issues could be addressed by writing a > > MIP-specific IPsec document that added more functionality. > As I've said before, I have no idea why you would only want to > protect BU's, but not other destination options. If the > destination options weren't piggybacked, they could easily be > selectively authenticated using standard IPsec. I'm not suggesting anything about whether just the BU or all the destination options should be covered. The issue is that the *current* specs do not support sufficient granularity for dealing with BUs within MIP. The question is how do we fix that. Move to something else? Write a MIPv6-specific IPsec document that specifies how this is being done (and if so, is this really the direction IPsec should go in)? Thomas From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 31 16:41:15 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA19984 for ; Tue, 31 Jul 2001 16:41:15 -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 OAA15827; Tue, 31 Jul 2001 14:40: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 NAA20843; Tue, 31 Jul 2001 13:38:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6VKWWw07906 for mobile-ip-dist; Tue, 31 Jul 2001 13:32:32 -0700 (PDT) Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6VKWOY07895 for ; Tue, 31 Jul 2001 13:32:25 -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 QAA26193 for ; Tue, 31 Jul 2001 16:32:37 -0400 (EDT) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id QAA01429 for mobile-ip@sunroof.eng.sun.com; Tue, 31 Jul 2001 16:33:03 -0400 (EDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6VK3MY07721 for ; Tue, 31 Jul 2001 13:03: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 NAA25018 for ; Tue, 31 Jul 2001 13:03:35 -0700 (PDT) Received: from fep01-app.kolumbus.fi (fep01-0.kolumbus.fi [193.229.0.41]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA17918 for ; Tue, 31 Jul 2001 14:03:33 -0600 (MDT) Received: from jariws1 ([62.248.155.56]) by fep01-app.kolumbus.fi (InterMail vM.5.01.02.00 201-253-122-103-20001017) with SMTP id <20010731200333.BJZC137.fep01-app.kolumbus.fi@jariws1> for ; Tue, 31 Jul 2001 23:03:33 +0300 Message-ID: <00c401c119fb$e3e1db40$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: References: <034BEFD03799D411A59F00508BDF754603008B94@esealnt448.al.sw.ericsson.se> <3B66F14C.A00A0B96@iprg.nokia.com> Subject: Re: [mobile-ip] Concern over draft-team-mobileip-mipv6-sec-reqts-00.txt Date: Tue, 31 Jul 2001 23:03:39 +0300 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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Vijay Devarapalli writes... > > => My point is this: > > - If we disallow piggybacking, > > - develop some other key exchange mechnism (like BAKE or one of Mike's proposals) > > > > Then I don't see why we can't use IPsec provided that the granularity > > of the IPsec selectors is fixed. Seems like an implementation > > issue (the policy part). Have I missed something ? > > i partly agree with you. i have personally implemented this fix. > but the problem is that this fix needs to be implemented in every > correspondent node. i wouldnt calls this an implementation issue. The way I see this is that _current_ IPsec selectors can be used quite fine, IF piggybacking is disallowed AND we have a separate next header value for BUs. Furthermore, _something_ needs to be implemented in every CN before secure BUs work, whatever solution we pick. So I don't think we need to argue about that. So, in my mind our options are the following (again talking only about the BU protection, not the key exchange): a) The mip-specific scheme in the -14 draft b) Standard IPsec usage without piggybacking c) Fixed IPsec which enables piggybacked and/or option-specific selectors Personally, my main preferences are either (a) or (b) solutions. There are differences between these two approaches, but the main significant question seems to be if the piggybacking is needed or not. Has someone looked at the concrete benefits of piggybacking in terms of numbers somewhere, preferrably taking in account various header compression schemes that get to be applied on the most sensitive links? Please note that separate packets can still be sent in parallel, no additional RTTs should be introduced. Also, there might be other factors such as firewall rule sets that affect this discussion. Jari From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 31 16:42:56 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAB20142 for ; Tue, 31 Jul 2001 16:42:55 -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 OAA17053; Tue, 31 Jul 2001 14:42: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 NAA21161; Tue, 31 Jul 2001 13:39:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6VKYVa07961 for mobile-ip-dist; Tue, 31 Jul 2001 13:34:32 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6VKYRY07954 for ; Tue, 31 Jul 2001 13:34:27 -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 NAA03145 for ; Tue, 31 Jul 2001 13:34:41 -0700 (PDT) Received: from fep02-app.kolumbus.fi (fep02-0.kolumbus.fi [193.229.0.44]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA14049 for ; Tue, 31 Jul 2001 14:36:11 -0600 (MDT) Received: from jariws1 ([62.248.155.56]) by fep02-app.kolumbus.fi (InterMail vM.5.01.02.00 201-253-122-103-20001017) with SMTP id <20010731203438.GTXI5930.fep02-app.kolumbus.fi@jariws1>; Tue, 31 Jul 2001 23:34:38 +0300 Message-ID: <00cc01c11a00$3bee9c20$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: Cc: "Thomas Narten" References: <200107311720.NAA12323@rotala.raleigh.ibm.com> Subject: Re: [mobile-ip] on using IPsec to secure Binding Updates Date: Tue, 31 Jul 2001 23:34:44 +0300 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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Thomas Narten writes: > Issues: > ... > Thus, while one certainly could imagine making IPsec fit, it is not at > all clear that it is the most desirable approach given the actual > function at hand. The list of issues is fine, but I think the discussion would benefit if we keep the key exchange and the packet protection issues separate. Global-PKI-as-the-only-BU-key-exchange -issue has been discussed at length earlier, as is many roundtrip and RSA/ Diffie-Hellman efficiency issues. But these aren't necessarily reasons to throw out AH, even if they mean IKE isn't applicable. For instance, the separate-packet-with-new-next-header-value -approach seems to solve all issues related to the use of standard AH with RFC 2401 policies. Or did you Thomas have additional problems even for this case? Anyway, the discussion around the packet protection is already ongoing with good contributions on the benefits/disadvantages of the different approaches. As far as the key exchange discussion goes, I would like bring up one point, though. In the global Internet, we can't use PKIs and other schemes. However, do we have requirements for smaller parts of the network being able to do this? For instance, assuming organizations like the DoD have a internal authentication infrastructure in place, can they secure their internal BUs using _their_ PKI, or are they forced to rely on BAKE only? That is, assuming BAKE is the scheme for the global world, do the protocols allow DoD to provide better protection in their network? If so, how? Jari From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 31 16:51:22 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA20680 for ; Tue, 31 Jul 2001 16:51:21 -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 NAA01714; Tue, 31 Jul 2001 13:50:18 -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 NAA23560; Tue, 31 Jul 2001 13:49:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6VKkqG08044 for mobile-ip-dist; Tue, 31 Jul 2001 13:46:52 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6VKknY08037 for ; Tue, 31 Jul 2001 13:46:49 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA03899 for ; Tue, 31 Jul 2001 13:47:02 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA05700 for ; Tue, 31 Jul 2001 13:47:02 -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 NAA28331 for ; Tue, 31 Jul 2001 13:47:02 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6VKl1p30102 for ; Tue, 31 Jul 2001 13:47:01 -0700 X-mProtect: Tue, 31 Jul 2001 13:47:01 -0700 Nokia Silicon Valley Messaging Protection Received: from tkniveto.iprg.nokia.com (205.226.2.111, claiming to be "Kniveton.com") by darkstar.iprg.nokia.com(P1.5 smtpdii7fMM; Tue, 31 Jul 2001 13:47:00 PDT Message-ID: <3B671944.E9F1F0B0@Kniveton.com> Date: Tue, 31 Jul 2001 13:47:00 -0700 From: "T.J. Kniveton" Organization: NOKIA Research 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 Subject: Re: [mobile-ip] Concerns about draft-mipv6-14 section 4.8 References: <0DF9FBC42474A24CA50F7A27FB08E0484455F8@meshpdc.meshnetworks.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 It's fine if the MANET group wants to discuss subnet mobility *as well*, but the subject of mobile routers, just as normal mobile nodes, within the scope of the Mobile IPv6 protocol, is a Mobile IP issue. What is a good reason that it is more appropriate to address it somewhere else? -TJ Phillip Neumiller wrote: > > I agree and a more appropriate place to discuss it may be the > MANET group where it has been pretty quiet lately. > > -Phil > > > -----Original Message----- > > From: Michael Thomas [mailto:mat@cisco.com] > > Sent: Tuesday, July 31, 2001 10:53 AM > > To: mobile-ip@sunroof.eng.sun.com > > Subject: Re: [mobile-ip] Concerns about draft-mipv6-14 section 4.8 > > > > > > I'll throw my support backing it out again > > too. Mobile routers are going to involve a lot of > > consideration, because they have some pretty far > > reaching implications. They should be taken up as > > a separate working group item instead of letting > > it bog down mipv6. > > > > Mike > > > > T.J. Kniveton writes: > > > I agree with Thierry here - the discussions on the list > > and at meetings > > > have shown that there is interest in making mobile > > prefixes work within > > > the context of MIPv6 handovers. The key phrase here is > > problem scope -- > > > it should be broken down to a solvable level, and > > especially limited > > > within the base draft (which I believe was the intention). > > To make it > > > really work, security issues must be solved first. Which > > leads us to the > > > question, for MIPv6 expediency's sake, why not leave it as > > a separate > > > draft? > > > > > > -TJ > > > > > > > > > > > > Thierry Ernst wrote: > > > > > > > > Dear all, > > > > > > > > One of the changes of the MIPv6 draft from version 13 to > > 14 is the > > > > addition of a section "Mobile Routers" (section 4.8) and a new > > > > sub-option "Mobile Router Prefix Length" (section 5.5). > > I have some > > > > concerns about these additions that I would like to > > share with the WG: > > > > > > > > o I think that more issues are added than solved by this new > > > > sub-option: > > > > - security (authorization) > > > > - How is it processed by the HA and the CNs > > > > - How is it used by the HA and the CNs > > > > - ... > > > > > > > > o It does only solve part of the problems already > > highlighted last year > > > > in the WG meetings and in the mailing list > > > > > > > > o There are a number of other problems that we have not > > even noticed or > > > > at least debated. > > > > > > > > o what is the exact meaning of "any home address" in > > section 5.5 ? > > > > > > > > I think that the support of mobile routers and networks > > (let's call this > > > > "Network Mobility Support") deserves more than a > > section. Particularly > > > > a terminology that defines what we are speaking about > > and that limits > > > > the scope of the problem that could be solve by the MIP > > spec. would be > > > > welcome prior to this. > > > > > > > > Indeed, I am quite surprised to see a new section that has not > > > > previously been discussed nor shared with the people on > > this mailing > > > > list, particularly not with the authors of draft > > > > > > http://www.ietf.org/internet-drafts/draft-ernst-mobileip-v6-ne > > twork-02.txt. > > > > This draft that I wrote highlighted some issues in the MIPv6 > > > > specification for "Network Mobility Support". As a > > result of past > > > > discussions, some people have agreed that MIPv6 needs > > clarifications for > > > > the HA to redirect packets to nodes behind the mobile > > router. This is > > > > not clarified in MIPv6-14, a clarification would have > > made more sense > > > > than the addition of a new feature in the WG doc itself. > > > > > > > > Moreover, my draft has introduced a "Mobile Network > > Prefix" sub-option > > > > that carries the prefix of the mobile network as part of > > the BU. This > > > > BU is sent to both the HA and CNs. Following this > > proposition, security > > > > concerns have been raised, particulalry about authorization. > > > > Authorization issues have largely accounted for the delay of the > > > > acceptance of my idea. The idea behind the sub-option > > introduced in > > > > MIPv6-14 seems to be taken from my draft, though a bit > > more limited, > > > > since it only carries the prefix length, not the prefix > > itself. The > > > > same authorization (and other security) concerns apply > > to this new > > > > sub-option, particularly when it is sent to CNs. I am > > quite amazed to > > > > see that no one has waved the security flag this time. > > Problably most > > > > people are busy, or have missed this section. > > > > > > > > Given the fact that "Network Mobility Support" is not > > yet a working > > > > group item and that the problem is not even perceived by > > the WG, the > > > > most immediate result relative to section 4.8 is that the MIPv6 > > > > specification may be further delayed. This is > > something we can not > > > > afford. MIPv6 has been delayed long enough, it's not the > > right moment to > > > > introduce new feartures in the MIPv6 document itself. > > The introduction > > > > of new features would in turn introduce potential new > > holes (particulary > > > > securiry holes) that would further delay the spec. for Proposed > > > > Standard. > > > > > > > > My conclusions are: > > > > > > > > - Section 4.8 and sub-option "Mobile Router Prefix > > Length" SHOULD be > > > > removed from the MIPv6 draft, > > > > > > > > - modifications to the MIPv6 draft specification MUST be > > discussed on > > > > the mailing list prior to their addition in a WG document, > > > > > > > > - extensions to the Mobile IPv6 specification, if not > > discussed on the > > > > mailing list, MUST be presented in a separate document, > > > > > > > > - Network Mobility Support SHOULD NOT be added in the MIPv6 > > > > specification itself - it is a distinct problem, it has > > its own solution > > > > IMHO > > > > > > > > - The problem and the requirements to solve "Network > > Mobility Support" > > > > SHOULD be discussed first. > > > > > > > > BTW, I have written a new draft "Network Mobility > > Support in IPv6: > > > > Problem Statement and Requirements" > > > > > > http://www.ietf.org/internet-drafts/draft-ernst-mobileip-monet > v6-00.txt > > > for the purpose of discussing the last item. If you have interest in > > > this discussion, a post on this mailing list PRIOR to the WG meeting > > > would be more than welcome. > > > > > > Regards, > > > Thierry. > > > > > > -- > > > * mailto:Thierry.Ernst@inrialpes.fr Tel +33 (0) 4 76 61 52 69 > > > * INRIA Rhone-Alpes Projet PLANETE (fax 52 52) > > > * and MOTOROLA Labs Paris > > > * http://www.inrialpes.fr/planete/people/ernst/Welcome.html > > > > -- > > T.J. Kniveton > > Communications Systems Lab > > Nokia Research Center -- T.J. Kniveton Communications Systems Lab Nokia Research Center From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 31 16:54:27 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA20900 for ; Tue, 31 Jul 2001 16:54:26 -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 OAA25559; Tue, 31 Jul 2001 14:53: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 NAA24269; Tue, 31 Jul 2001 13:52:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6VKoSa08104 for mobile-ip-dist; Tue, 31 Jul 2001 13:50:28 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6VKoPY08097 for ; Tue, 31 Jul 2001 13:50:25 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA17493 for ; Tue, 31 Jul 2001 13:50:38 -0700 (PDT) Received: from idcpa4.pa.interdigital.com ([12.32.197.142]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA07000 for ; Tue, 31 Jul 2001 13:50:38 -0700 (PDT) Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19) id ; Tue, 31 Jul 2001 16:49:28 -0400 Message-ID: From: "Shahrier, Sharif M." To: mobile-ip@sunroof.eng.sun.com, "'proberts@megisto.com'" , "'basavaraj.patil@nokia.com'" Subject: [mobile-ip] Proposal for L2 switching functions in Mobile IPv6 Date: Tue, 31 Jul 2001 16:49:27 -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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hello, I was wondering what the level of interest was to study L2 switching fnctions with Mobile IPv6. Recently there has been a couple of drafts using MPLS with MIPv6, although I did not see a whole lot of comments on the mailing list. I was wondering if there is enough interest in this for a work item. I would appreciate some feedback from those who are interested. Thanks. -Sharif. From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 31 17:17:15 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA22630 for ; Tue, 31 Jul 2001 17:17:15 -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 MAA17545; Tue, 31 Jul 2001 12:42:29 -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 LAA08838; Tue, 31 Jul 2001 11:42:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6VIf3U07319 for mobile-ip-dist; Tue, 31 Jul 2001 11:41:03 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6VIf0Y07312 for ; Tue, 31 Jul 2001 11:41:00 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA24285 for ; Tue, 31 Jul 2001 11:41:08 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA10409 for ; Tue, 31 Jul 2001 11:41:07 -0700 (PDT) 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 f6VIf7g08031 for ; Tue, 31 Jul 2001 11:41:07 -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 ABK12726; Tue, 31 Jul 2001 11:41:07 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA12715; Tue, 31 Jul 2001 11:41:07 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15206.64451.104039.687029@thomasm-u1.cisco.com> Date: Tue, 31 Jul 2001 11:41:07 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Re: Authentication Data as a BU suboption In-Reply-To: <3B66F9A5.3C2B4000@iprg.nokia.com> References: <200107311720.NAA12323@rotala.raleigh.ibm.com> <3B66F7B9.51090EC0@iprg.nokia.com> <3B66F9A5.3C2B4000@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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Are man in the middle attacks always acceptible? BAKE etc cannot provide MITM protection. Not having *any* strong authentication mechanism is a step backward. Mike Vijay Devarapalli writes: > and the keys are obtained through BAKE or whichever proposal > that gets accepted. > > dont bother IPSec and IKE folks. let them build their VPNs. > > vijay > > Vijay Devarapalli wrote: > > > > hi, > > > > I like authentication data as a BU suboption. this > > authentication data protects the BU option and the > > home address option alone. nothing else. draft-14 > > gives a cleaner solution for authenticating BU's IMO. > > > > advantages > > ---------- > > > > 1. we dont have to get a new next header value for the > > destination options header containing the BU > > > > 2. we dont have to modify the ipsec selectors > > > > 3. we dont have to protect the whole packet > > > > 4. we dont have bother about the traffic flows between > > the MN and the CN. > > > > 5. we can piggyback BU's. somebody asked a question if > > BU's are sent often. YES, BUs could be sent often to > > refresh the bindings. its not necessary the home agents > > agree to very large lifetimes for BUs. and BUs are sent > > to everybody in your binding update list everytime you > > move. > > > > 6. we dont have to store the security association for > > protecting the BU in the ipsec database. lookup is > > expensive. it could be stored in the binding update > > list entries. you already have access to the key. > > > > 7. authentication checksum calculation can be done > > very early (ie when the BU is being formed). in the > > current implementations you pull the packet out from > > the ip6_output function, calculate the checksum and > > put it out again in the ip6_output function. this is > > because you cant calculate the checksum until the > > whole packet has been formed. > > > > 8. mobile ip code just calls hmac_md5 function > > supplying the text and the key. thats all. > > > > so THIS is better. why dont we forget IPSec. hope > > you guys have read Thomas Narten's mail. draft-14 > > gives a cleaner alternative solution to IPsec > > > > Vijay From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 31 17:20:23 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA22843 for ; Tue, 31 Jul 2001 17:20:22 -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 OAA16580; Tue, 31 Jul 2001 14:19: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 OAA29786; Tue, 31 Jul 2001 14:17:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6VLD2208243 for mobile-ip-dist; Tue, 31 Jul 2001 14:13:02 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6VLCwY08236 for ; Tue, 31 Jul 2001 14:12:58 -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 OAA11297 for ; Tue, 31 Jul 2001 14:13:13 -0700 (PDT) From: Basavaraj.Patil@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 PAA06479 for ; Tue, 31 Jul 2001 15:14:42 -0600 (MDT) Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f6VLD1i23214 for ; Tue, 31 Jul 2001 16:13:14 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 31 Jul 2001 16:12:58 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.1600); Tue, 31 Jul 2001 16:12:57 -0500 content-class: urn:content-classes:message Subject: RE: [mobile-ip] Concerns about draft-mipv6-14 section 4.8 Date: Tue, 31 Jul 2001 16:12:57 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF4408614F@daebe007.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 Thread-Topic: [mobile-ip] Concerns about draft-mipv6-14 section 4.8 Thread-Index: AcEaAl6HINpnmoXlEdWJUgAIx6TWpQAAwV+A To: X-OriginalArrivalTime: 31 Jul 2001 21:12:57.0909 (UTC) FILETIME=[928F0650:01C11A05] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f6VLCxY08237 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 The Mobile IP WG charter does not exclude mobile routers/networks. No reason to move this aspect of Mobile IP elsewhere. -Basavaraj > > It's fine if the MANET group wants to discuss subnet mobility > *as well*, > but the subject of mobile routers, just as normal mobile nodes, within > the scope of the Mobile IPv6 protocol, is a Mobile IP issue. What is a > good reason that it is more appropriate to address it somewhere else? > > -TJ > > > Phillip Neumiller wrote: > > > > I agree and a more appropriate place to discuss it may be the > > MANET group where it has been pretty quiet lately. > > > > -Phil > > > > > -----Original Message----- > > > From: Michael Thomas [mailto:mat@cisco.com] > > > Sent: Tuesday, July 31, 2001 10:53 AM > > > To: mobile-ip@sunroof.eng.sun.com > > > Subject: Re: [mobile-ip] Concerns about draft-mipv6-14 section 4.8 > > > > > > > > > I'll throw my support backing it out again > > > too. Mobile routers are going to involve a lot of > > > consideration, because they have some pretty far > > > reaching implications. They should be taken up as > > > a separate working group item instead of letting > > > it bog down mipv6. > > > > > > Mike > > > > > > T.J. Kniveton writes: > > > > I agree with Thierry here - the discussions on the list > > > and at meetings > > > > have shown that there is interest in making mobile > > > prefixes work within > > > > the context of MIPv6 handovers. The key phrase here is > > > problem scope -- > > > > it should be broken down to a solvable level, and > > > especially limited > > > > within the base draft (which I believe was the intention). > > > To make it > > > > really work, security issues must be solved first. Which > > > leads us to the > > > > question, for MIPv6 expediency's sake, why not leave it as > > > a separate > > > > draft? > > > > > > > > -TJ > > > > > > > > > > > > > > > > Thierry Ernst wrote: > > > > > > > > > > Dear all, > > > > > > > > > > One of the changes of the MIPv6 draft from version 13 to > > > 14 is the > > > > > addition of a section "Mobile Routers" (section 4.8) > and a new > > > > > sub-option "Mobile Router Prefix Length" (section 5.5). > > > I have some > > > > > concerns about these additions that I would like to > > > share with the WG: > > > > > > > > > > o I think that more issues are added than solved by this new > > > > > sub-option: > > > > > - security (authorization) > > > > > - How is it processed by the HA and the CNs > > > > > - How is it used by the HA and the CNs > > > > > - ... > > > > > > > > > > o It does only solve part of the problems already > > > highlighted last year > > > > > in the WG meetings and in the mailing list > > > > > > > > > > o There are a number of other problems that we have not > > > even noticed or > > > > > at least debated. > > > > > > > > > > o what is the exact meaning of "any home address" in > > > section 5.5 ? > > > > > > > > > > I think that the support of mobile routers and networks > > > (let's call this > > > > > "Network Mobility Support") deserves more than a > > > section. Particularly > > > > > a terminology that defines what we are speaking about > > > and that limits > > > > > the scope of the problem that could be solve by the MIP > > > spec. would be > > > > > welcome prior to this. > > > > > > > > > > Indeed, I am quite surprised to see a new section > that has not > > > > > previously been discussed nor shared with the people on > > > this mailing > > > > > list, particularly not with the authors of draft > > > > > > > > http://www.ietf.org/internet-drafts/draft-ernst-mobileip-v6-ne > > > twork-02.txt. > > > > > This draft that I wrote highlighted some issues in the MIPv6 > > > > > specification for "Network Mobility Support". As a > > > result of past > > > > > discussions, some people have agreed that MIPv6 needs > > > clarifications for > > > > > the HA to redirect packets to nodes behind the mobile > > > router. This is > > > > > not clarified in MIPv6-14, a clarification would have > > > made more sense > > > > > than the addition of a new feature in the WG doc itself. > > > > > > > > > > Moreover, my draft has introduced a "Mobile Network > > > Prefix" sub-option > > > > > that carries the prefix of the mobile network as part of > > > the BU. This > > > > > BU is sent to both the HA and CNs. Following this > > > proposition, security > > > > > concerns have been raised, particulalry about authorization. > > > > > Authorization issues have largely accounted for the > delay of the > > > > > acceptance of my idea. The idea behind the sub-option > > > introduced in > > > > > MIPv6-14 seems to be taken from my draft, though a bit > > > more limited, > > > > > since it only carries the prefix length, not the prefix > > > itself. The > > > > > same authorization (and other security) concerns apply > > > to this new > > > > > sub-option, particularly when it is sent to CNs. I am > > > quite amazed to > > > > > see that no one has waved the security flag this time. > > > Problably most > > > > > people are busy, or have missed this section. > > > > > > > > > > Given the fact that "Network Mobility Support" is not > > > yet a working > > > > > group item and that the problem is not even perceived by > > > the WG, the > > > > > most immediate result relative to section 4.8 is > that the MIPv6 > > > > > specification may be further delayed. This is > > > something we can not > > > > > afford. MIPv6 has been delayed long enough, it's not the > > > right moment to > > > > > introduce new feartures in the MIPv6 document itself. > > > The introduction > > > > > of new features would in turn introduce potential new > > > holes (particulary > > > > > securiry holes) that would further delay the spec. > for Proposed > > > > > Standard. > > > > > > > > > > My conclusions are: > > > > > > > > > > - Section 4.8 and sub-option "Mobile Router Prefix > > > Length" SHOULD be > > > > > removed from the MIPv6 draft, > > > > > > > > > > - modifications to the MIPv6 draft specification MUST be > > > discussed on > > > > > the mailing list prior to their addition in a WG document, > > > > > > > > > > - extensions to the Mobile IPv6 specification, if not > > > discussed on the > > > > > mailing list, MUST be presented in a separate document, > > > > > > > > > > - Network Mobility Support SHOULD NOT be added in the MIPv6 > > > > > specification itself - it is a distinct problem, it has > > > its own solution > > > > > IMHO > > > > > > > > > > - The problem and the requirements to solve "Network > > > Mobility Support" > > > > > SHOULD be discussed first. > > > > > > > > > > BTW, I have written a new draft "Network Mobility > > > Support in IPv6: > > > > > Problem Statement and Requirements" > > > > > > > > http://www.ietf.org/internet-drafts/draft-ernst-mobileip-monet > > v6-00.txt > > > > for the purpose of discussing the last item. If you > have interest in > > > > this discussion, a post on this mailing list PRIOR to > the WG meeting > > > > would be more than welcome. > > > > > > > > Regards, > > > > Thierry. > > > > > > > > -- > > > > * mailto:Thierry.Ernst@inrialpes.fr Tel +33 (0) 4 76 61 52 69 > > > > * INRIA Rhone-Alpes Projet PLANETE (fax 52 52) > > > > * and MOTOROLA Labs Paris > > > > * http://www.inrialpes.fr/planete/people/ernst/Welcome.html > > > > > > -- > > > T.J. Kniveton > > > Communications Systems Lab > > > Nokia Research Center > > -- > T.J. Kniveton > Communications Systems Lab > Nokia Research Center > From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 31 17:21:26 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA22927 for ; Tue, 31 Jul 2001 17:21:25 -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 PAA18055; Tue, 31 Jul 2001 15:20: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 OAA00219; Tue, 31 Jul 2001 14:19:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6VLGTT08265 for mobile-ip-dist; Tue, 31 Jul 2001 14:16:29 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6VLGQY08258 for ; Tue, 31 Jul 2001 14:16:26 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA29634 for ; Tue, 31 Jul 2001 14:16:40 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA16171 for ; Tue, 31 Jul 2001 14:16:39 -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 OAA01182 for ; Tue, 31 Jul 2001 14:16:38 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6VLGc329674 for ; Tue, 31 Jul 2001 14:16:38 -0700 X-mProtect: Tue, 31 Jul 2001 14:16:38 -0700 Nokia Silicon Valley Messaging Protection Received: from vijayd.iprg.nokia.com (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdiCYLwT; Tue, 31 Jul 2001 14:16:36 PDT Message-ID: <3B672035.706ABCDE@iprg.nokia.com> Date: Tue, 31 Jul 2001 14:16: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: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] on using IPsec to secure Binding Updates References: <200107311720.NAA12323@rotala.raleigh.ibm.com> <00cc01c11a00$3bee9c20$8a1b6e0a@arenanet.fi> 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 Jari Arkko wrote: > > As far as the key exchange discussion goes, I would like bring > up one point, though. In the global Internet, we can't use PKIs > and other schemes. However, do we have requirements for > smaller parts of the network being able to do this? For instance, > assuming organizations like the DoD have a internal authentication > infrastructure in place, can they secure their internal BUs using _their_ > PKI, or are they forced to rely on BAKE only? That is, assuming BAKE > is the scheme for the global world, do the protocols allow DoD to provide > better protection in their network? If so, how? have both. rely on DoD's PKI when communicating with CN inside the DoD's network. use BAKE (or other competing proposal) only if you want to send a BU to a random CN. vijay > > Jari From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 31 17:27:20 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23372 for ; Tue, 31 Jul 2001 17:27:20 -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 PAA23073; Tue, 31 Jul 2001 15:26: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 OAA01703; Tue, 31 Jul 2001 14:25:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6VLMdx08344 for mobile-ip-dist; Tue, 31 Jul 2001 14:22:39 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6VLMZY08333 for ; Tue, 31 Jul 2001 14:22:35 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA11513 for ; Tue, 31 Jul 2001 14:22:49 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA21558 for ; Tue, 31 Jul 2001 14:22:49 -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 OAA01872 for ; Tue, 31 Jul 2001 14:22:49 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6VLMmH11439 for ; Tue, 31 Jul 2001 14:22:48 -0700 X-mProtect: Tue, 31 Jul 2001 14:22:48 -0700 Nokia Silicon Valley Messaging Protection Received: from vijayd.iprg.nokia.com (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdNDUCTs; Tue, 31 Jul 2001 14:22:47 PDT Message-ID: <3B6721A7.3D189E9C@iprg.nokia.com> Date: Tue, 31 Jul 2001 14:22: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: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Concern over draft-team-mobileip-mipv6-sec-reqts-00.txt References: <034BEFD03799D411A59F00508BDF754603008B94@esealnt448.al.sw.ericsson.se> <3B66F14C.A00A0B96@iprg.nokia.com> <00c401c119fb$e3e1db40$8a1b6e0a@arenanet.fi> 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 Jari, B cannot work at all. all packets from tbe MN to the CN contain a home address option in a destination options header. that means the security association is applied to every packet between the MN and CN. so 'B' also needs option specific selectors. vijay Jari Arkko wrote: > So, in my mind our options are the following (again talking only > about the BU protection, not the key exchange): > > a) The mip-specific scheme in the -14 draft > b) Standard IPsec usage without piggybacking > c) Fixed IPsec which enables piggybacked and/or > option-specific selectors > > Personally, my main preferences are either (a) or (b) > solutions. There are differences between these two > approaches, but the main significant question seems > to be if the piggybacking is needed or not. Has someone > looked at the concrete benefits of piggybacking in terms > of numbers somewhere, preferrably taking in account > various header compression schemes that get to be > applied on the most sensitive links? Please note that > separate packets can still be sent in parallel, no additional > RTTs should be introduced. Also, there might be other > factors such as firewall rule sets that affect this discussion. > > Jari From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 31 17:38:13 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA24136 for ; Tue, 31 Jul 2001 17:38:12 -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 PAA02349; Tue, 31 Jul 2001 15:37:29 -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 OAA15199; Tue, 31 Jul 2001 14:37:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6VLZrB08444 for mobile-ip-dist; Tue, 31 Jul 2001 14:35:53 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6VLZoY08437 for ; Tue, 31 Jul 2001 14:35:50 -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 OAA29318 for ; Tue, 31 Jul 2001 14:36:04 -0700 (PDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA19306 for ; Tue, 31 Jul 2001 15:37:36 -0600 (MDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f6VLaB325557 for ; Tue, 31 Jul 2001 14:36:11 -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 ABK17859; Tue, 31 Jul 2001 14:36:00 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA12723; Tue, 31 Jul 2001 14:36:00 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15207.9407.929798.879657@thomasm-u1.cisco.com> Date: Tue, 31 Jul 2001 14:35:59 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Concern over draft-team-mobileip-mipv6-sec-reqts-00.txt In-Reply-To: <3B6721A7.3D189E9C@iprg.nokia.com> References: <034BEFD03799D411A59F00508BDF754603008B94@esealnt448.al.sw.ericsson.se> <3B66F14C.A00A0B96@iprg.nokia.com> <00c401c119fb$e3e1db40$8a1b6e0a@arenanet.fi> <3B6721A7.3D189E9C@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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Vijay Devarapalli writes: > Jari, > > B cannot work at all. all packets from tbe MN to the CN > contain a home address option in a destination options > header. that means the security association is applied > to every packet between the MN and CN. so 'B' also needs > option specific selectors. Nonsense. All that means is that all traffic with a home address option would have crypto applied to it. This sounds like a feature to me. Since we're going to have a weak version of binding updates, you can always use that method if you think that crypto overhead is objectionable. Mike > > vijay > > > Jari Arkko wrote: > > > So, in my mind our options are the following (again talking only > > about the BU protection, not the key exchange): > > > > a) The mip-specific scheme in the -14 draft > > b) Standard IPsec usage without piggybacking > > c) Fixed IPsec which enables piggybacked and/or > > option-specific selectors > > > > Personally, my main preferences are either (a) or (b) > > solutions. There are differences between these two > > approaches, but the main significant question seems > > to be if the piggybacking is needed or not. Has someone > > looked at the concrete benefits of piggybacking in terms > > of numbers somewhere, preferrably taking in account > > various header compression schemes that get to be > > applied on the most sensitive links? Please note that > > separate packets can still be sent in parallel, no additional > > RTTs should be introduced. Also, there might be other > > factors such as firewall rule sets that affect this discussion. > > > > Jari From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 31 18:18:16 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27380 for ; Tue, 31 Jul 2001 18:18:15 -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 PAA11772; Tue, 31 Jul 2001 15:17: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 PAA07935; Tue, 31 Jul 2001 15:17:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6VMFrf08584 for mobile-ip-dist; Tue, 31 Jul 2001 15:15:53 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6VMFnY08577 for ; Tue, 31 Jul 2001 15:15:49 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA07482 for ; Tue, 31 Jul 2001 15:15:43 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA13848 for ; Tue, 31 Jul 2001 15:15:42 -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 PAA06714 for ; Tue, 31 Jul 2001 15:15:41 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6VMFfA32291 for ; Tue, 31 Jul 2001 15:15:41 -0700 X-mProtect: Tue, 31 Jul 2001 15:15:41 -0700 Nokia Silicon Valley Messaging Protection Received: from vijayd.iprg.nokia.com (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdxRF4Fg; Tue, 31 Jul 2001 15:15:39 PDT Message-ID: <3B672E0C.E49E6004@iprg.nokia.com> Date: Tue, 31 Jul 2001 15:15: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: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Concern over draft-team-mobileip-mipv6-sec-reqts-00.txt References: <034BEFD03799D411A59F00508BDF754603008B94@esealnt448.al.sw.ericsson.se> <3B66F14C.A00A0B96@iprg.nokia.com> <00c401c119fb$e3e1db40$8a1b6e0a@arenanet.fi> <3B6721A7.3D189E9C@iprg.nokia.com> <15207.9407.929798.879657@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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Mike, we are trying to see how a security association can be applied only to the BU and not every packet. vijay Michael Thomas wrote: > > Vijay Devarapalli writes: > > Jari, > > > > B cannot work at all. all packets from tbe MN to the CN > > contain a home address option in a destination options > > header. that means the security association is applied > > to every packet between the MN and CN. so 'B' also needs > > option specific selectors. > > Nonsense. All that means is that all traffic with a > home address option would have crypto applied > to it. This sounds like a feature to me. Since > we're going to have a weak version of binding > updates, you can always use that method if you > think that crypto overhead is objectionable. > > Mike > > > > > vijay > > > > > > Jari Arkko wrote: > > > > > So, in my mind our options are the following (again talking only > > > about the BU protection, not the key exchange): > > > > > > a) The mip-specific scheme in the -14 draft > > > b) Standard IPsec usage without piggybacking > > > c) Fixed IPsec which enables piggybacked and/or > > > option-specific selectors > > > > > > Personally, my main preferences are either (a) or (b) > > > solutions. There are differences between these two > > > approaches, but the main significant question seems > > > to be if the piggybacking is needed or not. Has someone > > > looked at the concrete benefits of piggybacking in terms > > > of numbers somewhere, preferrably taking in account > > > various header compression schemes that get to be > > > applied on the most sensitive links? Please note that > > > separate packets can still be sent in parallel, no additional > > > RTTs should be introduced. Also, there might be other > > > factors such as firewall rule sets that affect this discussion. > > > > > > Jari From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 31 18:25:40 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27998 for ; Tue, 31 Jul 2001 18:25:39 -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 QAA06344; Tue, 31 Jul 2001 16:25:03 -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 PAA09512; Tue, 31 Jul 2001 15:24:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6VMNg808659 for mobile-ip-dist; Tue, 31 Jul 2001 15:23:42 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6VMNcY08652 for ; Tue, 31 Jul 2001 15:23: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 PAA16173 for ; Tue, 31 Jul 2001 15:23:49 -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 QAA05378 for ; Tue, 31 Jul 2001 16:23:47 -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 PAA07526 for ; Tue, 31 Jul 2001 15:23:47 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6VMNlC16984 for ; Tue, 31 Jul 2001 15:23:47 -0700 X-mProtect: Tue, 31 Jul 2001 15:23:47 -0700 Nokia Silicon Valley Messaging Protection Received: from vijayd.iprg.nokia.com (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdH4CVqe; Tue, 31 Jul 2001 15:23:46 PDT Message-ID: <3B672FF2.782A4078@iprg.nokia.com> Date: Tue, 31 Jul 2001 15:23: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: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Concern over draft-team-mobileip-mipv6-sec-reqts-00.txt References: <034BEFD03799D411A59F00508BDF754603008B94@esealnt448.al.sw.ericsson.se> <3B66F14C.A00A0B96@iprg.nokia.com> <00c401c119fb$e3e1db40$8a1b6e0a@arenanet.fi> <3B6721A7.3D189E9C@iprg.nokia.com> <15207.9407.929798.879657@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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Mike, be careful with the words you use. what do you mean by 'nonsense'? maybe you are right. but you have no right to talk like this when you respond to others' mails. there are more decent ways of disagreeing with people. i am not using my time here trying to imagine some crap and putting it out on the mailing list. vijay Michael Thomas wrote: > > Vijay Devarapalli writes: > > Jari, > > > > B cannot work at all. all packets from tbe MN to the CN > > contain a home address option in a destination options > > header. that means the security association is applied > > to every packet between the MN and CN. so 'B' also needs > > option specific selectors. > > Nonsense. All that means is that all traffic with a > home address option would have crypto applied > to it. This sounds like a feature to me. Since > we're going to have a weak version of binding > updates, you can always use that method if you > think that crypto overhead is objectionable. > > Mike > > > > > vijay > > > > > > Jari Arkko wrote: > > > > > So, in my mind our options are the following (again talking only > > > about the BU protection, not the key exchange): > > > > > > a) The mip-specific scheme in the -14 draft > > > b) Standard IPsec usage without piggybacking > > > c) Fixed IPsec which enables piggybacked and/or > > > option-specific selectors > > > > > > Personally, my main preferences are either (a) or (b) > > > solutions. There are differences between these two > > > approaches, but the main significant question seems > > > to be if the piggybacking is needed or not. Has someone > > > looked at the concrete benefits of piggybacking in terms > > > of numbers somewhere, preferrably taking in account > > > various header compression schemes that get to be > > > applied on the most sensitive links? Please note that > > > separate packets can still be sent in parallel, no additional > > > RTTs should be introduced. Also, there might be other > > > factors such as firewall rule sets that affect this discussion. > > > > > > Jari From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 31 19:41:01 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA04848 for ; Tue, 31 Jul 2001 19:41:01 -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 RAA21679; Tue, 31 Jul 2001 17:40:25 -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 QAA14106; Tue, 31 Jul 2001 16:40:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6VNcIj08913 for mobile-ip-dist; Tue, 31 Jul 2001 16:38:18 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.88.31]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6VNcEY08906 for ; Tue, 31 Jul 2001 16:38:14 -0700 (PDT) Received: from istanbul.Eng.Sun.COM (istanbul.Eng.Sun.COM [129.146.86.247]) by jurassic.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with SMTP id f6VNcKS630426; Tue, 31 Jul 2001 16:38:20 -0700 (PDT) Message-Id: <200107312338.f6VNcKS630426@jurassic.eng.sun.com> Date: Tue, 31 Jul 2001 16:38:25 -0700 (PDT) From: Alper Yegin Subject: RE: [mobile-ip] Concern over draft-team-mobileip-mipv6-sec-reqts- 00.txt To: mobile-ip@sunroof.eng.sun.com, Jari.Arkko@lmf.ericsson.se Cc: Hesham.Soliman@era.ericsson.se, charliep@iprg.nokia.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: UUjC5uYZ/IwKIspPnQCaxg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4_37 SunOS 5.8.1 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: Glenn, I'm afraid other than killing birds, piggybacking has some other issues associated as well :) First of all, it'll complicate your implementation. You should queue your Mobile IPv6 signalling messages, setup timers amd age them ... Basically your implementation should "manage" this new queue. It's different than sending packets as soon as they are ready. In addition to implementation complexity, this will also have an effect in the performance of your system. Piggybacking also effects PMTU. If upper-layer wants to send a PMTU-sized packet, and IP wants to piggyback Mobile IPv6 signalling on this packet...? alper > Well simply put, piggybacking allows two things to be accomplished with one > packet. I think this is efficient. It seems that if there is a packet on the > queue headed for where the BU needs to be sent - might as well kill 2 birds > with one stone. I also think that if you need to reserve resources of some > sort, the combination might be useful either in conjunction with other > options or protocols. I also think you could kill 3 birds with one stone. > > Glenn > > > > -----Original Message----- > Could you explain more on why piggybacking is important ? When MIPv6 > is deployed, do we know how often a binding update will be sent ? > Is it your concern that there will be too many binding update packets > on the network ? > > -thanks > mohan alper From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 31 20:09:43 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA07133 for ; Tue, 31 Jul 2001 20:09:43 -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 RAA21768; Tue, 31 Jul 2001 17:09: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 RAA19718; Tue, 31 Jul 2001 17:08:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f7107EY09062 for mobile-ip-dist; Tue, 31 Jul 2001 17:07:14 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f7107AY09055 for ; Tue, 31 Jul 2001 17:07:10 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA15055 for ; Tue, 31 Jul 2001 17:07:24 -0700 (PDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA01613 for ; Tue, 31 Jul 2001 17:07:23 -0700 (PDT) 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 f7105aJ29886 for ; Tue, 31 Jul 2001 17:05:36 -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 ABK22319; Tue, 31 Jul 2001 17:07:22 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id RAA12731; Tue, 31 Jul 2001 17:07:22 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15207.18490.200566.294532@thomasm-u1.cisco.com> Date: Tue, 31 Jul 2001 17:07:22 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] on using IPsec to secure Binding Updates In-Reply-To: <200107312018.QAA13188@rotala.raleigh.ibm.com> References: <15206.61734.965790.717631@thomasm-u1.cisco.com> <200107312018.QAA13188@rotala.raleigh.ibm.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 Thomas Narten writes: > Michael Thomas writes: > > > None of the issues you raise, IMHO, come anywhere close to the > > extremely high hurdle of building or extending existing key > > distribution protocols. > > I expect that having this group design a new key negotiation protocol > in an attempt to do better/different than IKE is fraught with risks > that have been pointed out by many. We should not consider going there > without really good cause. I do not know that we are at a point where > such a direction is called for or such a decision needs to be made. I agree. This is why I don't like the idea of chucking IPsec because, warts and all, it's the devil we know. Unless we go crazy and decide that MIP doesn't need strong authentiation *ever*, the question of key distribution looms very, very large. > > > 1) absence of global PKI (which is needed to avoid MITM) note: this is > > > likely a "problem" with all proposals. Unless the two endpoints > > > have some sort of shared knowledge (e.g, key, CA, etc.), there is > > > no way to avoid MITM. > > > > > > Thus, IPsec (if used between MN and CN) would not in practice avoid > > > MITM. Thus, it may provide less protection that folks assume, and > > > may be a bit more expensive than other approaches that provide the > > > same protection. > > > What I think we all need to keep in mind is that there are really > > *two* separate problem spaces with securing BU's. The one is > > where authentication localization is practical and the other > > where it is not. > > I would like to better understand environments where this is makes > sense. What are some target deployment scenarios where using > pre-shared keys, a local PKI, etc., would make sense? A good example is a service provider who's provides a telephony service, say, which has interoperablity specifications, etc. It's almost certainly the case that the security association between the MN and HA can and should be protected using strong authentication using public key/IKE, kerberos or AAA mechanism for keying. In this limited realm, it may also be perfectly reasonable to assume that the calls between hosts which use the same service may use IPsec to transport the telephony signaling (SIP, say) end to end to counter threats against SIP (disclosure, forgery...) In this case, it would be perfectly natural to allow BU's to be protected using the same SA. > Also, how would the MN & CN *negotiate* which SA to use? Would it have > to assume one and then not work in any other environment? What happens > when a MN moves outside of the environment where the private PKI is > being used? Can a MN operate in two different realms at differnt > times? How scalable is all this? There are already mechansims within 2401 to determine what security policy to apply to an outgoing SA. Ultimately this needs to be populated by the host, perhaps as part of general provisioning. In the Packetcable environment, there is just a blanket policy that endpoints use transport mode IPsec for signaling traffic. In other environments, it may be useful to relax that sort of requirement when you aren't behaving as an end node for service X. Security is inherently hard on provisioning and policy. I don't think it's really fair to use it as an argument for or against as it comes with the territory of trying to answer the questions "who are you" and "should I let you do this." > I.e., it is not immediately clear to me how useful/desirable it is to > to target the first environment (while ignoring the other) and how one > would handle the case where one moves from one location to another > where different kinds of authentication are appropriate. I see absolutely no reason why you'd *ever* want the HA/MN security association to be secured using anything other than strong authentication. It has all of the desirable realm localization properties. If the IESG backs away from strong authentication where it is not only possible, but appropriate, it will be sending a really bad message that strong authentication is not a requirement. I think that would be a very bad message. Manifestly: this working group is now asking the question of if we don't have to do for some, why should we be doing it for any. Very, very, bad precedent. > > The state is inherent in symmetric key crypto, > > not IPsec per se. > > Right. But the cost of the IPsec state and messages is specific to > IPsec/IKE. I think *that* is what is at issue, not that there is > state. Clearly there has to be some state. Why do you think that IKE/IPsec state is more costly than other state? I just looked at the state header in freeswan's pluto and it's a couple hundred bytes and not optimized for memory. The KLIPS SADB probably has a similar amount. I doubt that two optimized implementations are likely to be significantly different. As far as messages go -- a keying protocol is a keying protocol is a keying protocol. MIP is just another potential DOI and you aren't going to change the fundamental message exchanges just because it's MIP. A protocol with better message exchange count would equally benefit IPsec as well as whatever application layer security you dreamt up. > I'm not suggesting anything about whether just the BU or all the > destination options should be covered. The issue is that the *current* > specs do not support sufficient granularity for dealing with BUs > within MIP. The question is how do we fix that. Move to something > else? Write a MIPv6-specific IPsec document that specifies how this is > being done (and if so, is this really the direction IPsec should go in)? draft-thomas-mip-esp-bu-00.txt describes a mechanism. The previous description of AH in the -13 draft was close as well, though it needed to not piggyback in some situations as well as drop the idea of only authenticating BU's and not all destination options. Mike From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 31 22:19:33 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA16231 for ; Tue, 31 Jul 2001 22:19: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 TAA02312; Tue, 31 Jul 2001 19:18:56 -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 TAA27418; Tue, 31 Jul 2001 19:18:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f712Gl809326 for mobile-ip-dist; Tue, 31 Jul 2001 19:16:47 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.89.31] (may be forged)) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f712GiY09319 for ; Tue, 31 Jul 2001 19:16:44 -0700 (PDT) Received: from istanbul.Eng.Sun.COM (istanbul.Eng.Sun.COM [129.146.86.247]) by jurassic.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with SMTP id f712GoS663467 for ; Tue, 31 Jul 2001 19:16:51 -0700 (PDT) Message-Id: <200108010216.f712GoS663467@jurassic.eng.sun.com> Date: Tue, 31 Jul 2001 19:16:59 -0700 (PDT) From: Alper Yegin Subject: [mobile-ip] BETH comments and questions To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: NXxnidXN7pXVwjjY70byqw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4_37 SunOS 5.8.1 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: Hi James, et. al, Finally I found some time to analyze the BETH draft in detail.. Some comments and questions.. As I understand, the approach BETH is taking is to eliminate the L3 signalling over the air, therefore eliminate the associated latency. While this goal is accomplished, I think this also creates some potential problems for the mobile node. Taking mobile node out of the loop makes me uncomfortable, because: Mobile node is a passive player in this protocol. Since this protocol takes away the signalling between the MN and the AR, MN cannot know when BETH takes place. Imagine a mobile node that detects it's receiving new router advertisements with a different prefix, and no longer hearing advertisements from oldAR. It also has detected a L2 break-and-make recently. Mobile node will "discover" this "movement", will attempt to unconfigure its oldCoA and configure a newCoA, and send BUs around. This, of course, won't play well if there is a BETH going on in parallel. Maybe ARs should advertise their BETH capability in advance. But, can mobile node always count on BETH taking place, and supress other protocols (MIPv6, FMIPv6) execution? Another case... Mobile node has two interfaces. It might just prefer to use basic MIPv6 (forwarding from previous CoA) for handoff. oldAR and newAR might decide the handover the mobile, while mobile might want to handover to thirdAR using it's other interface. How does this play with ARs doing BETH between them? Maybe oldAR and newAR should abort the operation as soon as they see mobile node sending a BU? Mobile node *might* even choose to send this BU directly to HA or CNs, if it doesn't care for forwarding from previous care-of address. These two are potential problems due to mobile node not being in control, or at least not informed. And I think "control" is more needed for multi-interfaced mobiles. Regarding to FMIPv6 analysis (Appendix A.4)... Any traffic that takes place in old-link can be categorized under "anticipation". They don't necessarily introduce delay in the service, but they require so much anticipation. They have to take place before L2 breaks. And arrival of F-NA at the newAR can be substituted with L2 triggers, which BETH already relies on. So, the L3 Handover Latency table in Appendix A.4 should be re-done IMO. Draft says BET is torn down when "The MN begins the process of obtaining an nCoA through nAR.". How does the newAR know that? Is is through newAR detecting that MN is doing a DAD on a CoA? Draft says "The MN is in the best position to know when it can afford to pay the latency cost of CoA establishment." I don't think obtaining a newCoA has a latency cost. It can happen in parallel with on-going traffic using oldCoA. Cheers, alper From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 31 23:30:08 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA21979 for ; Tue, 31 Jul 2001 23:30:07 -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 MAA19806; Tue, 31 Jul 2001 12:17:25 -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 MAA15658; Tue, 31 Jul 2001 12:16:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6VJDwG07552 for mobile-ip-dist; Tue, 31 Jul 2001 12:13:58 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6VJDtY07545 for ; Tue, 31 Jul 2001 12:13:55 -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 MAA26628 for ; Tue, 31 Jul 2001 12:14:08 -0700 (PDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id NAA28704 for ; Tue, 31 Jul 2001 13:15:39 -0600 (MDT) Received: (qmail 13507 invoked by uid 500); 31 Jul 2001 19:03:12 -0000 Date: Tue, 31 Jul 2001 12:03:12 -0700 From: Pat Calhoun To: "Madhavi W. Chandra" Cc: "Charles E. Perkins" , Mobile IP Working Group , Pat Calhoun , Alpesh Patel , "Kent K. Leung" Subject: [mobile-ip] Re: mobile-ip] Re: mobile-ip] WG last call: draft-ietf-mobileip-gen-key-00.txt Message-ID: <20010731120312.D6031@charizard.diameter.org> References: <20010718115752.A689@cisco.com> <3B61D37F.A75CF9B4@iprg.nokia.com> <20010731143810.B5836@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010731143810.B5836@cisco.com>; from mchandra@cisco.com on Tue, Jul 31, 2001 at 02:38:10PM -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: Ah, I think that I just understood what you want. You want the ability to include a key in a request, and not necessary request one. Isn't there anyway that this could simply be defined in another Internet Draft? I'd hate to start adding new features in the draft this late in the game (plus, there are some parties that really need an RFC number to start deploying their services). Perhaps once we've identified a need for the feature you mention (in an Internet-Draft form), you can simply define the new AVPs there. PatC On Tue, Jul 31, 2001 at 02:38:10PM -0400, Madhavi W. Chandra wrote: > Hi Charlie and Pat, > > On Fri, Jul 27, 2001 at 01:47:59PM -0700, Charles E. Perkins wrote: > > > > > > Hello folks, > > > > I submitted a version of the genkey draft, but I turned off my laptop > > before the mail had gone out and so I missed last week's deadline. > > It turns out that I had forgotten to cite RFC 2119 anyway, and so > > it might have been rejected by the IESG. I have re-revised the draft, > > and I will resubmit it at the next opportunity. > > > > The new draft is available at: > > http://people.nokia.net/charliep/txt/genkey/genkey.txt > > > > Here are some additional comments. > > > > > > "Madhavi W. Chandra" wrote: > > > > > > Hi Charlie and Pat, > > > > > > We've just started following this draft and are trying to grasp its > > > intent. We have a few questions/comments: > > > > > > 1. Since it is not specified, can the 'Reply' Key extensions be > > > appended to both RPYs and RRQs? > > > > As Pat noted, there should be restrictions. I have added text > > to that effect near the end of the Introduction. > > I'm not clear on the need for the restrictions. Being able to > append a 'Request' Key or 'Reply' Key extension to either a > RRQ or RPY provides more flexibility. Say, for example, that > hierarchical FAs want to share a key...they can append the FA-FA > Key Reply Extension to a RRQ as it propagates. Of course, the > extensions must be properly secured. > > > > 2. Section 7, 'FA-FA Key Reply Subtype Data' sounds like a > > > description for MN-HA Reply. > > > > Fixed. > > > > > > > > > 4. Can the 'Reply' Key extensions in Sections 3 and 5 be sent > > > unsolicited to the MN...meaning, not in response to a 'Request' Key > > > extension. > > > > if it is requested, then it is returned. However, it *could* be unsolicited. > > It will be helpful to explicity state this in the draft. We want to be > able to push keys to different entities, and hence would like support > for unsolicted key exchange. > > > > 6. When MN sends 'MN-HA Key Request' extension in RRQ, does it append > > > MN-AAA AE since no MHAE? So, AAA is doing proxy authentication of MN > > > for the HA? Then, HA sends RPY with 'MN-HA Key Reply' > > > extension...what AE is used to secure the RPY? > > > > They are independent. If the MN includes the MN-HA Key Request with the > > AAA subtype (see AAA keys draft), then it really should include the > > MN-AAA extension. However, these are separate drafts, and it makes sense > > to leave it that way. > > > You are correct, though, that the HA would include the MN-HA Key Reply > > extenion in the reply message, with the MN-HA auth ext generated using the > > newly distributed key. > > But, how does the MN know this newly generated key to authenticate the > MHAE in the RPY? Doesn't the MN first have to parse the RPY to extract the > 'MN-HA Key Reply extension' for the key, and then authenticate the RPY. > Is this in line with RFC2002? Or am I completely misunderstanding > something. > > > > 7. We would like a mobility agent, say MA-1, to pass key to MA-2 for > > > MA-2 to use with MN. If MAs are FAs, then probably the FA-FA Key > > > Reply Extension would be used...appended to what MIP message? What if > > > the MAs are HAs? > > > > I agree with Pat's comments about hierarchical FAs being the > > motivation for this extension, which seems to belong here. > > For the case of home agents, no one ever made such a request, > > and I haven't seen any protocol that would use such a thing as > > part of any Mobile IPv4 registration message. Even though it's > > a bit late, it's not completely impossible to add such a feature. > > However, I reckon the burden of proof would be on you to make > > the case. > > The need for HA-HA communication will become important in the case > of HA redundancy or load-balancing. The HAs will need to share a > security association, which can be dynamically assigned via a AAA > server. It's analogous to the hierarchical FA case for future use. > We'd like to request this feature to be included. We realize the > late nature of this request, and are more than willing to help with > text, motivation, etc. > > Thanks, > Madhavi > > > > > Regards, > > Charlie P. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 1 00:00:26 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10700 for ; Tue, 31 Jul 2001 14:59:37 -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 LAA11360; Tue, 31 Jul 2001 11:58:52 -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 LAA12157; Tue, 31 Jul 2001 11:58:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6VItZN07442 for mobile-ip-dist; Tue, 31 Jul 2001 11:55:35 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6VItVY07435 for ; Tue, 31 Jul 2001 11:55:32 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA23004 for ; Tue, 31 Jul 2001 11:55:45 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA17716 for ; Tue, 31 Jul 2001 11:55:44 -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 LAA18272 for ; Tue, 31 Jul 2001 11:55:44 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6VItib19940 for ; Tue, 31 Jul 2001 11:55:44 -0700 X-mProtect: Tue, 31 Jul 2001 11:55:44 -0700 Nokia Silicon Valley Messaging Protection Received: from vijayd.iprg.nokia.com (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdTkQXHu; Tue, 31 Jul 2001 11:55:42 PDT Message-ID: <3B66FF2E.133C0C98@iprg.nokia.com> Date: Tue, 31 Jul 2001 11:55: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: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Authentication Data as a BU suboption References: <200107311720.NAA12323@rotala.raleigh.ibm.com> <3B66F7B9.51090EC0@iprg.nokia.com> <15206.64005.34473.57514@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 Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Michael Thomas wrote: > > Disadvantages: > > 1) no standard key distribution > 2) no means of encryption > 3) no means of cipher suite negotiation > 4) no standard key distribution its three and not four. you cant list a disadvantage twice. actually cut it down to 1. i dont care about encryption. keys are obtained through BAKE or some other accepted proposal. vijay > > Mike > > Vijay Devarapalli writes: > > hi, > > > > I like authentication data as a BU suboption. this > > authentication data protects the BU option and the > > home address option alone. nothing else. draft-14 > > gives a cleaner solution for authenticating BU's IMO. > > > > advantages > > ---------- > > > > 1. we dont have to get a new next header value for the > > destination options header containing the BU > > > > 2. we dont have to modify the ipsec selectors > > > > 3. we dont have to protect the whole packet > > > > 4. we dont have bother about the traffic flows between > > the MN and the CN. > > > > 5. we can piggyback BU's. somebody asked a question if > > BU's are sent often. YES, BUs could be sent often to > > refresh the bindings. its not necessary the home agents > > agree to very large lifetimes for BUs. and BUs are sent > > to everybody in your binding update list everytime you > > move. > > > > 6. we dont have to store the security association for > > protecting the BU in the ipsec database. lookup is > > expensive. it could be stored in the binding update > > list entries. you already have access to the key. > > > > 7. authentication checksum calculation can be done > > very early (ie when the BU is being formed). in the > > current implementations you pull the packet out from > > the ip6_output function, calculate the checksum and > > put it out again in the ip6_output function. this is > > because you cant calculate the checksum until the > > whole packet has been formed. > > > > 8. mobile ip code just calls hmac_md5 function > > supplying the text and the key. thats all. > > > > so THIS is better. why dont we forget IPSec. hope > > you guys have read Thomas Narten's mail. draft-14 > > gives a cleaner alternative solution to IPsec > > > > Vijay