From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 1 04:04: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 EAA21597 for ; Wed, 1 Aug 2001 04:04:27 -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 CAA11315; Wed, 1 Aug 2001 02:03: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 AAA06261; Wed, 1 Aug 2001 00:59:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f717vqB10075 for mobile-ip-dist; Wed, 1 Aug 2001 00:57:52 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f717vmD10068 for ; Wed, 1 Aug 2001 00:57: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 AAA19169 for ; Wed, 1 Aug 2001 00:58: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 AAA05613 for ; Wed, 1 Aug 2001 00:58:01 -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 AAA14462; Wed, 1 Aug 2001 00:56:16 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f717uFQ16410; Wed, 1 Aug 2001 00:56:15 -0700 X-mProtect: Wed, 1 Aug 2001 00:56:15 -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 smtpd7UGDXC; Wed, 01 Aug 2001 00:56:13 PDT Message-ID: <3B67B638.8A793C92@iprg.nokia.com> Date: Wed, 01 Aug 2001 00:56:40 -0700 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Thomas Narten CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Concern over draft-team-mobileip-mipv6-sec-reqts-00.txt References: <200107311150.f6VBo9X04471@cichlid.adsl.duke.edu> 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 Thomas, Thomas Narten wrote: > "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. The route optimization part would only be vulnerable if Binding Updates could be applied without authentication. Since this is clearly prohibited, I am sure that the route optimization part does not have the vulnerability under discussion. How can it be otherwise? Maybe some nodes wouldn't have security associations with a mobile node sending a Binding Update. Then they could not accept the Binding Update. Is there something in the current specification that does not make this point sufficiently clear? If so, please let me know what improvement to make. Or else, maybe I am not understanding your point...? I am really curious to find out! Do you mean that some nodes wouldn't be able to accept Binding Updates at all? Then why is this a security vulnerability? Do you mean that some nodes would accept a Binding Update without authenticating it? Then this is a violation of Mobile IPv6! I think this is a fundamental enough point, with specific technical documentation, that we should be able to agree on the issue, but somehow it seems that there is not yet agreement, so I hope you can help me see why you believe there is some vulnerability here, when I am so certain it is prohibited by the existing specification!! > 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. Even IPv4 route optimization doesn't have the vulnerability, because IPv4 Binding Update is _also_ required to be discarded unless it can be authenticated. > > 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. I was talking about specifically the "base" Mobile IPv6 document, without key distribution. I would agree that ancillary documents should need to do their own analysis -- and yet the threat document mostly refers to features specific to the Mobile IPv6 document itself. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 1 04: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 EAA22109 for ; Wed, 1 Aug 2001 04:18: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 BAA14486; Wed, 1 Aug 2001 01:19: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 BAA08105; Wed, 1 Aug 2001 01:14:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f718DBF10197 for mobile-ip-dist; Wed, 1 Aug 2001 01:13:11 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f718D7D10190 for ; Wed, 1 Aug 2001 01:13:07 -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 BAA20883 for ; Wed, 1 Aug 2001 01:13:21 -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 BAA09136 for ; Wed, 1 Aug 2001 01:13:20 -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 BAA15580; Wed, 1 Aug 2001 01:13:19 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f718DIM06935; Wed, 1 Aug 2001 01:13:18 -0700 X-mProtect: Wed, 1 Aug 2001 01:13:18 -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 smtpdYaTCq8; Wed, 01 Aug 2001 01:13:16 PDT Message-ID: <3B67BA36.5138B18D@iprg.nokia.com> Date: Wed, 01 Aug 2001 01:13:42 -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> <3B662EAB.EE182C21@iprg.nokia.com> <15206.52882.864047.699551@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 > > > 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, Are you claiming that section 8.2 needs repair? Or is it that section 4.4 is incomplete? If the latter, then what specifically do you think is wrong? It specifies the data that needs to be authenticated. The Binding Update (formerly AH) specifies a SPI which should determine the authentication algorithm. If there isn't one, there is no authentication. What's wrong with that? What words do you think are missing? > 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. No, what I wrote is that the existing specification does not have the vulernability, because Binding Update packets cannot be accepted without authentication. It is the authentication requirement for Binding Updates that makes route optimization secure. This requirement has been known for well over 7 years. It is not new. It was never opened within Mobile IPv6. I sure do wish someone would explain why there is some vulnerability, since as best I can tell the action that would lead to vulnerability is absolutely prohibited by the specification. Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 1 07:48: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 HAA28387 for ; Wed, 1 Aug 2001 07:48: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 EAA11908; Wed, 1 Aug 2001 04:49: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 EAA12703; Wed, 1 Aug 2001 04:48:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f71Bldq10756 for mobile-ip-dist; Wed, 1 Aug 2001 04:47:39 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f71BlZD10749 for ; Wed, 1 Aug 2001 04:47:35 -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 EAA12652 for ; Wed, 1 Aug 2001 04:47:48 -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 EAA01921 for ; Wed, 1 Aug 2001 04:47:47 -0700 (PDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f71BljN22635; Wed, 1 Aug 2001 13:47:45 +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 f71Blh510217; Wed, 1 Aug 2001 14:47:43 +0300 (EET DST) Message-ID: <3B67EC5F.F4040E27@lmf.ericsson.se> Date: Wed, 01 Aug 2001 14:47:43 +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: vijayd@iprg.nokia.com CC: 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> 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 Vijay, You wrote the text below yesterday, and I'm trying to understand what you mean exactly. You can call me slow but could you help by explaining more? > > 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 > > 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. Specifically, I'm wondering why the HA option has relevance in this discussion. They don't need security in the same way as BUs do. But perhaps the HA options somehow affect the policy matching in a negative way? However, as per section 8.1 in the -14 draft, CNs generally remove the HA option before further processing - presumably such as IPsec policy matching - takes place. Also, section 10.2 seems to indicate that any policy matching is performed on outbound packets before they have the HA applied. So, assuming BUs have their own next header value and are not piggybacked, it seems that they could match policy entries such as "protocol=BU, destination=me, source=peershomeaddress => use sa1". The rest of the traffic uses protocols such as TCP, which do not match these entries, hence no security is applied to them. Jari From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 1 07:53: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 HAA28528 for ; Wed, 1 Aug 2001 07:53:38 -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 EAA13162; Wed, 1 Aug 2001 04:53: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 EAA13070; Wed, 1 Aug 2001 04:53:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f71BqaM10813 for mobile-ip-dist; Wed, 1 Aug 2001 04:52:36 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f71BqWD10806 for ; Wed, 1 Aug 2001 04:52:32 -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 EAA23116 for ; Wed, 1 Aug 2001 04:52:45 -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 FAA03938 for ; Wed, 1 Aug 2001 05:54:17 -0600 (MDT) Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.2/8.9.3) with ESMTP id f71Boph04637; Wed, 1 Aug 2001 07:50:52 -0400 Message-Id: <200108011150.f71Boph04637@cichlid.adsl.duke.edu> 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: Message from Charlie Perkins of "Wed, 01 Aug 2001 01:13:42 PDT." <3B67BA36.5138B18D@iprg.nokia.com> Date: Wed, 01 Aug 2001 07:50:51 -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: Charlie, It seems to me that you are to some extent splitting hairs. I'll concede this particular battle, but that doesn't change that we have work to do to get the spec to RFC. In particular: Charlie Perkins writes: > No, what I wrote is that the existing specification does not have > the vulernability, because Binding Update packets cannot be accepted > without authentication. This is technically correct. If a receiver can't properly authenticate a BU, it (per the MIPv6 spec) discards it, so technically there is no vulnerability. But in this case, route optimization doesn't work either. And presumably people want route optimization to work because they think it is important. So, I agree, rather than saying "there is a security vulnerability", we should be saying something rather different, i.e., additional work needs to done to develop a more deployable approach to securing BUs in the case of communication between arbitrary MNs and CNs. Thomas From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 1 08:46: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 IAA00115 for ; Wed, 1 Aug 2001 08:46: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 GAA25320; Wed, 1 Aug 2001 06:47: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 FAA17028; Wed, 1 Aug 2001 05:46:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f71Ci9m10904 for mobile-ip-dist; Wed, 1 Aug 2001 05:44:09 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f71Ci6D10897 for ; Wed, 1 Aug 2001 05:44: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 FAA28100 for ; Wed, 1 Aug 2001 05:44:19 -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 FAA24296 for ; Wed, 1 Aug 2001 05:44:17 -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 f71CfQX04049 for ; Wed, 1 Aug 2001 14:41:27 +0200 (MEST) Message-ID: <3B67F996.BD665A40@inrialpes.fr> Date: Wed, 01 Aug 2001 14:44:06 +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 Subject: Re: [mobile-ip] Concerns about draft-mipv6-14 section 4.8 References: <0DF9FBC42474A24CA50F7A27FB08E0484455F8@meshpdc.meshnetworks.com> <3B671944.E9F1F0B0@Kniveton.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 "T.J. Kniveton" wrote: > > 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? Indeed, there would be such one good reason: mobile networks have an implication on other aspects not related to Mobile IP. For instance, on routing protocols, but the right place for the discussion is still Mobile IP because we have to determine whether Mobile IPv6 is the right base protocol for network mobility support. Mobile IPv6 may not be able to address all issues, but it surely can help. I agree that MANET WG could benefit from this discussion (how do you manage mobility of an ad-hoc network that changes its point of attachment ?), but it's not a better place than Mobile IP WG. MANET WG is more concerned by "how things are done INSIDE the network" than "how to manage subsequent point of attachments to the Internet", which is Mobile IP WG's. Anyway, seems clear to me that everyone agree that this should not be addressed in the MIPv6 draft itself, but in a separate document. Thierry. > 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? -- * 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 Aug 1 11:38: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 LAA16977 for ; Wed, 1 Aug 2001 11:38:12 -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 IAA08132; Wed, 1 Aug 2001 08:36: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 IAA08527; Wed, 1 Aug 2001 08:33:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f71FS0U11332 for mobile-ip-dist; Wed, 1 Aug 2001 08:28:00 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f71FRuD11325 for ; Wed, 1 Aug 2001 08:27:56 -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 IAA07387 for ; Wed, 1 Aug 2001 08:28:09 -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 JAA19325 for ; Wed, 1 Aug 2001 09:27:59 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id IAA12207; Wed, 1 Aug 2001 08:28:00 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f71FRxW05463; Wed, 1 Aug 2001 08:27:59 -0700 X-mProtect: Wed, 1 Aug 2001 08:27:59 -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 smtpd1N8Msl; Wed, 01 Aug 2001 08:27:57 PDT Message-ID: <3B682017.2C9A6869@iprg.nokia.com> Date: Wed, 01 Aug 2001 08:28:23 -0700 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Thomas Narten CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Concern over draft-team-mobileip-mipv6-sec-reqts-00.txt References: <200108011150.f71Boph04637@cichlid.adsl.duke.edu> 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 Thomas, Thank you very much for this note. I suddenly no longer feel that we are living in parallel but disjoint universes. I thoroughly agree that we have work to do in order to get Mobile IPv6 to Proposed Standard, and I'm not adverse to going about getting it done in whatever way is the most likely to reach the technical goals and attain consensus within the working group. However, to me it does not seem at all like splitting hairs, because of the following: - The "original" goal was to have a mechanism by which route optimization could work, for those hosts able to create the appropriate security association. - The "new" goal is to create a mechanism by which a lot of (or maybe all) IPv6 hosts can authenticate the Binding Update. This would enable route optimization for a much larger subset of all IPv6 correspondent nodes. That is a big goal. I think that we are likely to be looking at some challenging work, so it is crucial to have a precise understanding of the current problem and the new goals. I like your formulation of the problem stated in your last sentence of the last paragraph. Regards, Charlie P. Thomas Narten wrote: > Charlie, > > It seems to me that you are to some extent splitting hairs. I'll > concede this particular battle, but that doesn't change that we have > work to do to get the spec to RFC. In particular: > > Charlie Perkins writes: > > > No, what I wrote is that the existing specification does not have > > the vulernability, because Binding Update packets cannot be accepted > > without authentication. > > This is technically correct. If a receiver can't properly authenticate > a BU, it (per the MIPv6 spec) discards it, so technically there is no > vulnerability. But in this case, route optimization doesn't work > either. And presumably people want route optimization to work because > they think it is important. So, I agree, rather than saying "there is > a security vulnerability", we should be saying something rather > different, i.e., additional work needs to done to develop a more > deployable approach to securing BUs in the case of communication > between arbitrary MNs and CNs. > > Thomas From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 1 12:07: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 MAA19167 for ; Wed, 1 Aug 2001 12:07: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 KAA21729; Wed, 1 Aug 2001 10:06:09 -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 JAA05210; Wed, 1 Aug 2001 09:04:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f71G2Uv11436 for mobile-ip-dist; Wed, 1 Aug 2001 09:02:30 -0700 (PDT) Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f71G2QD11429 for ; Wed, 1 Aug 2001 09:02:27 -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 f71G2V220507; Wed, 1 Aug 2001 18:02:31 +0200 (MET DST) Date: Wed, 1 Aug 2001 18:00:15 +0200 (CEST) From: Erik Nordmark Subject: Re: [mobile-ip] Concern over draft-team-mobileip-mipv6-sec-reqts-00.txt To: Michael Thomas Cc: Jari Arkko , Hesham.Soliman@era.ericsson.se, charliep@iprg.nokia.com, mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <15206.49527.863582.976611@thomasm-u1.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > 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. I think there are some issues here. Recall the MIPv6 uses destination options for binding updates, acks, requests, as well as home address option. Even if nobody ever invents any new destination options header this means that if the IPsec policy says that packets with nexthdr = destination options this effects packets containing e.g. home address options. Thus for traffic between two mobile nodes (which always have home address options in both directions) you'd be forced to use IPsec on every packet. In fact, when a mobile node is sending packets (using its home address) it must always include a home address option thus those packets would require IPsec. Of course, if other destination options are invented in the future the precense of those would also force IPsec which might be undesirable. So things for sure would be simpler if, in addition to no piggybacking, the BU (and binding acks, requests as well?) were sent using a different nexthdr value or otherwise using different IPsec selectors (i.e. a UDP port number would avoid this issue as well.) Erik From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 1 12:17: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 MAA19693 for ; Wed, 1 Aug 2001 12:17: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 HAA05561; Wed, 1 Aug 2001 07:53: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 GAA23371; Wed, 1 Aug 2001 06:50:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f71DiXN11056 for mobile-ip-dist; Wed, 1 Aug 2001 06:44:33 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f71DiPD11049 for ; Wed, 1 Aug 2001 06:44:25 -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 GAA22605 for ; Wed, 1 Aug 2001 06:44:39 -0700 (PDT) Received: from p-mail1.cnet.fr (p-mail1.rd.francetelecom.fr [193.49.124.31]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id HAA23446 for ; Wed, 1 Aug 2001 07:46:11 -0600 (MDT) Received: by p-biset.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19) id ; Wed, 1 Aug 2001 15:44:10 +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 QADMNJY7; Wed, 1 Aug 2001 15:44:03 +0200 Message-ID: <3B680774.48FD39@francetelecom.com> Date: Wed, 01 Aug 2001 15:43:16 +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] 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> <3B67EC5F.F4040E27@lmf.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 HAA05561 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA19693 Hi Jari, Jari Arkko a écrit : > Hi Vijay, > > You wrote the text below yesterday, and I'm trying > to understand what you mean exactly. You can call > me slow but could you help by explaining more? > > > > 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 > > > > 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. > > Specifically, I'm wondering why the HA option has relevance > in this discussion. They don't need security in the same way > as BUs do. But perhaps the HA options somehow affect the > policy matching in a negative way? However, as per section > 8.1 in the -14 draft, CNs generally remove the HA option before > further processing - presumably such as IPsec policy matching > - takes place. Also, section 10.2 seems to indicate that any > policy matching is performed on outbound packets before they > have the HA applied. > > So, assuming BUs have their own next header value and are > not piggybacked, it seems that they could match policy > entries such as "protocol=BU, destination=me, > source=peershomeaddress => use sa1". The rest of the traffic > uses protocols such as TCP, which do not match these entries, > hence no security is applied to them. JMC : I'm happy to hear this !!! I think this is the cheapest and best solution. I would be afraid to have to pay a high cost to secure MIPv6 while by changing just two little things (ie. BU "nxt header" value and "no piggybacking"), we could use existing tools ... Regards JMC. > > > Jari -- 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 Aug 1 12:23: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 MAA20096 for ; Wed, 1 Aug 2001 12:23: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 JAA02274; Wed, 1 Aug 2001 09:23: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 JAA09433; Wed, 1 Aug 2001 09:22:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f71GJmO11529 for mobile-ip-dist; Wed, 1 Aug 2001 09:19:48 -0700 (PDT) Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f71GJhD11519 for ; Wed, 1 Aug 2001 09:19:43 -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 f71GJs222004; Wed, 1 Aug 2001 18:19:54 +0200 (MET DST) Date: Wed, 1 Aug 2001 18:17:38 +0200 (CEST) From: Erik Nordmark Subject: Re: [mobile-ip] Concern over draft-team-mobileip-mipv6-sec-reqts-00.txt To: Jean-Michel COMBES Cc: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3B680774.48FD39@francetelecom.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: > JMC : I'm happy to hear this !!! I think this is the cheapest and best > solution. I would be afraid to have to pay a high cost to secure MIPv6 > while by changing just two little things (ie. BU "nxt header" value and > "no piggybacking"), we could use existing tools ... Jean-Michel, That would solve part of the outstanding issues. But with just those changes you would still need a PKI that includes both the MN and the CN in order to use route optimization. It is my understanding that folks one to use route optimizations even when a PKI with such scope is not available. (If I'm mistaken about this requirement it would be good to straighten me out.) Thus there is a need for something somewhat weaker than a PKI in order to allow route optimization in those cases. There are several proposals that somehow use "return routability" as the criteria for such a weaker scheme. Erik From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 1 12:24: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 MAA20138 for ; Wed, 1 Aug 2001 12:24: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 KAA06137; Wed, 1 Aug 2001 10:22: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 JAA09461; Wed, 1 Aug 2001 09:22:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f71GKvI11550 for mobile-ip-dist; Wed, 1 Aug 2001 09:20:57 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f71GKrD11543 for ; Wed, 1 Aug 2001 09:20: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 JAA16988; Wed, 1 Aug 2001 09:20:40 -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 KAA04396; Wed, 1 Aug 2001 10:20:34 -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 f71GKnY16103; Wed, 1 Aug 2001 09:20: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 ABK32979; Wed, 1 Aug 2001 09:20:34 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA13011; Wed, 1 Aug 2001 09:20:34 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15208.11346.178994.473828@thomasm-u1.cisco.com> Date: Wed, 1 Aug 2001 09:20:34 -0700 (PDT) To: Erik Nordmark Cc: Michael Thomas , Jari Arkko , Hesham.Soliman@era.ericsson.se, charliep@iprg.nokia.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Concern over draft-team-mobileip-mipv6-sec-reqts-00.txt In-Reply-To: References: <15206.49527.863582.976611@thomasm-u1.cisco.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Erik Nordmark writes: > > > 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. > > I think there are some issues here. Recall the MIPv6 uses destination options > for binding updates, acks, requests, as well as home address option. > > Even if nobody ever invents any new destination options header this means > that if the IPsec policy says that packets with nexthdr = destination options > this effects packets containing e.g. home address options. > Thus for traffic between two mobile nodes (which always have home address > options in both directions) you'd be forced to use IPsec on every packet. > In fact, when a mobile node is sending packets (using its home > address) it must always include a home address option thus those packets > would require IPsec. > > Of course, if other destination options are invented in the future the > precense of those would also force IPsec which might be undesirable. > > So things for sure would be simpler if, in addition to no piggybacking, > the BU (and binding acks, requests as well?) were sent using a different > nexthdr value or otherwise using different IPsec selectors (i.e. a UDP port > number would avoid this issue as well.) Yes, the more I think about this the more I'm inclined to agree. Another negative effect would be that you'd be unable to use SRTP instead of IPsec which in turn would pooch ROHC for the media (or at least give 12-16 bytes more of uncompressible data per packet). A longer term solution would be to extend the generalized port semantics to DO's just as it's getting extended to support SCTP right now. I think I'd probably favor that more for the following reasons: 1) Creating a new header type always seems like a rather large club to beat on a problem 2) IPsec will work right now if you're willing to live with the restrictions (ie, all home address options would need crypto applied to it too) 3) The situation where this would be problematic is just the MN/CN traffic since the traffic is tunneled between the HA/MN. I imagine that *most* of the MN/CN BU's will actually be the weak variety instead. 4) Where strong authentication is used between MN/CN is likely to be an all or nothing proposition anyway (ie, all PDA's in my enterprise using 802.11 MUST set up IPsec transport SA's to protect *everything*). Thus #2 may be a not-terrible restriction. Thus, waiting for an abstracted port mechanism for DO's may be viewed as more of a completeness issue, rather than a must have issue. Mike From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 1 12:33: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 MAA20660 for ; Wed, 1 Aug 2001 12:33:20 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA15203; Wed, 1 Aug 2001 10:32:04 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA19299; Wed, 1 Aug 2001 09:31:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f71GUVU11661 for mobile-ip-dist; Wed, 1 Aug 2001 09:30:31 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f71GUSD11654 for ; Wed, 1 Aug 2001 09:30:28 -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 JAA11233 for ; Wed, 1 Aug 2001 09:30:42 -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 KAA14074 for ; Wed, 1 Aug 2001 10:30:39 -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 f71GUjg03907; Wed, 1 Aug 2001 09:30:45 -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 ABK33226; Wed, 1 Aug 2001 09:30:40 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA13019; Wed, 1 Aug 2001 09:30:40 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15208.11951.979665.294736@thomasm-u1.cisco.com> Date: Wed, 1 Aug 2001 09:30:39 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Cc: Jean-Michel COMBES Subject: Re: [mobile-ip] Concern over draft-team-mobileip-mipv6-sec-reqts-00.txt In-Reply-To: References: <3B680774.48FD39@francetelecom.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Erik Nordmark writes: > > JMC : I'm happy to hear this !!! I think this is the cheapest and best > > solution. I would be afraid to have to pay a high cost to secure MIPv6 > > while by changing just two little things (ie. BU "nxt header" value and > > "no piggybacking"), we could use existing tools ... > > Jean-Michel, > > That would solve part of the outstanding issues. > But with just those changes you would still need a PKI that includes > both the MN and the CN in order to use route optimization. > It is my understanding that folks one to use route optimizations even when > a PKI with such scope is not available. > (If I'm mistaken about this requirement it would be good to straighten me out.) > Thus there is a need for something somewhat weaker than a PKI in order > to allow route optimization in those cases. There are several proposals > that somehow use "return routability" as the criteria for such a weaker > scheme. No, you are exactly right. There are two things that need to done: 1) Provide a strong authentication solution where it is pragmatically possible 2) Provide a weak authentication solution where it is pragmatically impossible. We have been talking almost exclusively about (1) recently, though that doesn't mean that (2) is uninteresting. It's day will come too, I expect. Mike From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 1 12:45: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 MAA21298 for ; Wed, 1 Aug 2001 12:45:18 -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 KAA27908; Wed, 1 Aug 2001 10:45:47 -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 JAA22119; Wed, 1 Aug 2001 09:45:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f71GiGM12220 for mobile-ip-dist; Wed, 1 Aug 2001 09:44:16 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f71Gi8D12209 for ; Wed, 1 Aug 2001 09:44:08 -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 JAA22563 for ; Wed, 1 Aug 2001 09:44:21 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA26601 for ; Wed, 1 Aug 2001 10:44:19 -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 JAA18785; Wed, 1 Aug 2001 09:44:20 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f71GiK113844; Wed, 1 Aug 2001 09:44:20 -0700 X-mProtect: Wed, 1 Aug 2001 09:44:20 -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 smtpd67TRGz; Wed, 01 Aug 2001 09:44:18 PDT Message-ID: <3B6831E2.76F7FDFD@iprg.nokia.com> Date: Wed, 01 Aug 2001 09:44:18 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Jari Arkko CC: 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> <3B67EC5F.F4040E27@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 Jari, for option 'B' i thought you assumed that only piggybacking was not used. i didnt realise that you also assumed that there is a new next header value for the BU. then option 'B' would work. vijay Jari Arkko wrote: > > Hi Vijay, > > You wrote the text below yesterday, and I'm trying > to understand what you mean exactly. You can call > me slow but could you help by explaining more? > > > > 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 > > > > 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. > > Specifically, I'm wondering why the HA option has relevance > in this discussion. They don't need security in the same way > as BUs do. But perhaps the HA options somehow affect the > policy matching in a negative way? However, as per section > 8.1 in the -14 draft, CNs generally remove the HA option before > further processing - presumably such as IPsec policy matching > - takes place. Also, section 10.2 seems to indicate that any > policy matching is performed on outbound packets before they > have the HA applied. > > So, assuming BUs have their own next header value and are > not piggybacked, it seems that they could match policy > entries such as "protocol=BU, destination=me, > source=peershomeaddress => use sa1". The rest of the traffic > uses protocols such as TCP, which do not match these entries, > hence no security is applied to them. > > Jari From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 1 12:57: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 MAA21950 for ; Wed, 1 Aug 2001 12:57:30 -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 KAA08780; Wed, 1 Aug 2001 10:57: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 JAA25143; Wed, 1 Aug 2001 09:56:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f71GtJ912284 for mobile-ip-dist; Wed, 1 Aug 2001 09:55:19 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f71GtFD12275 for ; Wed, 1 Aug 2001 09:55:15 -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 JAA24676 for ; Wed, 1 Aug 2001 09:55:28 -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 KAA06554 for ; Wed, 1 Aug 2001 10:55:25 -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 f71GtON11126 for ; Wed, 1 Aug 2001 18:55:25 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Wed Aug 01 18:55:19 2001 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 1 Aug 2001 18:49:07 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008B98@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Gopal Dommety '" , "'mobile-ip@sunroof.eng.sun.com '" , "'mobile-ip@sunroof.eng.sun.com '" Subject: RE: [mobile-ip] Re:Comments on draft-ietf-mobileip-fast-mipv6-02. txt Date: Wed, 1 Aug 2001 18:55:18 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) List-Subscribe: List-Unsubscribe: Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Gopal, DAD handling was already covered by the introduction of HI/HAck. The text below wouldn't hurt though. Hesham -----Original Message----- From: Gopal Dommety To: mobile-ip@sunroof.eng.sun.com; mobile-ip@sunroof.eng.sun.com Sent: 7/31/2001 5:36 PM Subject: Re: [mobile-ip] Re:Comments on draft-ietf-mobileip-fast-mipv6-02.txt 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 Wed Aug 1 13:04: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 NAA22289 for ; Wed, 1 Aug 2001 13:04: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 LAA14479; Wed, 1 Aug 2001 11:03: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 KAA26722; Wed, 1 Aug 2001 10:02:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f71H1cm12389 for mobile-ip-dist; Wed, 1 Aug 2001 10:01:38 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f71H1VD12382 for ; Wed, 1 Aug 2001 10:01:31 -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 KAA18538 for ; Wed, 1 Aug 2001 10:01:42 -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 KAA12170 for ; Wed, 1 Aug 2001 10:01:41 -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 f71H1SO25067 for ; Wed, 1 Aug 2001 19:01:28 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Wed Aug 01 19:01:28 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Wed, 1 Aug 2001 19:01:28 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008B99@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Vijay Devarapalli '" , "'mobile-ip@sunroof.eng.sun.com '" Subject: RE: [mobile-ip] Concern over draft-team-mobileip-mipv6-sec-reqts- 00.txt Date: Wed, 1 Aug 2001 19:01:22 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) List-Subscribe: List-Unsubscribe: Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk 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 ? 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. => I don't know what else to call it. If a -cn wants to receive a BU it has to do this. I don't see a problem with that. Nothing on the wire is changed. Hesham > > 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 Wed Aug 1 13:06: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 NAA22436 for ; Wed, 1 Aug 2001 13:06: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 LAA18446; Wed, 1 Aug 2001 11:06: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 KAA27762; Wed, 1 Aug 2001 10:06:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f71H5L012472 for mobile-ip-dist; Wed, 1 Aug 2001 10:05:21 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f71H5HD12458 for ; Wed, 1 Aug 2001 10:05: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 KAA02585 for ; Wed, 1 Aug 2001 10:05:26 -0700 (PDT) Received: from tml-gw.tml.hut.fi (tml.hut.fi [130.233.44.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA24376 for ; Wed, 1 Aug 2001 11:06:51 -0600 (MDT) Received: (from smap@localhost) by tml-gw.tml.hut.fi (8.8.7/8.8.7) id UAA04851 for ; Wed, 1 Aug 2001 20:02:40 +0300 Received: from mail.tml.hut.fi(130.233.45.70) by tml-gw.tml.hut.fi via smap (V2.0) id xma004845; Wed, 1 Aug 01 20:02:12 +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 f71H3jN08354 for ; Wed, 1 Aug 2001 20:03:45 +0300 (EEST) Received: from localhost (lpetande@localhost) by morphine.tml.hut.fi (8.11.3/8.11.3) with ESMTP id f71H4f823424 for ; Wed, 1 Aug 2001 20:04:41 +0300 (EET DST) X-Authentication-Warning: morphine.tml.hut.fi: lpetande owned process doing -bs Date: Wed, 1 Aug 2001 20:04:41 +0300 (EET DST) From: Lars Henrik Petander 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-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: On Wed, 1 Aug 2001, Erik Nordmark wrote: > > JMC : I'm happy to hear this !!! I think this is the cheapest and best > > solution. I would be afraid to have to pay a high cost to secure MIPv6 > > while by changing just two little things (ie. BU "nxt header" value and > > "no piggybacking"), we could use existing tools ... > > Jean-Michel, > > That would solve part of the outstanding issues. > But with just those changes you would still need a PKI that includes > both the MN and the CN in order to use route optimization. > It is my understanding that folks one to use route optimizations even when > a PKI with such scope is not available. > (If I'm mistaken about this requirement it would be good to straighten me out.) > Thus there is a need for something somewhat weaker than a PKI in order > to allow route optimization in those cases. There are several proposals > that somehow use "return routability" as the criteria for such a weaker > scheme. The use of return routability as a proof of address ownersip has some limitations, especially on nonswitched broadcast links. SUCV and CAM both provide a lightweight solution to the problem of address ownership, by cryptographically binding the home address to the public key of MN. This could be used in combination with almost any protocol, which uses public key cryptograhy, to verify cryptograhically that MN really "owns" its home address. IMHO use of a SUCV is a lot more secure than using return routability. Also as there is no dependence on a trusted third party, the protocol should scale well. Henrik Petander From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 1 13:12: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 NAA22807 for ; Wed, 1 Aug 2001 13:12:15 -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 LAA23570; Wed, 1 Aug 2001 11:12: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 KAA29100; Wed, 1 Aug 2001 10:12:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f71HB9I12602 for mobile-ip-dist; Wed, 1 Aug 2001 10:11:09 -0700 (PDT) Received: from locked.eng.sun.com (locked [129.146.85.189]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f71HB5D12595 for ; Wed, 1 Aug 2001 10:11:05 -0700 (PDT) Received: (from mohanp@localhost) by locked.eng.sun.com (8.11.2+Sun/8.11.2) id f71H9r904353 for mobile-ip@sunroof.eng.sun.com; Wed, 1 Aug 2001 10:09:53 -0700 (PDT) From: Mohan Parthasarathy Message-Id: <200108011709.f71H9r904353@locked.eng.sun.com> Subject: Re: [mobile-ip] on using IPsec to secure Binding Updates In-Reply-To: <200107311720.NAA12323@rotala.raleigh.ibm.com> from Thomas Narten at "Jul 31, 2001 01:20:22 pm" To: mobile-ip@sunroof.eng.sun.com Date: Wed, 1 Aug 2001 10:09:53 -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 Thomas, If you separate the key management from using AH and ESP for securing binding updates, you have raised two issues about using AH or ESP itself : 1) There is no policy selector for securing just binding update 2) The state maintained by IPsec could be large. (1) is not really a big issue if we could come up with a new next header value. At least IPv6 was designed to do such things i guess. We really have to think about (2). At least any new solution that does not propose to use IPsec should not maintain state larger than what IPsec would need. Should this be in the requirements draft ? -mohan > 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 Wed Aug 1 13:22: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 NAA23181 for ; Wed, 1 Aug 2001 13:22: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 KAA28470; Wed, 1 Aug 2001 10:20: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 KAA27573; Wed, 1 Aug 2001 10:05:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f71H4ab12436 for mobile-ip-dist; Wed, 1 Aug 2001 10:04: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+Sun/8.11.5) with ESMTP id f71H4XD12427 for ; Wed, 1 Aug 2001 10:04: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 KAA03023 for ; Wed, 1 Aug 2001 10:04:47 -0700 (PDT) Message-Id: <200108011704.KAA03023@heliopolis.eng.sun.com> Date: Wed, 1 Aug 2001 10:04:40 -0700 (PDT) From: James Kempf Subject: Re: [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: yXX7+Xluye2f6VYJ6kl74w== 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 Alper, Thanx for the review. > >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. > This not strictly accurate. It takes out the signaling at L3. There is still signaling at L2. The MN must know when it comes up on the new link, and what the L2 address of its router is, otherwise it can't get packets out. >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. > I'm not sure I understand your example. Perhaps you have identified a problem here, but lacking more detail, I can't see it. If a situation happens as you identify it, the MN can begin establishing a new CoA at any time. As soon as the new AR detects that the MN has completed this, it signals the old AR via a HRqst to tear down the tunnel. If the MN succeeds in getting a new CoA on old AR, old AR simply doesn't tunnel. In general, BETH is not proposing to replace or otherwise negate the existing handover mechanisms, just to augment them. If the MN discovers a router, it is perfectly free to perform a standard FMIPv6 handover, or even a stock Johnson and Perkins handover if it so chooses. The mobile node is completely in control of when it decides to begin the process of obtaining a new CoA. That, in fact, is the key differentator between BETH and both the standard FMIPv6 and Johnson and Perkins algorithms. These algorithms leave the MN no choice, it *must* obtain a new CoA regardless of whether the process would interrupt a real time flow. >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? > Well, this is a policy question and something that I don't think is appropriate for the protocol draft. There maybe be some need in particular situations to codify the interaction between BETH and FMIPv6 more precisely if there is interference, if so, then we need to clarify it. We probably need to go through some protocol flows to check this, similarly for the interaction between FMIPv6 and the original Johnson and Perkins algorithm. BETH is no different than standard FMIPv6 or the original Johnson and Perkins algorithm in this regard. Should a router advertise if it is capable of FMIPv6 so that it can suppress MIPv6? If so, then perhaps we need some policy knobs that let a network administrator configure what type of handover they want to support, and a way to communicate that to the MN when it enters the network. >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? I'm not clear on exactly what you are proposing, but if I understand you correctly, I think there are more open questions about how a second interface would get used than BETH. For example, if an interface is already configured with a global IPv6 address and a MIP CoA, then there would need to be some process on the MN to cause that binding to be transferred to the new interface. The global IPv6 address would need to be transferred and there would need to be a new CoA on the new interface (unless, of course, the new interface is on the same subnet). The Neighbor Caches on the routers need to be updated, to reflect the new binding between the CoA and L2 address. This is naturally going to require a certain amount of radio traffic, and so it is not appropriate for BETH handover to be used in this situation. BETH is only for extremely time critical handover, such as is involved in real time traffic. Before we start discussing how to handle interaction between BETH and a MN with two interfaces, I think we need a better understanding of how a MN with two interfaces would perform a standard MIPv6 handover 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. > The signal should be the BACK from the HA and any CNs, because it is only at that point when the new CoA can really be used. The ARs tear down the tunnel at this point, though they may keep it up for some configurable time period in order to assure that any laggard packets get to the MN. The draft should be more precise about this. >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. > As I mentioned, the MN is completely informed via L2 and is, in fact, more in control than in FMIPv6. In BETH, the MN can choose to use the standard FMIPv6 algorithm, where it gets to choose which router it wants, etc. *And* it gets to choose when to establish a new CoA. With FMIPv6, it only gets the first. > >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. > Delay occurs when the radio link is used for anything other than real time traffic, regardless if it occurs on the old link or the new. On a 9.6 Kbps radio link (currently used for 2.5G cellular voice), signalling traffic on the dedicated traffic channel will block any other traffic. Cellular protocols currently use the dedicated traffic channel for IP signalling. One could imagine using the dedicated signalling channel for IP signalling, and that would help to free the traffic channel since the IP signalling can go on in parallel, but even then the signalling channels tend to be substantially slower than the traffic channels (I think wCDMA uses 3 Kbps if I remember correctly), so there is the potential that a MN could start the process of obtaining a new CoA by anticipation and end up moving to a new access router before it actually had the new CoA. BETH would handle this smoothly, so I think there is a place for it even if IP signalling traffic moves to a dedicated channel. Not to mention: moving IP signalling traffic to a dedicated signalling channel would require the 3Gs to actually modify their air interface, something difficult and time consuming to do. >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. > > My understanding from reading the FMIPv6 draft is that the F-NA is what triggers the process of Neighbor Cache update at new AR, DAD, and all the other good but time consuming stuff involved in getting an IPv6 host up on a new subnet. Is that not so? Note that these calculations do not consider the BU/BACK from the HA nor from CNs. If you add those into the picture, you get considerably more time until the new CoA can be used. In that sense, the calculations are very optimistic, and for all but the first scenario consider that the MN will be using its old CoA on the new AR just like in BETH (considered a corner case in the original FMIPv6). >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? > As mentioned above, the tunnel should be kept up until all BU/BACK from the HA and CNs have arrived, and perhaps even remain up for a short period after to catch any laggard packets. It is only at that point that the MN can begin to reliably send and receive packets on the new 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. > Alper, everything that involves radio traffic not related specifically to applications running on the MN has a latency cost and is pure overhead. Everything. At 9.6 Kbps, it takes 1.2 ms to send a byte. If the byte is in a mobile IP packet, or a routing advertisement, or anything other than a packet involved in the application, that is 1.2 ms that is not available for sending application data. If the application is a real time application, you can only get away with sending overhead for an extremely short time before the user notices. The only way to get around this is to either do the signalling on a separate channel or crank up the speed of the radio link (if you can, wCDMA allows this, cdma2000 doesn't). That's why the 3G radio protocols have separate signalling channels in the first place, unfortunately, we don't get to use them. I agree that we need to do some protocol flows to identify the interaction between BETH, standard FMIPv6 and the original Johnson and Perkins algorithm. These flows should identify whether there are any situations in which there is need for some additional work to allow suppression or switchover, or perhaps specification about what the ARs and MN should or should not do in particular windows. I don't think, however, that BETH is any different from the other two algorithms in this regard. jak From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 1 13:26: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 NAA23321 for ; Wed, 1 Aug 2001 13:26:13 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA06800; Wed, 1 Aug 2001 11:26: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 KAA03080; Wed, 1 Aug 2001 10:26:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f71HOeM12840 for mobile-ip-dist; Wed, 1 Aug 2001 10:24:40 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f71HObD12833 for ; Wed, 1 Aug 2001 10:24: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 KAA06923 for ; Wed, 1 Aug 2001 10:24:51 -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 LAA05928 for ; Wed, 1 Aug 2001 11:26:19 -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 f71HOiN16074 for ; Wed, 1 Aug 2001 19:24:44 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed Aug 01 19:24:43 2001 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 1 Aug 2001 19:18:27 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008B9B@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Vijay Devarapalli '" , "'mobile-ip@sunroof.eng.sun.com '" Subject: RE: [mobile-ip] Concern over draft-team-mobileip-mipv6-sec-reqts- 00.txt Date: Wed, 1 Aug 2001 19:24:35 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) List-Subscribe: List-Unsubscribe: Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Vijay, 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. => The Home address destination option is not relevant here. The BU is. These are 2 separate options so you don't need to apply the AH to every packet. Hesham 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 Wed Aug 1 13:26: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 NAA23334 for ; Wed, 1 Aug 2001 13:26: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 LAA06942; Wed, 1 Aug 2001 11:26: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 KAA02945; Wed, 1 Aug 2001 10:25:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f71HOnU12853 for mobile-ip-dist; Wed, 1 Aug 2001 10:24:49 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f71HOiD12844 for ; Wed, 1 Aug 2001 10:24: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 KAA23518 for ; Wed, 1 Aug 2001 10:24:58 -0700 (PDT) Received: from tml-gw.tml.hut.fi (tml.hut.fi [130.233.44.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA04995 for ; Wed, 1 Aug 2001 11:24:53 -0600 (MDT) Received: (from smap@localhost) by tml-gw.tml.hut.fi (8.8.7/8.8.7) id UAA05161 for ; Wed, 1 Aug 2001 20:22:17 +0300 Received: from mail.tml.hut.fi(130.233.45.70) by tml-gw.tml.hut.fi via smap (V2.0) id xma005146; Wed, 1 Aug 01 20:21:48 +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 f71HNKN08563 for ; Wed, 1 Aug 2001 20:23:20 +0300 (EEST) Received: from localhost (lpetande@localhost) by morphine.tml.hut.fi (8.11.3/8.11.3) with ESMTP id f71HOHv23578 for ; Wed, 1 Aug 2001 20:24:17 +0300 (EET DST) X-Authentication-Warning: morphine.tml.hut.fi: lpetande owned process doing -bs Date: Wed, 1 Aug 2001 20:24:17 +0300 (EET DST) From: Lars Henrik Petander To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Authentication Data as a BU suboption In-Reply-To: <3B66F7B9.51090EC0@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Vijay, I am mostly neutral on whether the authentication data should be in the AH or in the BU itself. Both solutions have their benefits and drawbacks. However, the version 14 of the draft should be clearer on how the BSA is created, used and destroyed: The BSAs should be deleted when MN deregisters, since the replay state for MN is deleted then. If MN and HA have a preconfigured shared secret they need some new mechanism of deriving session keys to use for authenticating BUs and BAs. (If the same key is used for multiple sessions the replay protection from sequence numbers is broken) Henrik On Tue, 31 Jul 2001, 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. From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 1 13:34: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 NAA23693 for ; Wed, 1 Aug 2001 13:34:32 -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 LAA14586; Wed, 1 Aug 2001 11: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 KAA25810; Wed, 1 Aug 2001 10:34:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f71HWSe13034 for mobile-ip-dist; Wed, 1 Aug 2001 10:32:29 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f71HWPD13024 for ; Wed, 1 Aug 2001 10:32: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 KAA04675 for ; Wed, 1 Aug 2001 10:32: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 KAA28954 for ; Wed, 1 Aug 2001 10:32:33 -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 KAA23726 for ; Wed, 1 Aug 2001 10:32:32 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f71HWVx06172 for ; Wed, 1 Aug 2001 10:32:31 -0700 X-mProtect: Wed, 1 Aug 2001 10:32: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 smtpdLFrfSr; Wed, 01 Aug 2001 10:32:30 PDT Message-ID: <3B683D2E.FB8B0DBD@iprg.nokia.com> Date: Wed, 01 Aug 2001 10:32: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: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Analysis of Latency Propagation with Buffering References: <200107301810.LAA26689@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 Jim, > 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, ^^^^^^^^delayed before reception > and the more likely users will perceive the converstation as stilted > or hear some artifact. I wanted to clarify that it isn't buffering itself that adds delay. A packet could be buffered AND transmitted to the mobile node at the same time, which then would show that buffering does not have to introduce any delay. If a packet is received by the mobile node, then presumably it would prefer not to receive the buffered copy of that packet at any time in the future. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 1 13:39: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 NAA24014 for ; Wed, 1 Aug 2001 13:39: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 LAA18869; Wed, 1 Aug 2001 11:40:28 -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 KAA27095; Wed, 1 Aug 2001 10:40:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f71HcTH13341 for mobile-ip-dist; Wed, 1 Aug 2001 10:38:29 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f71HcPD13334 for ; Wed, 1 Aug 2001 10:38: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 KAA05580 for ; Wed, 1 Aug 2001 10:38: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 KAA02369 for ; Wed, 1 Aug 2001 10:38:33 -0700 (PDT) Received: (qmail 8747 invoked by uid 500); 1 Aug 2001 17:27:36 -0000 Date: Wed, 1 Aug 2001 10:27:36 -0700 From: Pat Calhoun To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Analysis of Latency Propagation with Buffering Message-ID: <20010801102736.F7881@charizard.diameter.org> References: <200107301810.LAA26689@heliopolis.eng.sun.com> <3B683D2E.FB8B0DBD@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: <3B683D2E.FB8B0DBD@iprg.nokia.com>; from charliep@iprg.nokia.com on Wed, Aug 01, 2001 at 10:32:30AM -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, Aug 01, 2001 at 10:32:30AM -0700, Charles E. Perkins wrote: > If a packet is received by the mobile node, > then presumably it would prefer not to receive the buffered copy of > that packet at any time in the future. sure, otherwise that would sure look like bicasting :) PatC From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 1 13:53: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 NAA24917 for ; Wed, 1 Aug 2001 13:53:37 -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 LAA01112; Wed, 1 Aug 2001 11:54: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 KAA00622; Wed, 1 Aug 2001 10:53:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f71HpDt13548 for mobile-ip-dist; Wed, 1 Aug 2001 10:51:13 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f71HpAD13541 for ; Wed, 1 Aug 2001 10:51:10 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA08950 for ; Wed, 1 Aug 2001 10:51:24 -0700 (PDT) Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA28164 for ; Wed, 1 Aug 2001 11:51:06 -0600 (MDT) Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83]) by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f71Hp7T26257 for ; Wed, 1 Aug 2001 13:51:07 -0400 (EDT) Received: by IL0015EXCH001H with Internet Mail Service (5.5.2650.21) id ; Wed, 1 Aug 2001 12:53:02 -0500 Message-ID: From: "Dolan, Michael F (Mike)" To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] What's UP? Where will you be? Date: Wed, 1 Aug 2001 12:47:18 -0500 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: Pat, I saw your note that you will be leaving Sun. Can you say where you will be planting your new roots? Will you be involved in Diameter and All-IP stuff? I hope that this will be a good move and will work out great! Have a good day, Mike Dolan Lucent Technologies - Bell Labs 263 Shuman Blvd., Room 2D-229 Naperville, IL 60566-7050, USA * Office: +1.630.979.1033 * Mobile: +1.630.697.3549 * Email: mfdolan@lucent.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -----Original Message----- From: Pat Calhoun [mailto:pcalhoun@diameter.org] Sent: Wednesday, August 01, 2001 12:28 PM To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Analysis of Latency Propagation with Buffering On Wed, Aug 01, 2001 at 10:32:30AM -0700, Charles E. Perkins wrote: > If a packet is received by the mobile node, > then presumably it would prefer not to receive the buffered copy of > that packet at any time in the future. sure, otherwise that would sure look like bicasting :) PatC From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 1 14:04: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 OAA25391 for ; Wed, 1 Aug 2001 14:04: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 MAA11089; Wed, 1 Aug 2001 12:05: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 LAA03581; Wed, 1 Aug 2001 11:04:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f71I2Ca13666 for mobile-ip-dist; Wed, 1 Aug 2001 11:02:12 -0700 (PDT) Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f71I28D13655 for ; Wed, 1 Aug 2001 11:02:08 -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 f71I2J229923; Wed, 1 Aug 2001 20:02:19 +0200 (MET DST) Date: Wed, 1 Aug 2001 20:00:04 +0200 (CEST) From: Erik Nordmark Subject: Re: [mobile-ip] Concern over draft-team-mobileip-mipv6-sec-reqts-00.txt To: Lars Henrik Petander Cc: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > The use of return routability as a proof of address ownersip has some > limitations, especially on nonswitched broadcast links. Agreed. My intent was just to have return routability as an example of a weaker mechanism. Sorry for not making that clear. > SUCV and CAM both provide a lightweight solution to the problem of address > ownership, by cryptographically binding the home address to the public key > of MN. This could be used in combination with almost any protocol, which > uses public key cryptograhy, to verify cryptograhically that MN really > "owns" its home address. While I'm not up on the latest draft I suspect that there can be DoS issues. For instance, invoking public key crypto operations to verify the binding between a SUCV address and a key, when a random packet is received might be asking for DoS attacks. This can be avoided by in effect doing a return routability checking handshake before invoking the public key operations. Erik From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 1 14:22: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 OAA26099 for ; Wed, 1 Aug 2001 14:22: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 KAA14771; Wed, 1 Aug 2001 10:56: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 KAA29110; Wed, 1 Aug 2001 10:12:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f71HBEM12611 for mobile-ip-dist; Wed, 1 Aug 2001 10:11:14 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f71HB9D12604 for ; Wed, 1 Aug 2001 10:11:09 -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 KAA20488 for ; Wed, 1 Aug 2001 10:11: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 KAA17239 for ; Wed, 1 Aug 2001 10:11:19 -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 f71HBHN13804 for ; Wed, 1 Aug 2001 19:11:17 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Wed Aug 01 19:11:05 2001 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 1 Aug 2001 19:04:53 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008B9A@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Vijay Devarapalli '" , "'mobile-ip@sunroof.eng.sun.com '" Subject: RE: [mobile-ip] Authentication Data as a BU suboption Date: Wed, 1 Aug 2001 19:11:04 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) List-Subscribe: List-Unsubscribe: Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: 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 => That would add zero cost. 2. we dont have to modify the ipsec selectors => Again zero (or insignificant) cost 3. we dont have to protect the whole packet => Why is that an advantage ? 4. we dont have bother about the traffic flows between the MN and the CN. => We don't have to anyway if we stop piggybacking. 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. => Do you really see a lookup time as a critical issue ? I'm not sure that it would be, even for real time data. Are there any figures on how long it takes ? 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. => Sure, but what's the added value in doing it earlier ? One advantage is that you might like to allow for IKE when strong authentication is needed. Why eliminate that option ? Hesham From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 1 14:59: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 OAA28008 for ; Wed, 1 Aug 2001 14:59:32 -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 NAA26970; Wed, 1 Aug 2001 13:00: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 LAA16496; Wed, 1 Aug 2001 11:59:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f71IvkG14121 for mobile-ip-dist; Wed, 1 Aug 2001 11:57:47 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f71IvhD14114 for ; Wed, 1 Aug 2001 11:57: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 LAA29793 for ; Wed, 1 Aug 2001 11:57:56 -0700 (PDT) Received: from meshpdc.meshnetworks.com ([205.245.27.196]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA25035 for ; Wed, 1 Aug 2001 12:57:54 -0600 (MDT) Received: by meshpdc.meshnetworks.com with Internet Mail Service (5.5.2653.19) id ; Wed, 1 Aug 2001 14:57:55 -0400 Message-ID: <0DF9FBC42474A24CA50F7A27FB08E048445611@meshpdc.meshnetworks.com> From: Phillip Neumiller To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Analysis of Latency Propagation with Buffering Date: Wed, 1 Aug 2001 14:57: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: And it sure seems more logical to bicast since if you need it you DONT have to ask for it and WAIT around the RTT! -pdn > -----Original Message----- > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > Sent: Wednesday, August 01, 2001 1:28 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Analysis of Latency Propagation with > Buffering > > > On Wed, Aug 01, 2001 at 10:32:30AM -0700, Charles E. Perkins wrote: > > If a packet is received by the mobile node, > > then presumably it would prefer not to receive the buffered copy of > > that packet at any time in the future. > > sure, otherwise that would sure look like bicasting :) > > PatC > From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 1 15:13: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 PAA28724 for ; Wed, 1 Aug 2001 15:13: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 KAA08844; Wed, 1 Aug 2001 10:57:21 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA25116; Wed, 1 Aug 2001 09:56:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f71GtMv12290 for mobile-ip-dist; Wed, 1 Aug 2001 09:55:22 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f71GtID12282 for ; Wed, 1 Aug 2001 09:55:18 -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 JAA17139 for ; Wed, 1 Aug 2001 09:55: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 JAA08694 for ; Wed, 1 Aug 2001 09:55:26 -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 f71GtPN11132 for ; Wed, 1 Aug 2001 18:55:25 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Wed Aug 01 18:55:19 2001 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 1 Aug 2001 18:49:07 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008B98@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Gopal Dommety '" , "'mobile-ip@sunroof.eng.sun.com '" , "'mobile-ip@sunroof.eng.sun.com '" Subject: RE: [mobile-ip] Re:Comments on draft-ietf-mobileip-fast-mipv6-02. txt Date: Wed, 1 Aug 2001 18:55:18 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) List-Subscribe: List-Unsubscribe: Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Gopal, DAD handling was already covered by the introduction of HI/HAck. The text below wouldn't hurt though. Hesham -----Original Message----- From: Gopal Dommety To: mobile-ip@sunroof.eng.sun.com; mobile-ip@sunroof.eng.sun.com Sent: 7/31/2001 5:36 PM Subject: Re: [mobile-ip] Re:Comments on draft-ietf-mobileip-fast-mipv6-02.txt 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 Wed Aug 1 15:25: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 PAA29416 for ; Wed, 1 Aug 2001 15:25: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 NAA16193; Wed, 1 Aug 2001 13:26: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 MAA22325; Wed, 1 Aug 2001 12:26:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f71JOAO14338 for mobile-ip-dist; Wed, 1 Aug 2001 12:24:10 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f71JO6D14331 for ; Wed, 1 Aug 2001 12:24:06 -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 MAA05381 for ; Wed, 1 Aug 2001 12:24:19 -0700 (PDT) Received: from fep04-app.kolumbus.fi (fep04-0.kolumbus.fi [193.229.0.56]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA27525 for ; Wed, 1 Aug 2001 12:24:18 -0700 (PDT) Received: from jariws1 ([62.248.155.56]) by fep04-app.kolumbus.fi (InterMail vM.5.01.03.08 201-253-122-118-108-20010628) with SMTP id <20010801192417.CETE1828.fep04-app.kolumbus.fi@jariws1>; Wed, 1 Aug 2001 22:24:17 +0300 Message-ID: <006d01c11abf$8812e560$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Erik Nordmark" Cc: , "Jean-Michel COMBES" References: Subject: Re: [mobile-ip] Concern over draft-team-mobileip-mipv6-sec-reqts-00.txt Date: Wed, 1 Aug 2001 22:23:53 +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 Erik writes: > > JMC : I'm happy to hear this !!! I think this is the cheapest and best > > solution. I would be afraid to have to pay a high cost to secure MIPv6 > > while by changing just two little things (ie. BU "nxt header" value and > > "no piggybacking"), we could use existing tools ... > > That would solve part of the outstanding issues. > But with just those changes you would still need a PKI that includes > both the MN and the CN in order to use route optimization. > It is my understanding that folks one to use route optimizations even when > a PKI with such scope is not available. Yes, we absolutely need to have a PKI-less solution for the global Internet use. (Perhaps also a PKI solution for the Intranet use.) But this working group already has an ongoing effort to create such a PKI-less key management solution, and luckily we can keep the actual BU protection and the authentication/key management questions separate. Therefore, we are free to choose between MIP-specific BU protection and IPsec AH independent of how the key management is solved. (Of course, it might be easier to get also the PKI-solution if IPsec AH was used.) Jari From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 1 15:44: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 PAA00611 for ; Wed, 1 Aug 2001 15:44: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 NAA28794; Wed, 1 Aug 2001 13:45:05 -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 MAA26232; Wed, 1 Aug 2001 12:44:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f71JgCd14442 for mobile-ip-dist; Wed, 1 Aug 2001 12:42:12 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f71Jg8D14435 for ; Wed, 1 Aug 2001 12:42:09 -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 MAA03725 for ; Wed, 1 Aug 2001 12:42: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 NAA26688 for ; Wed, 1 Aug 2001 13:42:16 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id MAA07887; Wed, 1 Aug 2001 12:42:16 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f71JgFw31895; Wed, 1 Aug 2001 12:42:15 -0700 X-mProtect: Wed, 1 Aug 2001 12:42:15 -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 smtpdQv7EvW; Wed, 01 Aug 2001 12:42:14 PDT Message-ID: <3B685B96.E0873655@iprg.nokia.com> Date: Wed, 01 Aug 2001 12:42:14 -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: Phillip Neumiller CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Analysis of Latency Propagation with Buffering References: <0DF9FBC42474A24CA50F7A27FB08E048445611@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 Hello Phil, If I order a pizza, and somebody brings me two, and charges me twice, that's bad. If I get two for one for free, that's better, but from the standpoint of the restaurateur it would be nice if the government didn't tell him he HAD to serve me two for one. Furthermore, if I'm tired of eating and I still have to swallow the extra food, I might complain even about the freebie. If, on the other hand, I can buy just the pizza I want, and if I have to leave before I finish the meal but later I can ask for the slices that are still hot, that sounds about right to me. Regards, Charlie P. Phillip Neumiller wrote: > > And it sure seems more logical to bicast since if you need it you > DONT have to ask for it and WAIT around the RTT! > > -pdn > > > -----Original Message----- > > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > > Sent: Wednesday, August 01, 2001 1:28 PM > > To: mobile-ip@sunroof.eng.sun.com > > Subject: Re: [mobile-ip] Analysis of Latency Propagation with > > Buffering > > > > > > On Wed, Aug 01, 2001 at 10:32:30AM -0700, Charles E. Perkins wrote: > > > If a packet is received by the mobile node, > > > then presumably it would prefer not to receive the buffered copy of > > > that packet at any time in the future. > > > > sure, otherwise that would sure look like bicasting :) > > > > PatC > > From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 1 15:48: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 PAA01007 for ; Wed, 1 Aug 2001 15:48: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 NAA02016; Wed, 1 Aug 2001 13:49: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 MAA27070; Wed, 1 Aug 2001 12:48:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f71JlfE14512 for mobile-ip-dist; Wed, 1 Aug 2001 12:47:41 -0700 (PDT) Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f71JlbD14505 for ; Wed, 1 Aug 2001 12:47:37 -0700 (PDT) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f71JlT205360; Wed, 1 Aug 2001 21:47:30 +0200 (MET DST) Date: Wed, 1 Aug 2001 21:45:10 +0200 (CEST) From: Erik Nordmark Subject: Re: [mobile-ip] Concern over draft-team-mobileip-mipv6-sec-reqts-00.txt To: Jari Arkko Cc: Erik Nordmark , mobile-ip@sunroof.eng.sun.com, Jean-Michel COMBES In-Reply-To: "Your message with ID" <006d01c11abf$8812e560$8a1b6e0a@arenanet.fi> 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: > Therefore, we are free to choose between > MIP-specific BU protection and IPsec AH independent of how > the key management is solved. You are assuming that it is easy to use IKE to create non-IPsec keys e.g. for MIP specific BU protection. Are you sure it is that easy? (I don't have any data - but I thought IKE was tied to IPsec.) Erik From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 1 15:52: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 PAA01214 for ; Wed, 1 Aug 2001 15:52: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 NAA04949; Wed, 1 Aug 2001 13:53: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 MAA27796; Wed, 1 Aug 2001 12:53:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f71JpZe14580 for mobile-ip-dist; Wed, 1 Aug 2001 12:51:35 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f71JpVD14570 for ; Wed, 1 Aug 2001 12:51: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 MAA05748 for ; Wed, 1 Aug 2001 12:51:45 -0700 (PDT) Received: from rajma.kniveton.com (adsl-63-197-0-77.dsl.snfc21.pacbell.net [63.197.0.77]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA16319 for ; Wed, 1 Aug 2001 12:51:40 -0700 (PDT) Received: from Kniveton.com (eldorado.kniveton.com [192.168.1.70]) by rajma.kniveton.com (8.11.1/8.11.1) with ESMTP id f71Jpdd27679 for ; Wed, 1 Aug 2001 12:51:40 -0700 (PDT) Message-ID: <3B685DC5.A9D781BD@Kniveton.com> Date: Wed, 01 Aug 2001 12:51:33 -0700 From: "T.J. Kniveton" Organization: NOKIA Research X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Concerns about draft-mipv6-14 section 4.8 References: <0DF9FBC42474A24CA50F7A27FB08E0484455F8@meshpdc.meshnetworks.com> <3B671944.E9F1F0B0@Kniveton.com> <3B67F996.BD665A40@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 Excellent post Thierry. I agree with your points exactly. -TJ Thierry Ernst wrote: > "T.J. Kniveton" wrote: > > > > 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? > > Indeed, there would be such one good reason: mobile networks have an > implication on other aspects not related to Mobile IP. For instance, on > routing protocols, but the right place for the discussion is still > Mobile IP because we have to determine whether Mobile IPv6 is the right > base protocol for network mobility support. Mobile IPv6 may not be able > to address all issues, but it surely can help. > > I agree that MANET WG could benefit from this discussion (how do you > manage mobility of an ad-hoc network that changes its point of > attachment ?), but it's not a better place than Mobile IP WG. MANET WG > is more concerned by "how things are done INSIDE the network" than "how > to manage subsequent point of attachments to the Internet", which is > Mobile IP WG's. > > Anyway, seems clear to me that everyone agree that this should not be > addressed in the MIPv6 draft itself, but in a separate document. > > Thierry. > > > 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? > > -- > * 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 Aug 1 16:08: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 QAA02228 for ; Wed, 1 Aug 2001 16:08:18 -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 OAA15602; Wed, 1 Aug 2001 14:08: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 NAA00967; Wed, 1 Aug 2001 13:08:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f71K6Ao14726 for mobile-ip-dist; Wed, 1 Aug 2001 13:06:10 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f71K66D14719 for ; Wed, 1 Aug 2001 13:06:06 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA08419 for ; Wed, 1 Aug 2001 13:06:20 -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 OAA22751 for ; Wed, 1 Aug 2001 14:07:50 -0600 (MDT) Received: by meshpdc.meshnetworks.com with Internet Mail Service (5.5.2653.19) id ; Wed, 1 Aug 2001 16:06:17 -0400 Message-ID: <0DF9FBC42474A24CA50F7A27FB08E048445612@meshpdc.meshnetworks.com> From: Phillip Neumiller To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Analysis of Latency Propagation with Buffering Date: Wed, 1 Aug 2001 16:06:13 -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 Charlie, A single pizza is not really a good example. Its perhaps better to think of yourself as SERVING pizzas to visiting dignitaries and you have to keep the pizzas coming to ensure that they are always happy (i.e. the pizzas are warm NOT stale). In this case if the dignitaries can be in two possible places during certain periods of time (handoffs) it is VERY wise to send pizzas to both locations. QED :-) -pdn > -----Original Message----- > From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] > Sent: Wednesday, August 01, 2001 3:42 PM > To: Phillip Neumiller > Cc: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Analysis of Latency Propagation with > Buffering > > > Hello Phil, > > If I order a pizza, and somebody brings me two, and > charges me twice, that's bad. > > If I get two for one for free, that's better, but from > the standpoint of the restaurateur it would be nice > if the government didn't tell him he HAD to serve me > two for one. Furthermore, if I'm tired of eating and > I still have to swallow the extra food, I might complain > even about the freebie. > > If, on the other hand, I can buy just the pizza I want, > and if I have to leave before I finish the meal but > later I can ask for the slices that are still hot, > that sounds about right to me. > > Regards, > Charlie P. > > > > Phillip Neumiller wrote: > > > > And it sure seems more logical to bicast since if you need it you > > DONT have to ask for it and WAIT around the RTT! > > > > -pdn > > > > > -----Original Message----- > > > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > > > Sent: Wednesday, August 01, 2001 1:28 PM > > > To: mobile-ip@sunroof.eng.sun.com > > > Subject: Re: [mobile-ip] Analysis of Latency Propagation with > > > Buffering > > > > > > > > > On Wed, Aug 01, 2001 at 10:32:30AM -0700, Charles E. > Perkins wrote: > > > > If a packet is received by the mobile node, > > > > then presumably it would prefer not to receive the > buffered copy of > > > > that packet at any time in the future. > > > > > > sure, otherwise that would sure look like bicasting :) > > > > > > PatC > > > > From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 1 16:12: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 QAA02493 for ; Wed, 1 Aug 2001 16:12: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 LAA21869; Wed, 1 Aug 2001 11:43: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 KAA28021; Wed, 1 Aug 2001 10:43:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f71Hfq213399 for mobile-ip-dist; Wed, 1 Aug 2001 10:41:52 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f71HfiD13380 for ; Wed, 1 Aug 2001 10:41:44 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA06257 for ; Wed, 1 Aug 2001 10:41:38 -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 LAA14482 for ; Wed, 1 Aug 2001 11:43:09 -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 f71HfZO01975 for ; Wed, 1 Aug 2001 19:41:35 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Wed Aug 01 19:41:35 2001 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 1 Aug 2001 19:35:18 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008B9D@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Michael Thomas '" , "'Erik Nordmark '" Cc: "Jari Arkko (LMF)" , "Hesham Soliman (ERA)" , "'charliep@iprg.nokia.com '" , "'mobile-ip@sunroof.eng.sun.com '" Subject: RE: [mobile-ip] Concern over draft-team-mobileip-mipv6-sec-reqts- 00.txt Date: Wed, 1 Aug 2001 19:41:27 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Mike, Let's get an agreement on this: the MN can use AH without needing a new nxt header value and without using AH on every packet with a Home address option if : - No piggybacking was allowed - The IPsec selectors granularity was refined to see the BU option not the Home address option. I do however agree with the option Erik mentioned below (having a new nxt header) in which case only eliminating piggybacking would be needed. But I would like to leave the 2 options open. So in one case a nxt header value is needed and in another the IPsec granularity is changed. Of course this is assuming piggybacking is disallowed. Hesham -----Original Message----- From: Michael Thomas To: Erik Nordmark Cc: Michael Thomas; Jari Arkko; Hesham.Soliman@era.ericsson.se; charliep@iprg.nokia.com; mobile-ip@sunroof.eng.sun.com Sent: 8/1/2001 6:20 PM Subject: Re: [mobile-ip] Concern over draft-team-mobileip-mipv6-sec-reqts-00.txt Erik Nordmark writes: > > > 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. > > I think there are some issues here. Recall the MIPv6 uses destination options > for binding updates, acks, requests, as well as home address option. > > Even if nobody ever invents any new destination options header this means > that if the IPsec policy says that packets with nexthdr = destination options > this effects packets containing e.g. home address options. > Thus for traffic between two mobile nodes (which always have home address > options in both directions) you'd be forced to use IPsec on every packet. > In fact, when a mobile node is sending packets (using its home > address) it must always include a home address option thus those packets > would require IPsec. > > Of course, if other destination options are invented in the future the > precense of those would also force IPsec which might be undesirable. > > So things for sure would be simpler if, in addition to no piggybacking, > the BU (and binding acks, requests as well?) were sent using a different > nexthdr value or otherwise using different IPsec selectors (i.e. a UDP port > number would avoid this issue as well.) Yes, the more I think about this the more I'm inclined to agree. Another negative effect would be that you'd be unable to use SRTP instead of IPsec which in turn would pooch ROHC for the media (or at least give 12-16 bytes more of uncompressible data per packet). A longer term solution would be to extend the generalized port semantics to DO's just as it's getting extended to support SCTP right now. I think I'd probably favor that more for the following reasons: 1) Creating a new header type always seems like a rather large club to beat on a problem 2) IPsec will work right now if you're willing to live with the restrictions (ie, all home address options would need crypto applied to it too) 3) The situation where this would be problematic is just the MN/CN traffic since the traffic is tunneled between the HA/MN. I imagine that *most* of the MN/CN BU's will actually be the weak variety instead. 4) Where strong authentication is used between MN/CN is likely to be an all or nothing proposition anyway (ie, all PDA's in my enterprise using 802.11 MUST set up IPsec transport SA's to protect *everything*). Thus #2 may be a not-terrible restriction. Thus, waiting for an abstracted port mechanism for DO's may be viewed as more of a completeness issue, rather than a must have issue. Mike From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 1 16:28: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 QAA03404 for ; Wed, 1 Aug 2001 16:28: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 NAA22023; Wed, 1 Aug 2001 13:27: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 NAA01897; Wed, 1 Aug 2001 13:13:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f71KCFo14768 for mobile-ip-dist; Wed, 1 Aug 2001 13:12:15 -0700 (PDT) Received: from locked.eng.sun.com (locked [129.146.85.189]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f71KCCD14761 for ; Wed, 1 Aug 2001 13:12:12 -0700 (PDT) Received: (from mohanp@localhost) by locked.eng.sun.com (8.11.2+Sun/8.11.2) id f71KAxn04501; Wed, 1 Aug 2001 13:10:59 -0700 (PDT) From: Mohan Parthasarathy Message-Id: <200108012010.f71KAxn04501@locked.eng.sun.com> Subject: Re: [mobile-ip] Concern over draft-team-mobileip-mipv6-sec-reqts-00.txt In-Reply-To: from Erik Nordmark at "Aug 1, 2001 09:45:10 pm" To: mobile-ip@sunroof.eng.sun.com Date: Wed, 1 Aug 2001 13:10:59 -0700 (PDT) CC: Jari Arkko , Erik Nordmark , Jean-Michel COMBES 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 > > Therefore, we are free to choose between > > MIP-specific BU protection and IPsec AH independent of how > > the key management is solved. > > You are assuming that it is easy to use IKE to create non-IPsec keys e.g. > for MIP specific BU protection. > Are you sure it is that easy? > (I don't have any data - but I thought IKE was tied to IPsec.) > From RFC2409, Phase 2 is where Security Associations are negotiated on behalf of services such as IPsec or any other service which needs key material and/or parameter negotiation. "Quick Mode" accomplishes a phase 2 exchange. "Quick Mode" MUST ONLY be used in phase 2. I thought you would not need IKE, if you need only weak authentication. -mohan > Erik > From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 1 16:47: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 QAA04483 for ; Wed, 1 Aug 2001 16:47:35 -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 NAA01347; Wed, 1 Aug 2001 13:48: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 NAA09009; Wed, 1 Aug 2001 13:47:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f71Kjjw14900 for mobile-ip-dist; Wed, 1 Aug 2001 13:45:45 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f71KjaD14893 for ; Wed, 1 Aug 2001 13:45:36 -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 NAA08544; Wed, 1 Aug 2001 13:45:50 -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 OAA12087; Wed, 1 Aug 2001 14:45:47 -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 f71Kjf317679; Wed, 1 Aug 2001 13:45:41 -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 ABK41568; Wed, 1 Aug 2001 13:45:28 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA13040; Wed, 1 Aug 2001 13:45:28 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15208.27240.169011.796904@thomasm-u1.cisco.com> Date: Wed, 1 Aug 2001 13:45:28 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Cc: Jari Arkko , Erik Nordmark , Jean-Michel COMBES Subject: Re: [mobile-ip] Concern over draft-team-mobileip-mipv6-sec-reqts-00.txt In-Reply-To: References: <006d01c11abf$8812e560$8a1b6e0a@arenanet.fi> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Erik Nordmark writes: > > Therefore, we are free to choose between > > MIP-specific BU protection and IPsec AH independent of how > > the key management is solved. > > You are assuming that it is easy to use IKE to create non-IPsec keys e.g. > for MIP specific BU protection. > Are you sure it is that easy? > (I don't have any data - but I thought IKE was tied to IPsec.) IKE provides for domains of interpretation (DOI), though IPsec (2407) is the only one currently defined. ISAKMP provides a fairly general framework which is used by the group keying draft as well as KINK. It would require a pretty good understanding of 2407, 2408, and 2409 to contemplate creating new DOI, not to mention that the work would need to be back integrated into ISAKMP consumers (KINK, maybe GDOI??). Also, there is a question of how the kernel would get the keying information. PFKEY (2367) is the current method for many *nixes, but I don't know how extensible it is for things other than IPsec. An implementation issue for certain, but yet another complication. Mike From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 1 16:48: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 QAA04533 for ; Wed, 1 Aug 2001 16:48: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 NAA01904; Wed, 1 Aug 2001 13:49: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 NAA16955; Wed, 1 Aug 2001 13:48:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f71KlDG14918 for mobile-ip-dist; Wed, 1 Aug 2001 13:47:13 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f71Kl8D14911 for ; Wed, 1 Aug 2001 13:47: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 NAA15923; Wed, 1 Aug 2001 13: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 OAA11395; Wed, 1 Aug 2001 14:48:50 -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 NAA14696; Wed, 1 Aug 2001 13:47:14 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f71KlDr02322; Wed, 1 Aug 2001 13:47:13 -0700 X-mProtect: Wed, 1 Aug 2001 13:47:13 -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 smtpdZdf2lu; Wed, 01 Aug 2001 13:47:12 PDT Message-ID: <3B686ACF.AFCA9F86@iprg.nokia.com> Date: Wed, 01 Aug 2001 13:47:11 -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, hesham.soliman@era.ericsson.se, mohan.parthasarathy@eng.sun.com Subject: Re: [mobile-ip] Authentication Data as a BU suboption References: <034BEFD03799D411A59F00508BDF754603008B9C@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 from Mohan's mail > From RFC2409, > > Phase 2 is where Security Associations are negotiated on behalf of > services such as IPsec or any other service which needs key material > and/or parameter negotiation. "Quick Mode" accomplishes a phase 2 > exchange. "Quick Mode" MUST ONLY be used in phase 2. > the main thing in the above paragraph is "or any other service which needs key material". IKE is for key exchange. IKE/BAKE/PKI/AAA can all establish a key between two nodes. extract the security association from the database, store it in the binding update list and use it to authenticate the BU. the SA is stored in the binding cache entry in case of the CN. i am not an expert at IKE either. but that doest prevent me from going into the SPD database (mobile ip module), extract the SA and store it in the binding update list. the mobile ip module has the all the information it needs (key, spi, algorithm). it calculate the authentication checksum as soon as the BU option is created. vijay "Hesham Soliman (ERA)" wrote: > > i never eliminated IKE. when you need strong authentication > gets the keys using IKE. but instead of adding an authentication > header, you send the authentication checksum as a BU suboption. > > => My understanding was that the current BU format > does not allow the use of IKE. I'm not an expert > on -ike by any means but this was voiced on the list > by a few people and there was no opposition to this > opinion. > > Hesham > > "Hesham Soliman (ERA)" wrote: > > > > 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 > > > > => That would add zero cost. > > > > 2. we dont have to modify the ipsec selectors > > > > => Again zero (or insignificant) cost > > > > 3. we dont have to protect the whole packet > > > > => Why is that an advantage ? > > > > 4. we dont have bother about the traffic flows between > > the MN and the CN. > > > > => We don't have to anyway if we stop piggybacking. > > > > 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. > > > > => Do you really see a lookup time as a critical issue ? > > I'm not sure that it would be, even for real time > > data. Are there any figures on how long it takes ? > > > > 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. > > > > => Sure, but what's the added value in doing it > > earlier ? > > > > One advantage is that you might like to allow for > > IKE when strong authentication is needed. Why > > eliminate that option ? > > > > Hesham From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 1 16:50: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 QAA04646 for ; Wed, 1 Aug 2001 16:50: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 OAA16697; Wed, 1 Aug 2001 14:51:26 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA17722; Wed, 1 Aug 2001 13:51:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f71KnjL14997 for mobile-ip-dist; Wed, 1 Aug 2001 13:49:45 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f71KndD14983 for ; Wed, 1 Aug 2001 13:49:40 -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 NAA17337 for ; Wed, 1 Aug 2001 13:49:54 -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 NAA13830 for ; Wed, 1 Aug 2001 13:49:53 -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 f71Ko6Y25743; Wed, 1 Aug 2001 13:50:06 -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 ABK41698; Wed, 1 Aug 2001 13:49:51 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA13043; Wed, 1 Aug 2001 13:49:51 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15208.27503.450299.135095@thomasm-u1.cisco.com> Date: Wed, 1 Aug 2001 13:49:51 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Cc: "'Vijay Devarapalli '" Subject: RE: [mobile-ip] Concern over draft-team-mobileip-mipv6-sec-reqts- 00.txt In-Reply-To: <034BEFD03799D411A59F00508BDF754603008B9B@esealnt448.al.sw.ericsson.se> References: <034BEFD03799D411A59F00508BDF754603008B9B@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: > Vijay, > > 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. > > => The Home address destination option is not > relevant here. The BU is. These are 2 separate > options so you don't need to apply the AH to > every packet. I'm pretty sure that Vijay is correct here. IPsec selectors do not define a standard way to use the port numbers in the ID payload to select for different destination options. This is probably not that hard to define, but it's not standard now. Mike > > Hesham > > 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 Wed Aug 1 16:51: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 QAA04695 for ; Wed, 1 Aug 2001 16:51: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 OAA17504; Wed, 1 Aug 2001 14:52:30 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA18007; Wed, 1 Aug 2001 13:52:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f71KpBQ15047 for mobile-ip-dist; Wed, 1 Aug 2001 13:51: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+Sun/8.11.5) with ESMTP id f71Kp7D15040 for ; Wed, 1 Aug 2001 13:51: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 NAA14047 for ; Wed, 1 Aug 2001 13:51:21 -0700 (PDT) Message-Id: <200108012051.NAA14047@heliopolis.eng.sun.com> Date: Wed, 1 Aug 2001 13:51:13 -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: 2ykXzXWVYSJycvznNzmjDg== 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 Charlie, For some reason, your note was delayed and I got it after two responses. >Hello Jim, > >> 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, > ^^^^^^^^delayed before reception Agreed. >> and the more likely users will perceive the converstation as stilted >> or hear some artifact. > >I wanted to clarify that it isn't buffering itself that adds delay. >A packet could be buffered AND transmitted to the mobile node at the >same time, which then would show that buffering does not have to >introduce any delay. If a packet is received by the mobile node, >then presumably it would prefer not to receive the buffered copy of >that packet at any time in the future. > Well, I guess I agree, but what is the point of buffering if you are going to transmit it or of transmitting it if you are going to buffer it? The two options seem mutually exclusive to me. Am I missing something? jak From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 1 16:53: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 QAA04724 for ; Wed, 1 Aug 2001 16:53:09 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA18470; Wed, 1 Aug 2001 14:53:47 -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 NAA18403; Wed, 1 Aug 2001 13:53:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f71KqHr15094 for mobile-ip-dist; Wed, 1 Aug 2001 13:52:17 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f71KqDD15087 for ; Wed, 1 Aug 2001 13:52:13 -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 NAA17134 for ; Wed, 1 Aug 2001 13:52: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 NAA15070 for ; Wed, 1 Aug 2001 13:52: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 NAA15279 for ; Wed, 1 Aug 2001 13:52:25 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f71KqO720815 for ; Wed, 1 Aug 2001 13:52:24 -0700 X-mProtect: Wed, 1 Aug 2001 13:52:24 -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 smtpdHk6WQU; Wed, 01 Aug 2001 13:52:23 PDT Message-ID: <3B686C07.59D8548F@iprg.nokia.com> Date: Wed, 01 Aug 2001 13:52: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@sunroof.eng.sun.com Subject: Re: [mobile-ip] Authentication Data as a BU suboption 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 Henrik, > The BSAs should be deleted when MN deregisters, since the replay state for > MN is deleted then. It is likely that the existing mechanism for replay protection could be improved. For instance, we could specify an explicit field in the Binding Update option data for this purpose, and maybe that should be done in preference to relying merely on the Sequence Number field. Alternatively, we could continue to go with the Sequence Number field and just accept the possibility for more frequent rekeying. However, I get the sense that people will desire that rekeying be done every few days or weeks anyway, so maybe it's O.K. as is, even between mobile node and home agent. This means that a BSA could be retained as long as the sequence number could still protect against replays (i.e., the replay state would become part of the BSA and not be deleted). > If MN and HA have a preconfigured shared secret they > need some new mechanism of deriving session keys to use for authenticating > BUs and BAs. (If the same key is used for multiple sessions the replay > protection from sequence numbers is broken) Agreed, and this has been noted within the specification. It is an open question how adequate or inadequate the current proposed use of the sequence number might be. I am, myself, completely neutral on the issue, as with most of the current security issues. Regards, Charlie P. > > Henrik > > On Tue, 31 Jul 2001, 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. From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 1 16:54: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 QAA04750 for ; Wed, 1 Aug 2001 16:54: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 NAA03999; Wed, 1 Aug 2001 13:53:48 -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 NAA17684; Wed, 1 Aug 2001 13:50:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f71Knff14994 for mobile-ip-dist; Wed, 1 Aug 2001 13:49:42 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f71KnaD14969 for ; Wed, 1 Aug 2001 13:49:36 -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 NAA17273 for ; Wed, 1 Aug 2001 13:49:46 -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 NAA13745 for ; Wed, 1 Aug 2001 13:49:41 -0700 (PDT) Received: (qmail 11777 invoked by uid 500); 1 Aug 2001 20:38:44 -0000 Date: Wed, 1 Aug 2001 13:38:44 -0700 From: Pat Calhoun To: mobile-ip@sunroof.eng.sun.com Cc: Phillip Neumiller Subject: Re: [mobile-ip] Analysis of Latency Propagation with Buffering Message-ID: <20010801133844.A8990@charizard.diameter.org> References: <0DF9FBC42474A24CA50F7A27FB08E048445611@meshpdc.meshnetworks.com> <3B685B96.E0873655@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: <3B685B96.E0873655@iprg.nokia.com>; from charliep@iprg.nokia.com on Wed, Aug 01, 2001 at 12:42:14PM -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, Aug 01, 2001 at 12:42:14PM -0700, Charles E. Perkins wrote: > Hello Phil, > > If I order a pizza, and somebody brings me two, and > charges me twice, that's bad. > > If I get two for one for free, that's better, but from > the standpoint of the restaurateur it would be nice > if the government didn't tell him he HAD to serve me > two for one. Furthermore, if I'm tired of eating and > I still have to swallow the extra food, I might complain > even about the freebie. > > If, on the other hand, I can buy just the pizza I want, > and if I have to leave before I finish the meal but > later I can ask for the slices that are still hot, > that sounds about right to me. But chances are you'll end up with the remaining slices, which are now cold, and a new pizza that is warm as well. So, if a packet stays around in a buffer long enough (and we're not talking that long), the peer will most likely retransmit, and you'll end up with dups anyways. PatC From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 1 17:06: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 RAA05095 for ; Wed, 1 Aug 2001 17:06: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 OAA10363; Wed, 1 Aug 2001 14:06: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 OAA21356; Wed, 1 Aug 2001 14:03:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f71L2be15394 for mobile-ip-dist; Wed, 1 Aug 2001 14:02:37 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f71L2XD15378 for ; Wed, 1 Aug 2001 14:02: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 OAA19650; Wed, 1 Aug 2001 14:02:30 -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 PAA18724; Wed, 1 Aug 2001 15:03: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 OAA16402; Wed, 1 Aug 2001 14:02:23 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f71L2Me14263; Wed, 1 Aug 2001 14:02:22 -0700 X-mProtect: Wed, 1 Aug 2001 14:02:22 -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 smtpdFTS4Dt; Wed, 01 Aug 2001 14:02:20 PDT Message-ID: <3B686E5D.449BD717@iprg.nokia.com> Date: Wed, 01 Aug 2001 14:02:21 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Analysis of Latency Propagation with Buffering References: <200108012051.NAA14047@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 Jim, >> I wanted to clarify that it isn't buffering itself that adds delay. >> A packet could be buffered AND transmitted to the mobile node at the >> same time, which then would show that buffering does not have to >> introduce any delay. If a packet is received by the mobile node, >> then presumably it would prefer not to receive the buffered copy of >> that packet at any time in the future. > Well, I guess I agree, but what is the point of buffering if you > are going to transmit it or of transmitting it if you are going > to buffer it? The two options seem mutually exclusive to me. > Am I missing something? The point of buffering and simultaneously transmitting is that sometimes the mobile node might not be there to receive the transmitted packet -- say because it moved to a new access router. Then it would request the previous access router to send the buffered packets that it had not already received. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 1 17:14: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 RAA05281 for ; Wed, 1 Aug 2001 17:14: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 OAA14209; Wed, 1 Aug 2001 14:14: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 NAA20298; Wed, 1 Aug 2001 13:59:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f71KwnG15287 for mobile-ip-dist; Wed, 1 Aug 2001 13:58:49 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f71KwjD15280 for ; Wed, 1 Aug 2001 13:58: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 NAA19964; Wed, 1 Aug 2001 13:58:45 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA22239; Wed, 1 Aug 2001 14:58: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 NAA15946; Wed, 1 Aug 2001 13:58:42 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f71Kwgh03511; Wed, 1 Aug 2001 13:58:42 -0700 X-mProtect: Wed, 1 Aug 2001 13:58: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 smtpdlyEPxw; Wed, 01 Aug 2001 13:58:41 PDT Message-ID: <3B686D81.5ED716C1@iprg.nokia.com> Date: Wed, 01 Aug 2001 13:58:41 -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: Pat Calhoun CC: mobile-ip@sunroof.eng.sun.com, Phillip Neumiller Subject: Re: [mobile-ip] Analysis of Latency Propagation with Buffering References: <0DF9FBC42474A24CA50F7A27FB08E048445611@meshpdc.meshnetworks.com> <3B685B96.E0873655@iprg.nokia.com> <20010801133844.A8990@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, Pat Calhoun wrote: > > On Wed, Aug 01, 2001 at 12:42:14PM -0700, Charles E. Perkins wrote: > > Hello Phil, > > > > If I order a pizza, and somebody brings me two, and > > charges me twice, that's bad. > > > > If I get two for one for free, that's better, but from > > the standpoint of the restaurateur it would be nice > > if the government didn't tell him he HAD to serve me > > two for one. Furthermore, if I'm tired of eating and > > I still have to swallow the extra food, I might complain > > even about the freebie. > > > > If, on the other hand, I can buy just the pizza I want, > > and if I have to leave before I finish the meal but > > later I can ask for the slices that are still hot, > > that sounds about right to me. > > But chances are you'll end up with the remaining slices, which > are now cold, and a new pizza that is warm as well. > > So, if a packet stays around in a buffer long enough (and we're not > talking that long), the peer will most likely retransmit, and you'll > end up with dups anyways. This is a matter for managing the probabilities for such occurrences, and when it gets to that point the analogy cannot help any more. But simulation and prototype indicate that the necessary data (slices of pizza) can be consumed in enough time to help with voice. And it can be done in a way to avoid dups entirely. I thought the analogy would be useful for illustrating points about resource consumption and so on, but not for evaluating probabilities or other engineering parameters. Just to be clear, I am not categorically against bicasting, but I think it's true realm of applicability is not large enough to be mandated as part of fast handover protocol, and that there may often be more economical approaches available. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 1 17:16: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 RAA05395 for ; Wed, 1 Aug 2001 17:16: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 PAA06066; Wed, 1 Aug 2001 15:16: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 OAA24196; Wed, 1 Aug 2001 14:16:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f71LElc15538 for mobile-ip-dist; Wed, 1 Aug 2001 14:14:47 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f71LEcD15528 for ; Wed, 1 Aug 2001 14:14:39 -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 OAA22895; Wed, 1 Aug 2001 14:14:47 -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 OAA29567; Wed, 1 Aug 2001 14:21:34 -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 NAA11929; Wed, 1 Aug 2001 13:17:40 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f71KHdS20547; Wed, 1 Aug 2001 13:17:39 -0700 X-mProtect: Wed, 1 Aug 2001 13:17:39 -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 smtpdD1tRiY; Wed, 01 Aug 2001 13:17:37 PDT Message-ID: <3B6863E2.3FC2B867@iprg.nokia.com> Date: Wed, 01 Aug 2001 13:17:38 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Erik Nordmark CC: mobile-ip@sunroof.eng.sun.com, Jari Arkko , Jean-Michel COMBES Subject: Re: [mobile-ip] Concern over draft-team-mobileip-mipv6-sec-reqts-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 Hello Erik, I thought that we were going to have to devise a way for all IPv6 nodes to get security associations with mobile nodes. Isn't IKE too much to ask from every IPv6 node? And, yet, I agree that we should have a way to use IKE to get keys that would be useful for authenticating Binding Updates. I just expected it wouldn't be the universally mandated way. Regards, Charlie P. Erik Nordmark wrote: > > > Therefore, we are free to choose between > > MIP-specific BU protection and IPsec AH independent of how > > the key management is solved. > > You are assuming that it is easy to use IKE to create non-IPsec keys e.g. > for MIP specific BU protection. > Are you sure it is that easy? > (I don't have any data - but I thought IKE was tied to IPsec.) > > Erik From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 1 17:26: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 RAA05661 for ; Wed, 1 Aug 2001 17:26: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 OAA19568; Wed, 1 Aug 2001 14:26: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 OAA24840; Wed, 1 Aug 2001 14:18:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f71LHkV15586 for mobile-ip-dist; Wed, 1 Aug 2001 14:17: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+Sun/8.11.5) with ESMTP id f71LHgD15577 for ; Wed, 1 Aug 2001 14:17: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 OAA15567; Wed, 1 Aug 2001 14:17:52 -0700 (PDT) Message-Id: <200108012117.OAA15567@heliopolis.eng.sun.com> Date: Wed, 1 Aug 2001 14:17:45 -0700 (PDT) From: James Kempf Subject: Re: [mobile-ip] Analysis of Latency Propagation with Buffering To: James.Kempf@Sun.COM, charliep@iprg.nokia.com Cc: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: WfAJBC7u9mJNnOBSjWagPw== 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 Charlie, > >>> I wanted to clarify that it isn't buffering itself that adds delay. >>> A packet could be buffered AND transmitted to the mobile node at the >>> same time, which then would show that buffering does not have to >>> introduce any delay. If a packet is received by the mobile node, >>> then presumably it would prefer not to receive the buffered copy of >>> that packet at any time in the future. > >> Well, I guess I agree, but what is the point of buffering if you >> are going to transmit it or of transmitting it if you are going >> to buffer it? The two options seem mutually exclusive to me. >> Am I missing something? > >The point of buffering and simultaneously transmitting is that >sometimes the mobile node might not be there to receive the transmitted >packet -- say because it moved to a new access router. Then it would >request the previous access router to send the buffered packets that >it had not already received. > OK, now I understand. I suggested something like this, but with the new AR doing the buffering, in Appendix B of the BETH draft. jak From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 1 17:49: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 RAA06328 for ; Wed, 1 Aug 2001 17:49: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 OAA29925; Wed, 1 Aug 2001 14:49:20 -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 OAA29906; Wed, 1 Aug 2001 14:44:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f71LZVf15780 for mobile-ip-dist; Wed, 1 Aug 2001 14:35:31 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f71LZQD15773 for ; Wed, 1 Aug 2001 14:35:26 -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 OAA27690 for ; Wed, 1 Aug 2001 14:35:39 -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 PAA18880 for ; Wed, 1 Aug 2001 15:35:33 -0600 (MDT) Received: (qmail 12513 invoked by uid 500); 1 Aug 2001 21:24:38 -0000 Date: Wed, 1 Aug 2001 14:24:37 -0700 From: Pat Calhoun To: mobile-ip@sunroof.eng.sun.com Cc: James.Kempf@Sun.COM, charliep@iprg.nokia.com Subject: Re: [mobile-ip] Analysis of Latency Propagation with Buffering Message-ID: <20010801142437.I8990@charizard.diameter.org> References: <200108012117.OAA15567@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: <200108012117.OAA15567@heliopolis.eng.sun.com>; from James.Kempf@Sun.COM on Wed, Aug 01, 2001 at 02:17: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: On Wed, Aug 01, 2001 at 02:17:45PM -0700, James Kempf wrote: > Hi Charlie, > > > > >>> I wanted to clarify that it isn't buffering itself that adds delay. > >>> A packet could be buffered AND transmitted to the mobile node at the > >>> same time, which then would show that buffering does not have to > >>> introduce any delay. If a packet is received by the mobile node, > >>> then presumably it would prefer not to receive the buffered copy of > >>> that packet at any time in the future. > > > >> Well, I guess I agree, but what is the point of buffering if you > >> are going to transmit it or of transmitting it if you are going > >> to buffer it? The two options seem mutually exclusive to me. > >> Am I missing something? > > > >The point of buffering and simultaneously transmitting is that > >sometimes the mobile node might not be there to receive the transmitted > >packet -- say because it moved to a new access router. Then it would > >request the previous access router to send the buffered packets that > >it had not already received. > > > > OK, now I understand. I suggested something like this, but with > the new AR doing the buffering, in Appendix B of the BETH draft. in which case the mobile doesn't have to request the packets, since opening the L2 would cause buffered packets to be released to the mobile node. PatC From glass@jurassic.eng.sun.com Wed Aug 1 17:55: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 RAA06501 for ; Wed, 1 Aug 2001 17:55:09 -0400 (EDT) Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA03031 for ; Wed, 1 Aug 2001 14:56:09 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.85.31]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id OAA02658; Wed, 1 Aug 2001 14:58:07 -0700 (PDT) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by jurassic.eng.sun.com (8.11.5+Sun/8.11.5) with SMTP id f71Lu4b347613; Wed, 1 Aug 2001 14:56:04 -0700 (PDT) Message-Id: <200108012156.f71Lu4b347613@jurassic.eng.sun.com> Date: Wed, 1 Aug 2001 17:56:30 -0400 (EDT) From: Steven Glass - Solaris Software Reply-To: Steven Glass - Solaris Software Subject: [mobile-ip] Test plan X, please ignore. To: nobody@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 I'm testing the mobile-ip list, please ignore. Cheers, Steve From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 1 18:29: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 SAA07710 for ; Wed, 1 Aug 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 PAA16481; Wed, 1 Aug 2001 15:29: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 PAA09867; Wed, 1 Aug 2001 15:26:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f71MKbQ15894 for mobile-ip-dist; Wed, 1 Aug 2001 15:20:38 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f71MKYD15887 for ; Wed, 1 Aug 2001 15:20:34 -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 PAA13495 for ; Wed, 1 Aug 2001 15:20:49 -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 QAA25467 for ; Wed, 1 Aug 2001 16:20:47 -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 f71ML1Y28822; Wed, 1 Aug 2001 15:21: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 ABM02004; Wed, 1 Aug 2001 15:20:47 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA13050; Wed, 1 Aug 2001 15:20:46 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15208.32958.818374.455399@thomasm-u1.cisco.com> Date: Wed, 1 Aug 2001 15:20:46 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Cc: "Thomas Narten" Subject: Re: [mobile-ip] on using IPsec to secure Binding Updates In-Reply-To: <00cc01c11a00$3bee9c20$8a1b6e0a@arenanet.fi> References: <200107311720.NAA12323@rotala.raleigh.ibm.com> <00cc01c11a00$3bee9c20$8a1b6e0a@arenanet.fi> 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: > 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? While I agree that they are orthogonal problems, without well defined mechanisms for key distribution -- especially considering the scaling implications of small/cheap mobile devices -- key distribution is likely to be the real problem with actual deployment. Retaining standards based key distribution mechanisms with some deployment track record is the safest and quickest way to deployment that I can see. And I'm hardly what you'd call an IKE evangelist (are there such creatures? :-) > 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? My interpretation of the IESG's general position is that if strong authentication is pragmatic (with fairly high standards for what is not pragmatic), it must be provided for by the protocol in order to advance. For MIP, it's a mixed bag: in some cases it's possible (MN/HA) and in some cases it's not pragmatic (random MN/CN). Given that, it seems that we need to provide for both options. I'll add that the MIP working group is not the only one to feel the heat because of this general requirement, much to the chagrin of many working group chairs. Mike From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 2 00: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 AAA22286 for ; Thu, 2 Aug 2001 00:22: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 WAA20687; Wed, 1 Aug 2001 22:22: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 VAA04987; Wed, 1 Aug 2001 21:22:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f724Krx16496 for mobile-ip-dist; Wed, 1 Aug 2001 21:20:53 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f724KmD16489 for ; Wed, 1 Aug 2001 21:20: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 VAA04858 for ; Wed, 1 Aug 2001 21:21:02 -0700 (PDT) Received: from fep01-app.kolumbus.fi (fep01-0.kolumbus.fi [193.229.0.41]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA16190 for ; Wed, 1 Aug 2001 21:21:01 -0700 (PDT) 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 <20010802042059.LDO18748.fep01-app.kolumbus.fi@jariws1>; Thu, 2 Aug 2001 07:20:59 +0300 Message-ID: <00e001c11b0a$84387540$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: , "Michael Thomas" Cc: "'Vijay Devarapalli '" References: <034BEFD03799D411A59F00508BDF754603008B9B@esealnt448.al.sw.ericsson.se> <15208.27503.450299.135095@thomasm-u1.cisco.com> Subject: Re: [mobile-ip] Concern over draft-team-mobileip-mipv6-sec-reqts-00.txt Date: Thu, 2 Aug 2001 07:20:52 +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 > > 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. > > > > => The Home address destination option is not > > relevant here. The BU is. These are 2 separate > > options so you don't need to apply the AH to > > every packet. > > I'm pretty sure that Vijay is correct here. IPsec selectors > do not define a standard way to use the port numbers in > the ID payload to select for different destination options. > This is probably not that hard to define, but it's not > standard now. It has earlier already been discussed that if a _new next header number_ is allocated for the BU then there is no issue, and current standard can be used. Jari From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 2 00:36: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 AAA23336 for ; Thu, 2 Aug 2001 00:36: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 WAA25979; Wed, 1 Aug 2001 22:36: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 VAA06865; Wed, 1 Aug 2001 21:36:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f724ZQG16573 for mobile-ip-dist; Wed, 1 Aug 2001 21:35:26 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f724ZLD16566 for ; Wed, 1 Aug 2001 21:35: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 VAA06758 for ; Wed, 1 Aug 2001 21:35:35 -0700 (PDT) Received: from fep01-app.kolumbus.fi (fep01-0.kolumbus.fi [193.229.0.41]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA25202 for ; Wed, 1 Aug 2001 21:35:34 -0700 (PDT) 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 <20010802043534.NEA18748.fep01-app.kolumbus.fi@jariws1>; Thu, 2 Aug 2001 07:35:34 +0300 Message-ID: <00ee01c11b0c$8db52120$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Erik Nordmark" , "Charles E. Perkins" Cc: References: Subject: Re: [mobile-ip] Concern over draft-team-mobileip-mipv6-sec-reqts-00.txt Date: Thu, 2 Aug 2001 07:35:27 +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 Charlie, Erik, Erik you wrote this: > > Therefore, we are free to choose between > > MIP-specific BU protection and IPsec AH independent of how > > the key management is solved. > > You are assuming that it is easy to use IKE to create non-IPsec keys e.g. > for MIP specific BU protection. > Are you sure it is that easy? > (I don't have any data - but I thought IKE was tied to IPsec.) I'm trying to make the point here that the BU protection and key management can be solved in an independent manner. I wasn't actually thinking that IKE be used to create MIP-specific SAs. That would also be possible, though it involves some more work. Instead, I think a much more fruitful approach would be the following: - CN, MN, and HA nodes implement AH protection for BUs in the manner discussed before in this thread i.e. no piggybacking and a new next header number. Current IPsec suffices for this. - CN and MN nodes implement BAKE - or something similar - in order to generate keys without a global PKI. BAKE provides keys for AH i.e. creates IPsec SAs. We do need to complete BAKE in this WG, but I don't think it'll make a difference whether it keys IPsec SAs or other kinds of SAs. - Optionally, some nodes may implement IKE in order to use it for VPNs or for the protection of BUs through a corporate PKI. Of course IKE will also be creating keys for IPsec SAs. Jari From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 2 01:05: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 BAA24054 for ; Thu, 2 Aug 2001 01:05: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 XAA05823; Wed, 1 Aug 2001 23:05:51 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA09868; Wed, 1 Aug 2001 22:05:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7254d016657 for mobile-ip-dist; Wed, 1 Aug 2001 22:04:39 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7254aD16650 for ; Wed, 1 Aug 2001 22:04:36 -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 WAA06349 for ; Wed, 1 Aug 2001 22:04:50 -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 WAA29294 for ; Wed, 1 Aug 2001 22:04:37 -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 f7254Si04340 for ; Thu, 2 Aug 2001 00:04:40 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Thu, 2 Aug 2001 00:04:24 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.1600); Thu, 2 Aug 2001 00:04:24 -0500 content-class: urn:content-classes:message Subject: RE: [mobile-ip] Concern over draft-team-mobileip-mipv6-sec-reqts-00.txt Date: Thu, 2 Aug 2001 00:04:23 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF44086184@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: AcEbDOQ/88tCgob7EdWrxAAIx6S5QwAAopsA To: Cc: X-OriginalArrivalTime: 02 Aug 2001 05:04:24.0257 (UTC) FILETIME=[98F2F310:01C11B10] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f7254aD16651 Sender: owner-mobile-ip@sunroof.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'm trying to make the point here that the BU protection and key >management can be solved in an independent manner. I wasn't >actually thinking that IKE be used to create MIP-specific SAs. >That would also be possible, though it involves some more work. > >Instead, I think a much more fruitful approach would be the following: > >- CN, MN, and HA nodes implement AH protection for BUs in the manner > discussed before in this thread i.e. no piggybacking and a new > next header number. Current IPsec suffices for this. > If you have a new next header number, would you still need to avoid piggybacking? (Maybe I should go read this really long thread and find the answer...) One of the things that has been raised as a concern is the scalability of IPSec SAs in CNs (such as web servers) which may be serving a large number of MNs. Can today's IPSec implementations handle a very large number of SAs in the SAD (in the tens of thousands)? >- CN and MN nodes implement BAKE - or something similar - > in order to generate keys without a global PKI. BAKE provides > keys for AH i.e. creates IPsec SAs. We do need to complete > BAKE in this WG, but I don't think it'll make a difference whether > it keys IPsec SAs or other kinds of SAs. > Good. Relying on IPSec SAs as the only types of SAs may be a limiting factor. >- Optionally, some nodes may implement IKE in order to > use it for VPNs or for the protection of BUs through a > corporate PKI. Of course IKE will also be creating > keys for IPsec SAs. > >Jari > -Basavaraj From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 2 03:56: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 DAA15747 for ; Thu, 2 Aug 2001 03:56: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 AAA02197; Thu, 2 Aug 2001 00:57:15 -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 AAA13366; Thu, 2 Aug 2001 00:56:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f727t9A17082 for mobile-ip-dist; Thu, 2 Aug 2001 00:55:09 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f727t5D17075 for ; Thu, 2 Aug 2001 00:55: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 AAA28227 for ; Thu, 2 Aug 2001 00:55:19 -0700 (PDT) Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA14731; Thu, 2 Aug 2001 01:55:16 -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 f727qPX21538; Thu, 2 Aug 2001 09:52:26 +0200 (MEST) Message-ID: <3B690704.F5D908E8@inrialpes.fr> Date: Thu, 02 Aug 2001 09:53:40 +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 CC: Lars Henrik Petander , erik.nordmark@sun.com Subject: Re: [mobile-ip] Concern over draft-team-mobileip-mipv6-sec-reqts-00.txt References: Content-Type: multipart/alternative; boundary="------------41C1A1EAB5539F92C0CC4C4F" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --------------41C1A1EAB5539F92C0CC4C4F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Erik, Actually SUCVp (the SUCV protocol) described in http://www.inrialpes.fr/planete/people/ccastel/draft-montenegro-sucv-01.txt considers the DoS issues you've pointed out... The protocol works as follows: - the MN sends a msg1 (basically a BU-Hello request) to the CN - the CN replies with a msg2 (that contains a cookie ...or more precisely a client puzzle). This msg is sent through the home agent... - the MN then has to reply with a msg3 that contains the cookie or the puzzle reply... - The CN will then only perform the SUCV verification + DH exponentiation (to derive a SKey) if the cookie or the puzzle reply is correct... The draft actually contains a fully detailled security analysis of the protocol...we believe it is pretty complete... Unfortunatly we did not get a slot to present it in London ...but we will both (Gabriel Montenegro and myself) be in London and will be very happy to discuss with anybody interested in this work... regards, Claude. Erik Nordmark wrote: > > The use of return routability as a proof of address ownersip has some > > limitations, especially on nonswitched broadcast links. > > Agreed. My intent was just to have return routability as an example > of a weaker mechanism. Sorry for not making that clear. > > > SUCV and CAM both provide a lightweight solution to the problem of address > > ownership, by cryptographically binding the home address to the public key > > of MN. This could be used in combination with almost any protocol, which > > uses public key cryptograhy, to verify cryptograhically that MN really > > "owns" its home address. > > While I'm not up on the latest draft I suspect that there can be DoS > issues. For instance, invoking public key crypto operations to verify > the binding between a SUCV address and a key, when a random packet is > received might be asking for DoS attacks. This can be avoided by in > effect doing a return routability checking handshake before invoking > the public key operations. > > Erik -- ---------------------------------------- Claude CASTELLUCCIA, INRIA Rhone-Alpes ph: +33 4.76.61.52.15 (fax: 52.52) http://www.inrialpes.fr/planete/ --------------41C1A1EAB5539F92C0CC4C4F Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  
Hello Erik,

Actually SUCVp (the SUCV protocol) described in
http://www.inrialpes.fr/planete/people/ccastel/draft-montenegro-sucv-01.txt
considers the DoS issues you've pointed out...

The protocol works as follows:
- the MN sends a msg1 (basically a BU-Hello request) to the CN
- the CN replies with a msg2 (that contains a cookie ...or more precisely a client puzzle). This msg is sent through the home agent...
- the MN then has to reply with a msg3 that contains the cookie or the puzzle reply...
- The CN will then only perform the SUCV verification + DH exponentiation (to derive a SKey) if the cookie or the puzzle reply is correct...

The draft actually contains a fully detailled security analysis of the protocol...we believe it is pretty complete...
Unfortunatly we  did not get a slot to present it in London ...but we will both (Gabriel Montenegro and myself) be in London and will
be very happy to discuss with anybody interested in this work...
 

regards,

Claude.
 
 

Erik Nordmark wrote:

> The use of return routability as a proof of address ownersip has some
> limitations, especially on nonswitched broadcast links.

Agreed. My intent was just to have return routability as an example
of a weaker mechanism. Sorry for not making that clear.

> SUCV and CAM both provide a lightweight solution to the problem of address
> ownership, by cryptographically binding the home address to the public key
> of MN. This could be used in combination with almost any protocol, which
> uses public key cryptograhy, to verify cryptograhically that MN really
> "owns" its home address.

While I'm not up on the latest draft I suspect that there can be DoS
issues. For instance, invoking public key crypto operations to verify
the binding between a SUCV address and a key, when a random packet is
received might be asking for DoS attacks. This can be avoided by in
effect doing a return routability checking handshake before invoking
the public key operations.

   Erik

-- 

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes  
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/
  --------------41C1A1EAB5539F92C0CC4C4F-- From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 2 04:23: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 EAA16532 for ; Thu, 2 Aug 2001 04:23: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 BAA09808; Thu, 2 Aug 2001 01:24: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 BAA16686; Thu, 2 Aug 2001 01:22:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f728LEr17175 for mobile-ip-dist; Thu, 2 Aug 2001 01:21:14 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f728LAD17168 for ; Thu, 2 Aug 2001 01:21:10 -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 BAA01246 for ; Thu, 2 Aug 2001 01:21:24 -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 CAA27240 for ; Thu, 2 Aug 2001 02:22:57 -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 f728IVX22160 for ; Thu, 2 Aug 2001 10:18:31 +0200 (MEST) Message-ID: <3B690D50.458B7F35@inrialpes.fr> Date: Thu, 02 Aug 2001 10:20:32 +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] Concern over draft-team-mobileip-mipv6-sec-reqts-00.txt References: Content-Type: multipart/alternative; boundary="------------4DB4186B188D34548120DC85" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --------------4DB4186B188D34548120DC85 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lars Henrik Petander wrote: > On Wed, 1 Aug 2001, Erik Nordmark wrote: > > > > JMC : I'm happy to hear this !!! I think this is the cheapest and best > > > solution. I would be afraid to have to pay a high cost to secure MIPv6 > > > while by changing just two little things (ie. BU "nxt header" value and > > > "no piggybacking"), we could use existing tools ... > > > > Jean-Michel, > > > > That would solve part of the outstanding issues. > > But with just those changes you would still need a PKI that includes > > both the MN and the CN in order to use route optimization. > > It is my understanding that folks one to use route optimizations even when > > a PKI with such scope is not available. > > (If I'm mistaken about this requirement it would be good to straighten me out.) > > Thus there is a need for something somewhat weaker than a PKI in order > > to allow route optimization in those cases. There are several proposals > > that somehow use "return routability" as the criteria for such a weaker > > scheme. > > The use of return routability as a proof of address ownersip has some > limitations, especially on nonswitched broadcast links. > > SUCV and CAM both provide a lightweight solution to the problem of address > ownership, by cryptographically binding the home address to the public key > of MN. This could be used in combination with almost any protocol, which > uses public key cryptograhy, to verify cryptograhically that MN really > "owns" its home address. > > IMHO use of a SUCV is a lot more secure than using return routability. > Also as there is no dependence on a trusted third party, the protocol > should scale well. > Hello Henrik... I of course agree with you ;-) SUCV does not rely on any trusted third party and scales very well... SUCVp also uses return routability but not as a proof of address ownership but rather to avoid some DoS attacks as described in the draft... BTW SUCVp can also be used to prove the CoA address owernship... this is very usefull to avoid address stealing and some DoS attacks (see .http://www.inrialpes.fr/planete/people/ccastel/draft-montenegro-sucv-01.txt for more details). regards, Claude. > > Henrik Petander -- ---------------------------------------- Claude CASTELLUCCIA, INRIA Rhone-Alpes ph: +33 4.76.61.52.15 (fax: 52.52) http://www.inrialpes.fr/planete/ --------------4DB4186B188D34548120DC85 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Lars Henrik Petander wrote:
On Wed, 1 Aug 2001, Erik Nordmark wrote:

> > JMC : I'm happy to hear this !!! I think this is the cheapest and best
> > solution. I would be afraid to have to pay a high cost to secure MIPv6
> > while by changing just two little things (ie. BU "nxt header" value and
> > "no piggybacking"), we could use existing tools ...
>
> Jean-Michel,
>
> That would solve part of the outstanding issues.
> But with just those changes you would still need a PKI that includes
> both the MN and the CN in order to use route optimization.
> It is my understanding that folks one to use route optimizations even when
> a PKI with such scope is not available.
> (If I'm mistaken about this requirement it would be good to straighten me out.)
>  Thus there is a need for something somewhat weaker than a PKI in order
> to allow route optimization in those cases. There are several proposals
> that somehow use "return routability" as the criteria for such a weaker
> scheme.

The use of return routability as a proof of address ownersip has some
limitations, especially on nonswitched broadcast links.

SUCV and CAM both provide a lightweight solution to the problem of address
ownership, by cryptographically binding the home address to the public key
of MN. This could be used in combination with almost any protocol, which
uses public key cryptograhy, to verify cryptograhically that MN really
"owns" its home address.

IMHO use of a SUCV is a lot more secure than using return routability.
Also as there is no dependence on a trusted third party, the protocol
should scale well.
 


Hello Henrik...

I of course agree with you ;-)
SUCV does not rely on any trusted third party and scales very well...

SUCVp also uses return routability but not as a proof of address ownership but
rather to avoid some DoS attacks as described in the draft...

BTW SUCVp can also be used to prove the CoA address owernship... this is very usefull to
avoid address stealing and some DoS attacks (see .http://www.inrialpes.fr/planete/people/ccastel/draft-montenegro-sucv-01.txt
for more details).

regards,
Claude.
 
 
 
 

 
Henrik Petander
-- 

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes  
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/
  --------------4DB4186B188D34548120DC85-- From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 2 04:44: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 EAA17165 for ; Thu, 2 Aug 2001 04:44: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 CAA08317; Thu, 2 Aug 2001 02:45: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 BAA00387; Thu, 2 Aug 2001 01:44:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f728htY17282 for mobile-ip-dist; Thu, 2 Aug 2001 01:43:55 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f728hqD17275 for ; Thu, 2 Aug 2001 01:43:52 -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 BAA18684 for ; Thu, 2 Aug 2001 01:44:06 -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 CAA07691 for ; Thu, 2 Aug 2001 02:45:38 -0600 (MDT) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Thu, 2 Aug 2001 04:44:04 -0400 Message-ID: <8C92E23A3E87FB479988285F9E22BE460546F3@ftmail> From: George Tsirtsis To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Analysis of Latency Propagation with Buffering Date: Thu, 2 Aug 2001 04:44: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: Pat Calhoun [mailto:pcalhoun@diameter.org] Sent: Wednesday, August 01, 2001 10:25 PM To: mobile-ip@sunroof.eng.sun.com Cc: James.Kempf@Sun.COM; charliep@iprg.nokia.com Subject: Re: [mobile-ip] Analysis of Latency Propagation with Buffering On Wed, Aug 01, 2001 at 02:17:45PM -0700, James Kempf wrote: > Hi Charlie, > > > > >>> I wanted to clarify that it isn't buffering itself that adds delay. > >>> A packet could be buffered AND transmitted to the mobile node at the > >>> same time, which then would show that buffering does not have to > >>> introduce any delay. If a packet is received by the mobile node, > >>> then presumably it would prefer not to receive the buffered copy of > >>> that packet at any time in the future. > > > >> Well, I guess I agree, but what is the point of buffering if you > >> are going to transmit it or of transmitting it if you are going > >> to buffer it? The two options seem mutually exclusive to me. > >> Am I missing something? > > > >The point of buffering and simultaneously transmitting is that > >sometimes the mobile node might not be there to receive the transmitted > >packet -- say because it moved to a new access router. Then it would > >request the previous access router to send the buffered packets that > >it had not already received. > > > > OK, now I understand. I suggested something like this, but with > the new AR doing the buffering, in Appendix B of the BETH draft. in which case the mobile doesn't have to request the packets, since opening the L2 would cause buffered packets to be released to the mobile node. GT> I guess that works when the oldAR knows which packets were received by the MN before the link went down...any remaining packets can now be forwarded to the newAR and by the time the MN connects to it the packets will be ready for delivery ...without requests or duplications...sounds good to me too. George From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 2 05:12: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 FAA17760 for ; Thu, 2 Aug 2001 05:12: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 CAA23078; Thu, 2 Aug 2001 02:12: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 CAA05334; Thu, 2 Aug 2001 02:11:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f729Arp17452 for mobile-ip-dist; Thu, 2 Aug 2001 02:10:53 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f729AoD17445 for ; Thu, 2 Aug 2001 02:10:50 -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 CAA05291 for ; Thu, 2 Aug 2001 02:11:04 -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 DAA20185 for ; Thu, 2 Aug 2001 03:10:57 -0600 (MDT) Received: from cychong (a22416 [165.213.224.16]) by telecom.samsung.co.kr (8.9.3/8.9.3) with SMTP id SAA23798 for ; Thu, 2 Aug 2001 18:13:32 +0900 (KST) Message-ID: <002d01c11b33$82e98a70$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> <20010728163959.B24014@charizard.diameter.org> Subject: Re: [mobile-ip] I-D ACTION:draft-ietf-mobileip-aaa-key-08.txt Date: Thu, 2 Aug 2001 18:14:18 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.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 f729AoD17446 Sender: owner-mobile-ip@sunroof.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. ----- Original Message ----- From: "Pat Calhoun" To: Sent: Sunday, July 29, 2001 8:40 AM Subject: Re: [mobile-ip] I-D ACTION:draft-ietf-mobileip-aaa-key-08.txt > > 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. > I think you agreed that your draft is not a complete solution in RADIUS based architecture because some other security association must be present betwen FA and HA. Right? If so, someone want to use your draft in RADIUS based architecture and they want not to use IPSec like secuirty protocol betwen FA and HA, then it is vulnerable to the DoS attack not because of the security hole of your draft but because of the that of RADIUS. They should have mandate FA-HA authentication extension in this case, I think. > Thanks, > > PatC > Thanks Chae-yong From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 2 07:55: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 HAA23306 for ; Thu, 2 Aug 2001 07:55: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 EAA03855; Thu, 2 Aug 2001 04:56: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 EAA14908; Thu, 2 Aug 2001 04:55:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f72BsLa18102 for mobile-ip-dist; Thu, 2 Aug 2001 04:54:21 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f72BsHD18095 for ; Thu, 2 Aug 2001 04:54: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 EAA17052 for ; Thu, 2 Aug 2001 04:54:18 -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 EAA22565 for ; Thu, 2 Aug 2001 04:54:16 -0700 (PDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f72BsFN05294; Thu, 2 Aug 2001 13:54:15 +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 f72BsF506964; Thu, 2 Aug 2001 14:54:15 +0300 (EET DST) Message-ID: <3B693F67.F733DF16@lmf.ericsson.se> Date: Thu, 02 Aug 2001 14:54:15 +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: Basavaraj.Patil@nokia.com CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Concern over draft-team-mobileip-mipv6-sec-reqts-00.txt References: <697DAA22C5004B4596E033803A7CEF44086184@daebe007.NOE.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 >If you have a new next header number, would you >still need to avoid piggybacking? (Maybe I should >go read this really long thread and find the answer...) It is indeed a long thread! I think the answer is that piggybacking would still have to be avoided. Both in terms of firewalls and ipsec policies the current limitation is that usually just one level of protocols can be matched against. The remaining part of the packet beyond the BU might include something that needs other special security treatment. Again, this is an limitation that could relatively easily be removed, but in this discussion we were trying to see how BUs must look like if current IPsec is used. >One of the things that has been raised as a concern >is the scalability of IPSec SAs in CNs (such as web >servers) which may be serving a large number of MNs. >Can today's IPSec implementations handle a very large >number of SAs in the SAD (in the tens of thousands)? The scalability issues certainly deserve some thought. There are IPsec implementations that can handle large number of SAs. There are also implementations that handle only a few. If you are out of luck, it's on your web server OS ;-) Seriously though, there are three separate issues, the SAs themselves, their use, and then the policy databases. Let's discuss the SA database first. This is in the order of a few hundred bytes in typical implementations and essentially contains the necessary cryptographic contexts, plus a small number of other smaller fields. Any SA, IPsec or other, requires similar amounts of memory. So here it is hard for me to see an issue. Naturally there might be hard computing power limits on how much you can actually use the SAs. These should also be roughly similar in any of the alternatives we are discussing. It is perhaps possible that on some busy servers this load exceeds the capabilities of the hardware. It is likely that server manufacturers would like to add a feature that enables the box to age BUs faster and/or refuse BAKE and optimized routing if the load of the box grows too high. Finally, the policy databases that contain the filters to match packets. These need both memory, and execution time for each packet. Typical implementations would perhaps use a similar amount of space for a policy entry as they do for an SA. On a MIP-specific solution, we don't need this as the policy is in a way hardcoded to the processing of the BUs. However, assuming your box doesn't want to support IPsec in general and only wants to support BU protection, it is easy to optimize this by e.g. starting the policy matching only in the BU processing. Jari From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 2 08:54: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 IAA25244 for ; Thu, 2 Aug 2001 08:54: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 FAA21156; Thu, 2 Aug 2001 05:54: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 FAA19893; Thu, 2 Aug 2001 05:54:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f72CrUL18443 for mobile-ip-dist; Thu, 2 Aug 2001 05:53:30 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f72CrRD18436 for ; Thu, 2 Aug 2001 05:53:27 -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 FAA24766 for ; Thu, 2 Aug 2001 05:53: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 GAA29288 for ; Thu, 2 Aug 2001 06:53:21 -0600 (MDT) Received: by p-voyageur.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19) id ; Thu, 2 Aug 2001 14:52:49 +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 QADMN4QM; Thu, 2 Aug 2001 14:52:47 +0200 Message-ID: <3B694CEE.F86F57D@francetelecom.com> Date: Thu, 02 Aug 2001 14:51:58 +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] Concern over draft-team-mobileip-mipv6-sec-reqts-00.txt References: 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 FAA21156 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA25244 Hi Erik, Erik Nordmark a écrit : > > JMC : I'm happy to hear this !!! I think this is the cheapest and best > > solution. I would be afraid to have to pay a high cost to secure MIPv6 > > while by changing just two little things (ie. BU "nxt header" value and > > "no piggybacking"), we could use existing tools ... > > Jean-Michel, > > That would solve part of the outstanding issues. > But with just those changes you would still need a PKI that includes > both the MN and the CN in order to use route optimization. > It is my understanding that folks one to use route optimizations even when > a PKI with such scope is not available. > (If I'm mistaken about this requirement it would be good to straighten me out.) > Thus there is a need for something somewhat weaker than a PKI in order > to allow route optimization in those cases. There are several proposals > that somehow use "return routability" as the criteria for such a weaker > scheme. JMC : I totally agree with you. I just want to avoid that PKI-IPsec solution will be rejected. Today, some people speak about problem of PKI scalability but just one point : there are more PKI than MIPv6 Mobile in the world :-)) Regards. JMC. > > > Erik -- 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 Thu Aug 2 08:58: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 IAA25482 for ; Thu, 2 Aug 2001 08:58: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 GAA02720; Thu, 2 Aug 2001 06:59:03 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA20256; Thu, 2 Aug 2001 05:58:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f72Cvsd18485 for mobile-ip-dist; Thu, 2 Aug 2001 05:57:54 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f72CvoD18478 for ; Thu, 2 Aug 2001 05:57: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 FAA22164 for ; Thu, 2 Aug 2001 05:57:52 -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 GAA02069 for ; Thu, 2 Aug 2001 06:57:49 -0600 (MDT) Received: by p-voyageur.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19) id ; Thu, 2 Aug 2001 14:56:46 +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 QADMN4RS; Thu, 2 Aug 2001 14:56:43 +0200 Message-ID: <3B694DDB.F42C3BC8@francetelecom.com> Date: Thu, 02 Aug 2001 14:55:55 +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] Concern over draft-team-mobileip-mipv6-sec-reqts-00.txt References: <3B680774.48FD39@francetelecom.com> <15208.11951.979665.294736@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 GAA02720 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA25482 Hi Mike, Michael Thomas a écrit : > Erik Nordmark writes: > > > JMC : I'm happy to hear this !!! I think this is the cheapest and best > > > solution. I would be afraid to have to pay a high cost to secure MIPv6 > > > while by changing just two little things (ie. BU "nxt header" value and > > > "no piggybacking"), we could use existing tools ... > > > > Jean-Michel, > > > > That would solve part of the outstanding issues. > > But with just those changes you would still need a PKI that includes > > both the MN and the CN in order to use route optimization. > > It is my understanding that folks one to use route optimizations even when > > a PKI with such scope is not available. > > (If I'm mistaken about this requirement it would be good to straighten me out.) > > Thus there is a need for something somewhat weaker than a PKI in order > > to allow route optimization in those cases. There are several proposals > > that somehow use "return routability" as the criteria for such a weaker > > scheme. > > No, you are exactly right. There are two things that need to > done: > > 1) Provide a strong authentication solution where it is > pragmatically possible JMC : that are the right words : strong authentication when possible > > 2) Provide a weak authentication solution where it is > pragmatically impossible. JMC : agree too Regards. JMC. > > > We have been talking almost exclusively about (1) recently, > though that doesn't mean that (2) is uninteresting. It's > day will come too, I expect. > > 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 Thu Aug 2 09:25: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 JAA26336 for ; Thu, 2 Aug 2001 09:25: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 GAA02077; Thu, 2 Aug 2001 06:25: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 GAA22984; Thu, 2 Aug 2001 06:25:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f72DO5218682 for mobile-ip-dist; Thu, 2 Aug 2001 06:24:05 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f72DO2D18675 for ; Thu, 2 Aug 2001 06:24: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 GAA13125 for ; Thu, 2 Aug 2001 06:24:04 -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 GAA26917 for ; Thu, 2 Aug 2001 06:24:02 -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 f72DM4J00572 for ; Thu, 2 Aug 2001 06:22:13 -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 ABO05091; Thu, 2 Aug 2001 06:23:52 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id GAA13342; Thu, 2 Aug 2001 06:23:52 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15209.21608.16926.510932@thomasm-u1.cisco.com> Date: Thu, 2 Aug 2001 06:23:52 -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: <3B690D50.458B7F35@inrialpes.fr> References: <3B690D50.458B7F35@inrialpes.fr> 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 Claude Castelluccia writes: > Lars Henrik Petander wrote: > > SUCV and CAM both provide a lightweight solution to the problem of address > > ownership, by cryptographically binding the home address to the public key > > of MN. This could be used in combination with almost any protocol, which > > uses public key cryptograhy, to verify cryptograhically that MN really > > "owns" its home address. > > > > IMHO use of a SUCV is a lot more secure than using return routability. > > Also as there is no dependence on a trusted third party, the protocol > > should scale well. > > > > Hello Henrik... > > I of course agree with you ;-) > SUCV does not rely on any trusted third party and scales very well... > > SUCVp also uses return routability but not as a proof of address ownership but > rather to avoid some DoS attacks as described in the draft... This really amounts to the same thing. The Diffie-Hellman exchange is being protected by a return routability test but since it's the exchange is not bound to trustable direct or third party knowledge, the key agreement protocol isn't providing any _additional_ authentication properties (which is why all of these drafts are subject to MITM attacks, etc.) This is why I think that we must make public key crypto explicitly optional as I did in draft-thomas-mobileip-ha-cookies. They have their use, but their use is in the cpu time/messages tradeoff domain, not in the authentication domain. > BTW SUCVp can also be used to prove the CoA address owernship... this is very > usefull to > avoid address stealing and some DoS attacks (see > . http://www.inrialpes.fr/planete/people/ccastel/draft-montenegro-sucv-01.txt > for more details). I don't understand how you can possibly have "proof" of address ownership without either direct or third party knowledge of a key to address binding. Perfect forward secrecy is only as strong as the initial authentication; it doesn't provide additional authentication. Mike From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 2 10:26: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 KAA28738 for ; Thu, 2 Aug 2001 10:26: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 IAA28485; Thu, 2 Aug 2001 08:26: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 HAA05307; Thu, 2 Aug 2001 07:26:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f72EPCX18896 for mobile-ip-dist; Thu, 2 Aug 2001 07:25:12 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f72EP9D18889 for ; Thu, 2 Aug 2001 07:25:09 -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 HAA28996 for ; Thu, 2 Aug 2001 07:25:06 -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 IAA27395 for ; Thu, 2 Aug 2001 08:25:03 -0600 (MDT) Received: by p-voyageur.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19) id ; Thu, 2 Aug 2001 15:50:20 +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 QADMN48B; Thu, 2 Aug 2001 15:50:16 +0200 Message-ID: <3B695A68.8BA8665D@francetelecom.com> Date: Thu, 02 Aug 2001 15:49:28 +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] Concern over draft-team-mobileip-mipv6-sec-reqts-00.txt References: <00ee01c11b0c$8db52120$8a1b6e0a@arenanet.fi> 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 IAA28485 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA28738 Hi, Jari Arkko a écrit : > Charlie, Erik, > > Erik you wrote this: > > > > Therefore, we are free to choose between > > > MIP-specific BU protection and IPsec AH independent of how > > > the key management is solved. > > > > You are assuming that it is easy to use IKE to create non-IPsec keys e.g. > > for MIP specific BU protection. > > Are you sure it is that easy? > > (I don't have any data - but I thought IKE was tied to IPsec.) > > I'm trying to make the point here that the BU protection and key > management can be solved in an independent manner. I wasn't > actually thinking that IKE be used to create MIP-specific SAs. > That would also be possible, though it involves some more work. > > Instead, I think a much more fruitful approach would be the following: > > - CN, MN, and HA nodes implement AH protection for BUs in the manner > discussed before in this thread i.e. no piggybacking and a new > next header number. Current IPsec suffices for this. > > - CN and MN nodes implement BAKE - or something similar - > in order to generate keys without a global PKI. BAKE provides > keys for AH i.e. creates IPsec SAs. We do need to complete > BAKE in this WG, but I don't think it'll make a difference whether > it keys IPsec SAs or other kinds of SAs. > > - Optionally, some nodes may implement IKE in order to > use it for VPNs or for the protection of BUs through a > corporate PKI. JMC : or if you want to guaranty no breaks during sensitive communications (eg. IP telephony) Regards. JMC. > Of course IKE will also be creating > keys for IPsec SAs. > > Jari -- 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 Thu Aug 2 11:03: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 LAA00690 for ; Thu, 2 Aug 2001 11:03: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 JAA27048; Thu, 2 Aug 2001 09:04: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 HAA09743; Thu, 2 Aug 2001 07:58:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f72Evug19020 for mobile-ip-dist; Thu, 2 Aug 2001 07:57:56 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f72EvqD19013 for ; Thu, 2 Aug 2001 07:57:52 -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 HAA03130; Thu, 2 Aug 2001 07:57:53 -0700 (PDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA21110; Thu, 2 Aug 2001 08:57:50 -0600 (MDT) 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 f72EtbJ03689; Thu, 2 Aug 2001 07:55:37 -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 ABO06149; Thu, 2 Aug 2001 07:57:21 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA13349; Thu, 2 Aug 2001 07:57:21 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15209.27217.622682.284932@thomasm-u1.cisco.com> Date: Thu, 2 Aug 2001 07:57:21 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Cc: "Erik Nordmark" , "Charles E. Perkins" Subject: Re: [mobile-ip] Concern over draft-team-mobileip-mipv6-sec-reqts-00.txt In-Reply-To: <00ee01c11b0c$8db52120$8a1b6e0a@arenanet.fi> References: <00ee01c11b0c$8db52120$8a1b6e0a@arenanet.fi> 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: > Instead, I think a much more fruitful approach would be the following: > > - CN, MN, and HA nodes implement AH protection for BUs in the manner > discussed before in this thread i.e. no piggybacking and a new > next header number. Current IPsec suffices for this. Agreed. > - CN and MN nodes implement BAKE - or something similar - > in order to generate keys without a global PKI. BAKE provides > keys for AH i.e. creates IPsec SAs. We do need to complete > BAKE in this WG, but I don't think it'll make a difference whether > it keys IPsec SAs or other kinds of SAs. I'm not so sure here as there's a consideration which hasn't been discussed yet (to my knowledge). IPsec and other kinds of schemes like it create hard state on the nodes. That is, state that cannot be deleted at will by either of the hosts without causing synchronization problems. It would be nice to have a scheme which allows soft state instead. This is not possible with strong authentication unless you use public-key digital signatures. However, it does seem like it's possible with the weaker return routability-based authentication schemes. Given that BU's are soft state, it would be highly advantageous to allow for soft state in the weaker variety of BU authentication. Indeed, I see no reason to force hard state between the MN/CN in general for the very reason that the return routability test is, itself, an example of a repeatable test which can be used as a means of producing soft state. > - Optionally, some nodes may implement IKE in order to > use it for VPNs or for the protection of BUs through a > corporate PKI. Of course IKE will also be creating > keys for IPsec SAs. Right. My main argument here is that if we are given the choice between something that has standard key distribution methods defined right now, and something that does not, there should be extraordinary reasons why we'd choose the latter since key distribution is such a nightmare. Mike From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 2 11:06: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 LAA00845 for ; Thu, 2 Aug 2001 11:06: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 IAA13084; Thu, 2 Aug 2001 08:06:42 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA10904; Thu, 2 Aug 2001 08:06:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f72F5dr19081 for mobile-ip-dist; Thu, 2 Aug 2001 08:05:39 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f72F5ZD19074 for ; Thu, 2 Aug 2001 08:05: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 IAA28859 for ; Thu, 2 Aug 2001 08:05:36 -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 IAA21348 for ; Thu, 2 Aug 2001 08:05:35 -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 f72F2gf00729 for ; Thu, 2 Aug 2001 17:02:43 +0200 (MEST) Message-ID: <3B696B95.757D353F@inrialpes.fr> Date: Thu, 02 Aug 2001 17:02:45 +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] Concern over draft-team-mobileip-mipv6-sec-reqts-00.txt References: <3B690D50.458B7F35@inrialpes.fr> <15209.21608.16926.510932@thomasm-u1.cisco.com> Content-Type: multipart/alternative; boundary="------------915BB0D7AE1F0E642BB9097E" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --------------915BB0D7AE1F0E642BB9097E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Michael Thomas wrote: > Claude Castelluccia writes: > > Lars Henrik Petander wrote: > > > SUCV and CAM both provide a lightweight solution to the problem of address > > > ownership, by cryptographically binding the home address to the public key > > > of MN. This could be used in combination with almost any protocol, which > > > uses public key cryptograhy, to verify cryptograhically that MN really > > > "owns" its home address. > > > > > > IMHO use of a SUCV is a lot more secure than using return routability. > > > Also as there is no dependence on a trusted third party, the protocol > > > should scale well. > > > > > > > Hello Henrik... > > > > I of course agree with you ;-) > > SUCV does not rely on any trusted third party and scales very well... > > > > SUCVp also uses return routability but not as a proof of address ownership but > > rather to avoid some DoS attacks as described in the draft... > > This really amounts to the same thing. The Diffie-Hellman > exchange is being protected by a return routability test > but since it's the exchange is not bound to trustable > direct or third party knowledge, the key agreement protocol > isn't providing any _additional_ authentication properties > (which is why all of these drafts are subject to MITM > attacks, etc.) Hello Mike, I would be very gratefull if you could explicitly tell us to which MITM attacks SUCVp are subject to... This would be very useful to us. thanks in advance, Claude. -- ---------------------------------------- Claude CASTELLUCCIA, INRIA Rhone-Alpes ph: +33 4.76.61.52.15 (fax: 52.52) http://www.inrialpes.fr/planete/ --------------915BB0D7AE1F0E642BB9097E Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Michael Thomas wrote:
Claude Castelluccia writes:
 > Lars Henrik Petander wrote:
 > > SUCV and CAM both provide a lightweight solution to the problem of address
 > > ownership, by cryptographically binding the home address to the public key
 > > of MN. This could be used in combination with almost any protocol, which
 > > uses public key cryptograhy, to verify cryptograhically that MN really
 > > "owns" its home address.
 > >
 > > IMHO use of a SUCV is a lot more secure than using return routability.
 > > Also as there is no dependence on a trusted third party, the protocol
 > > should scale well.
 > >
 >
 > Hello Henrik...
 >
 > I of course agree with you ;-)
 > SUCV does not rely on any trusted third party and scales very well...
 >
 > SUCVp also uses return routability but not as a proof of address ownership but
 > rather to avoid some DoS attacks as described in the draft...

   This really amounts to the same thing. The Diffie-Hellman
   exchange is being protected by a return routability test
   but since it's the exchange is not bound to trustable
   direct or third party knowledge, the key agreement protocol
   isn't providing any _additional_ authentication properties
   (which is why all of these drafts are subject to MITM
   attacks, etc.)

Hello Mike,

I would be very gratefull if you could explicitly tell us to which MITM attacks SUCVp
are subject to...
This would be very useful to us.

thanks in advance,

Claude. 

-- 

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes  
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/
  --------------915BB0D7AE1F0E642BB9097E-- From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 2 11:47: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 LAA02552 for ; Thu, 2 Aug 2001 11:47: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 IAA02935; Thu, 2 Aug 2001 08:48: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 IAA11510; Thu, 2 Aug 2001 08:47:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f72FkJP19312 for mobile-ip-dist; Thu, 2 Aug 2001 08:46:19 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f72FkFD19305 for ; Thu, 2 Aug 2001 08:46:15 -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 IAA11174 for ; Thu, 2 Aug 2001 08:46:16 -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 IAA05895 for ; Thu, 2 Aug 2001 08:46:08 -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 f72FjO920337 for ; Thu, 2 Aug 2001 11:45:24 -0400 (EDT) Received: from zrchb200.us.nortel.com by smtprch1.nortel.com; Thu, 2 Aug 2001 10:45:35 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 2 Aug 2001 10:45:18 -0500 Message-ID: <85AA7486A2C1D411BCA20000F8073E4302FDB4C7@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: Thu, 2 Aug 2001 10:45:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C11B6A.2012A260" Sender: owner-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_01C11B6A.2012A260 Content-Type: text/plain; charset="iso-8859-1" Ya know alper, route optimization, in general, certainly complicates things. In fact mobility complicates things. Perhaps we just shouldn't do any of it. This is all just too complicated. Let's just keep building stagnated stupid routers and hosts - not to mention access specific single point of failure anchored systems. My point is that it isn't that complicated. -----Original Message----- From: Alper Yegin [mailto:Alper.Yegin@eng.sun.com] Sent: Tuesday, July 31, 2001 6:38 PM 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 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 ------_=_NextPart_001_01C11B6A.2012A260 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

Ya know alper, route optimization, in general, = certainly complicates things. In fact mobility  complicates = things. Perhaps we just shouldn't do any of it. This is all just too = complicated. Let's just keep building stagnated stupid routers and = hosts - not to mention access specific single point of failure anchored = systems.

My point is that it isn't that complicated.

-----Original Message-----
From: Alper Yegin [mailto:Alper.Yegin@eng.sun.com]
Sent: Tuesday, July 31, 2001 6:38 PM
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


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

------_=_NextPart_001_01C11B6A.2012A260-- From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 2 12:55: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 MAA06701 for ; Thu, 2 Aug 2001 12:55: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 KAA03956; Thu, 2 Aug 2001 10:56: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 JAA20404; Thu, 2 Aug 2001 09:56:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f72GsSE19618 for mobile-ip-dist; Thu, 2 Aug 2001 09:54:28 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f72GsPD19608 for ; Thu, 2 Aug 2001 09:54:25 -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 JAA04652 for ; Thu, 2 Aug 2001 09:54: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 JAA18927 for ; Thu, 2 Aug 2001 09:54:25 -0700 (PDT) Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.24.14]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f72Gr0306240; Thu, 2 Aug 2001 09:53:00 -0700 (PDT) Received: from cisco.com (alpesh-u5.cisco.com [128.107.162.126]) by mira-sjcm-2.cisco.com (Mirapoint) with ESMTP id AFV00107 (AUTH alpesh); Thu, 2 Aug 2001 09:52:46 -0700 (PDT) Message-ID: <3B69855D.4F20AB2B@cisco.com> Date: Thu, 02 Aug 2001 09:52:45 -0700 From: Alpesh Patel X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com CC: "Madhavi W. Chandra" , "Charles E. Perkins" , Pat Calhoun , "Kent K. Leung" Subject: Re: [mobile-ip] Re: mobile-ip] Re: mobile-ip] WG last call: draft-ietf-mobileip-gen-key-00.txt References: <20010718115752.A689@cisco.com> <3B61D37F.A75CF9B4@iprg.nokia.com> <20010731143810.B5836@cisco.com> <20010731120312.D6031@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 Pat, We can probably define the specifics/details of the operation of this in another draft. What we are asking is that you include a statement in this regard so that we have a basis for a new draft. We don't want to close the avenues through which we can define unsolicited key distribution. I personally think it is better to amend your draft now instead of going back to revise your rfc to support unsolicited key distribution. Alpesh Pat Calhoun wrote: > > 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. > > > > > > > > > > > > -- -a From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 2 13: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 NAA08855 for ; Thu, 2 Aug 2001 13:39: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 IAA29544; Thu, 2 Aug 2001 08:41:32 -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 IAA09910; Thu, 2 Aug 2001 08:40:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f72FdNN19246 for mobile-ip-dist; Thu, 2 Aug 2001 08:39:23 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f72FdJD19239 for ; Thu, 2 Aug 2001 08:39:20 -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 IAA03998 for ; Thu, 2 Aug 2001 08:39:21 -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 IAA12037 for ; Thu, 2 Aug 2001 08:39:20 -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 f72FdKg14124 for ; Thu, 2 Aug 2001 08:39: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 ABO06852; Thu, 2 Aug 2001 08:39:19 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA13388; Thu, 2 Aug 2001 08:39:19 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15209.29735.403782.258535@thomasm-u1.cisco.com> Date: Thu, 2 Aug 2001 08:39:19 -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: <3B696B95.757D353F@inrialpes.fr> References: <3B690D50.458B7F35@inrialpes.fr> <15209.21608.16926.510932@thomasm-u1.cisco.com> <3B696B95.757D353F@inrialpes.fr> 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 Claude Castelluccia writes: > Michael Thomas wrote: > > This really amounts to the same thing. The Diffie-Hellman > > exchange is being protected by a return routability test > > but since it's the exchange is not bound to trustable > > direct or third party knowledge, the key agreement protocol > > isn't providing any _additional_ authentication properties > > (which is why all of these drafts are subject to MITM > > attacks, etc.) > > Hello Mike, > > I would be very gratefull if you could explicitly tell us to which MITM attacks > SUCVp > are subject to... > This would be very useful to us. Claude, What you propose is the security equivalent of a perpetual motion machine :-) It is well known that all schemes which do not incorporate authentication -- either direct or third party -- are subject to man in the middle attack. That is, if my message goes through an untrusted man in the middle, it can dup both parties into believing that they are speaking end to end when they are in fact speaking through the man in the middle who can adulter/insert/delete messages. In the case of MIP, the MITM would likely be a router, though it's possible there are attacks from the edge as well. The only way that I can counter the MITM is to possess a piece of _independently_ obtained information for which you can supply some cryptographic transform which leads me to believe that you are in possession of the information which binds the request to whatever you are asserting ownership of (and thus control). Practically speaking, that means a key, either asymmetric or symmetric, that I've obtained securely and *in advance* of the request, either directly, or by leveraging a trusted third party. I've not read enough in the SUCV draft to find exactly where the MITM attack is possible, but if it is based off of HIP in its oppertunistic mode, then such an attack is definitely possible (which I'm pretty sure that Bob would agree). This is not to say that such opportunistic encryption is not completely without value; indeed it does a reasonable job of keeping outsiders out even with the MITM attack possibility. However, we need to not fall victim to belief that the security equivalent of the second law of thermodynamics can be repealed. Mike From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 2 13:43: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 NAA09092 for ; Thu, 2 Aug 2001 13:43: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 KAA29897; Thu, 2 Aug 2001 10:44: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 KAA02412; Thu, 2 Aug 2001 10:43:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f72HfuB19786 for mobile-ip-dist; Thu, 2 Aug 2001 10:41:56 -0700 (PDT) Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f72HfsD19779 for ; Thu, 2 Aug 2001 10:41:54 -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 NAA06158 for ; Thu, 2 Aug 2001 13:41:55 -0400 (EDT) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id NAA17464 for mobile-ip@sunroof.eng.sun.com; Thu, 2 Aug 2001 13:42:21 -0400 (EDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f720LmD16188 for ; Wed, 1 Aug 2001 17:21: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 RAA04375 for ; Wed, 1 Aug 2001 17:21:56 -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 RAA05489 for ; Wed, 1 Aug 2001 17:21:55 -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 GHEZH100.OX7 for ; Thu, 2 Aug 2001 09:17:25 +0900 Message-ID: <000801c11ae9$854617b0$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> <20010728163959.B24014@charizard.diameter.org> Subject: Re: [mobile-ip] I-D ACTION:draft-ietf-mobileip-aaa-key-08.txt Date: Thu, 2 Aug 2001 09:24:40 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.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 f720LmD16189 Sender: owner-mobile-ip@sunroof.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! ----- Original Message ----- From: "Pat Calhoun" To: Sent: Sunday, July 29, 2001 8:40 AM Subject: Re: [mobile-ip] I-D ACTION:draft-ietf-mobileip-aaa-key-08.txt > > 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. > I think you agreed that your draft is not a complete solution in RADIUS based architecture because some other security association must be present betwen FA and HA. Right? If so, someone want to use your draft in RADIUS based architecture and they want not to use IPSec like secuirty protocol betwen FA and HA, then it is vulnerable to the DoS attack not because of the security hole of your draft but because of the that of RADIUS. They should have mandate FA-HA authentication extension in this case, I think. > Thanks, > > PatC > Thanks Chae-yong From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 2 13:46: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 NAA09250 for ; Thu, 2 Aug 2001 13:46:11 -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 LAA14893; Thu, 2 Aug 2001 11:46: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 KAA03165; Thu, 2 Aug 2001 10:46:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f72HjCP19804 for mobile-ip-dist; Thu, 2 Aug 2001 10:45:12 -0700 (PDT) Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f72HirD19797 for ; Thu, 2 Aug 2001 10:44:57 -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 NAA27509 for ; Thu, 2 Aug 2001 13:44:51 -0400 (EDT) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id NAA17516 for mobile-ip@sunroof.eng.sun.com; Thu, 2 Aug 2001 13:45:17 -0400 (EDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f721hrD16355 for ; Wed, 1 Aug 2001 18:43:53 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA17115 for ; Wed, 1 Aug 2001 18:44:08 -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 TAA28284 for ; Wed, 1 Aug 2001 19:45:38 -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 GHF39Z00.256 for ; Thu, 2 Aug 2001 10:39:35 +0900 Message-ID: <002401c11af5$00575e40$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> <20010728163959.B24014@charizard.diameter.org> Subject: Re: [mobile-ip] I-D ACTION:draft-ietf-mobileip-aaa-key-08.txt Date: Thu, 2 Aug 2001 10:46:51 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.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 f721hsD16356 Sender: owner-mobile-ip@sunroof.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 ----- Original Message ----- From: "Pat Calhoun" To: Sent: Sunday, July 29, 2001 8:40 AM Subject: Re: [mobile-ip] I-D ACTION:draft-ietf-mobileip-aaa-key-08.txt > > 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. > I think you agreed that your draft is not a complete solution in RADIUS based architecture because some other security association must be present betwen FA and HA. Right? If so, someone want to use your draft in RADIUS based architecture and they want not to use IPSec like secuirty protocol betwen FA and HA, then it is vulnerable to the DoS attack not because of the security hole of your draft but because of the that of RADIUS. They should have mandate FA-HA authentication extension in this case, I think. > Thanks, > > PatC > Thanks Chae-yong From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 2 14:13: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 OAA10813 for ; Thu, 2 Aug 2001 14:13: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 MAA07226; Thu, 2 Aug 2001 12:13:41 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA09318; Thu, 2 Aug 2001 11:13:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f72IBIi19965 for mobile-ip-dist; Thu, 2 Aug 2001 11:11:18 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f72IBDD19958 for ; Thu, 2 Aug 2001 11:11: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 LAA14455 for ; Thu, 2 Aug 2001 11:11:10 -0700 (PDT) Received: from tml-gw.tml.hut.fi (tml.hut.fi [130.233.44.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA28694 for ; Thu, 2 Aug 2001 12:11:07 -0600 (MDT) Received: (from smap@localhost) by tml-gw.tml.hut.fi (8.8.7/8.8.7) id VAA17786 for ; Thu, 2 Aug 2001 21:08:27 +0300 Received: from mail.tml.hut.fi(130.233.45.70) by tml-gw.tml.hut.fi via smap (V2.0) id xma017780; Thu, 2 Aug 01 21:08:19 +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 f72I9rN17638; Thu, 2 Aug 2001 21:09:53 +0300 (EEST) Received: from localhost (lpetande@localhost) by morphine.tml.hut.fi (8.11.3/8.11.3) with ESMTP id f72IApG29494; Thu, 2 Aug 2001 21:10:51 +0300 (EET DST) X-Authentication-Warning: morphine.tml.hut.fi: lpetande owned process doing -bs Date: Thu, 2 Aug 2001 21:10:51 +0300 (EET DST) From: Lars Henrik Petander To: "Charles E. Perkins" cc: mobile-ip@sunroof.eng.sun.com, Venkata Jagana Subject: [mobile-ip] home address option and DHAAD in MIPv6 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 Charlie, When implementing DHAAD, we noticed that the resending policy for the DHAAD request is not specified in draft 14. However, it probably should be specified, since the initial request or reply can easily get lost if MN moves. Regarding the processing of the home address option section 8.1 says: "... However, any actual modifications to the Source Address field in the packet's IPv6 header MUST not be performed until after all processing of other options contained in the same Destination Options extension header is completed." Normally destination options are handled independently of each other in the order they are in the packet, which allows a clean design for destination option processing. Unfortuantely draft section 8.1 breaks this and requires the handler to go back to the home address option after processing all other destination options in the header. I wonder, whether this behaviour is really worth the complications it causes. If it is absolutely necessary to handle the home address option only after the other options are processed, it would IMHO be better to make the sender of the packet responsible for the ordering. (The sender would add the home address option as the last option in the 1. destination options header.) Regards, Henrik From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 2 15:28: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 PAA15250 for ; Thu, 2 Aug 2001 15:28: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 NAA05719; Thu, 2 Aug 2001 13:29: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 MAA25439; Thu, 2 Aug 2001 12:28:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f72JQq120367 for mobile-ip-dist; Thu, 2 Aug 2001 12:26:52 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.88.31]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f72JQnD20360 for ; Thu, 2 Aug 2001 12:26:49 -0700 (PDT) Received: from istanbul.Eng.Sun.COM (istanbul.Eng.Sun.COM [129.146.86.247]) by jurassic.eng.sun.com (8.11.5+Sun/8.11.5) with SMTP id f72JQmb638871; Thu, 2 Aug 2001 12:26:48 -0700 (PDT) Message-Id: <200108021926.f72JQmb638871@jurassic.eng.sun.com> Date: Thu, 2 Aug 2001 12:26:48 -0700 (PDT) From: Alper Yegin Subject: RE: [mobile-ip] Concern over draft-team-mobileip-mipv6-sec-reqts- 00.txt To: gmorrow@nortelnetworks.com, 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: j8B19Hrhvq07w6hqKXrQ6g== 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 Glenn, > Ya know alper, route optimization, in general, certainly complicates things. > In fact mobility complicates things. Perhaps we just shouldn't do any of > it. This is all just too complicated. Let's just keep building stagnated > stupid routers and hosts - not to mention access specific single point of > failure anchored systems. Of course not :) You seem to be picking on my "implementation complexity" point. By the way, I'm talking about piggybacking binding messages, not talking about route optimization. Implementation complexity by itself is not the only issue. The other points I have raised was the performance hit due to handling "binding message should wait until we have a packet to send to the same destination, or a timer goes off"... It's hard to say which one is more important: saving bandwidth or processing power. And the PMTU issue... You haven't addressed my last two issues.. All I'm saying is that there are also downsides to piggybacking. It's not all that great. alper > > My point is that it isn't that complicated. > > -----Original Message----- > From: Alper Yegin [mailto:Alper.Yegin@eng.sun.com] > Sent: Tuesday, July 31, 2001 6:38 PM > 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 > > > 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 > alper From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 2 15:33: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 PAA15494 for ; Thu, 2 Aug 2001 15:33:52 -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 NAA09697; Thu, 2 Aug 2001 13:34: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 MAA26652; Thu, 2 Aug 2001 12:34:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f72JXKR20441 for mobile-ip-dist; Thu, 2 Aug 2001 12:33:20 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f72JXBD20428 for ; Thu, 2 Aug 2001 12:33:11 -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 MAA02064 for ; Thu, 2 Aug 2001 12:33:09 -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 MAA10773 for ; Thu, 2 Aug 2001 12:33:09 -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 f72JN9g01023 for ; Thu, 2 Aug 2001 12:23:09 -0700 (PDT) Received: from GDOMMETY-W2K2.cisco.com (dhcp-171-70-57-120.cisco.com [171.70.57.120]) by mira-sjcm-3.cisco.com (Mirapoint) with ESMTP id AAS04475; Thu, 2 Aug 2001 12:23:06 -0700 (PDT) Message-Id: <4.3.2.7.2.20010802122523.0261a680@mira-sjcm-3.cisco.com> X-Sender: gdommety@mira-sjcm-3.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 02 Aug 2001 12:25:52 -0700 To: 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: <034BEFD03799D411A59F00508BDF754603008B98@esealnt448.al.sw. ericsson.se> 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. I will include it. -Gopal At 06:55 PM 8/1/2001 +0200, you wrote: >Gopal, > >DAD handling was already covered by the introduction >of HI/HAck. The text below wouldn't hurt though. > >Hesham > >-----Original Message----- >From: Gopal Dommety >To: mobile-ip@sunroof.eng.sun.com; mobile-ip@sunroof.eng.sun.com >Sent: 7/31/2001 5:36 PM >Subject: Re: [mobile-ip] Re:Comments on draft-ietf-mobileip-fast-mipv6-02.txt > >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 Thu Aug 2 16:47: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 QAA18491 for ; Thu, 2 Aug 2001 16:47: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 OAA01848; Thu, 2 Aug 2001 14:48:35 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA18241; Thu, 2 Aug 2001 13:48:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f72KjOO20661 for mobile-ip-dist; Thu, 2 Aug 2001 13:45:24 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f72KjJD20654 for ; Thu, 2 Aug 2001 13:45:20 -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 NAA11924 for ; Thu, 2 Aug 2001 13:45:21 -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 OAA29714 for ; Thu, 2 Aug 2001 14:45:18 -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 f72KivY14057; Thu, 2 Aug 2001 13:44:57 -0700 (PDT) Received: from cisco.com (alpesh-u5.cisco.com [128.107.162.126]) by mira-sjcm-2.cisco.com (Mirapoint) with ESMTP id AFX01402 (AUTH alpesh); Thu, 2 Aug 2001 13:44:42 -0700 (PDT) Message-ID: <3B69BBB9.5B723C3C@cisco.com> Date: Thu, 02 Aug 2001 13:44:41 -0700 From: Alpesh Patel X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com CC: "Madhavi W. Chandra" , "Charles E. Perkins" , Pat Calhoun , "Kent K. Leung" Subject: Re: [mobile-ip] Re: mobile-ip] Re: mobile-ip] WG last call: draft-ietf-mobileip-gen-key-00.txt References: <20010718115752.A689@cisco.com> <3B61D37F.A75CF9B4@iprg.nokia.com> <20010731143810.B5836@cisco.com> <20010731120312.D6031@charizard.diameter.org> <3B69855D.4F20AB2B@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 Alpesh Patel wrote: Pat, In addition to the request for adding the unsolicited key push feature, we are still requesting support for HA-HA authentication as requested by Madhavi Chandra. Also, we are still wondering if authentication of a reply carrying a key is in line with RFC2002 - MN parses the reply, obtains the key from an extension in the reply and uses this key to authenticate the message. Thanks Alpesh > > Pat, > > We can probably define the specifics/details of the operation of this > in another draft. What we are asking is that you include a statement in > this regard so that we have a basis for a new draft. We don't want to > close the avenues through which we can define unsolicited key > distribution. > > I personally think it is better to amend your draft now instead of going > back to revise your rfc to support unsolicited key distribution. > > Alpesh > > Pat Calhoun wrote: > > > > 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. > > > > > > > > > > > > > > > > > > > > -- > -a -- -a From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 2 16:57: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 QAA19053 for ; Thu, 2 Aug 2001 16:57: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 NAA27510; Thu, 2 Aug 2001 13:57: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 NAA03587; Thu, 2 Aug 2001 13:57:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f72KtqJ20796 for mobile-ip-dist; Thu, 2 Aug 2001 13:55:52 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f72KtnD20789 for ; Thu, 2 Aug 2001 13:55:49 -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 NAA14344 for ; Thu, 2 Aug 2001 13:55: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 OAA07365 for ; Thu, 2 Aug 2001 14:55:47 -0600 (MDT) Received: (qmail 20329 invoked by uid 500); 2 Aug 2001 20:44:48 -0000 Date: Thu, 2 Aug 2001 13:44:48 -0700 From: Pat Calhoun To: Alpesh Patel Cc: mobile-ip@sunroof.eng.sun.com, "Madhavi W. Chandra" , "Charles E. Perkins" , Pat Calhoun , "Kent K. Leung" Subject: Re: [mobile-ip] Re: mobile-ip] Re: mobile-ip] WG last call: draft-ietf-mobileip-gen-key-00.txt Message-ID: <20010802134448.A20321@charizard.diameter.org> References: <20010718115752.A689@cisco.com> <3B61D37F.A75CF9B4@iprg.nokia.com> <20010731143810.B5836@cisco.com> <20010731120312.D6031@charizard.diameter.org> <3B69855D.4F20AB2B@cisco.com> <3B69BBB9.5B723C3C@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: <3B69BBB9.5B723C3C@cisco.com>; from alpesh@cisco.com on Thu, Aug 02, 2001 at 01:44:41PM -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, Aug 02, 2001 at 01:44:41PM -0700, Alpesh Patel wrote: > Alpesh Patel wrote: > > Pat, > > In addition to the request for adding the unsolicited key push feature, > we are still requesting support for HA-HA authentication as requested > by Madhavi Chandra. Somehow I missed that request. > > Also, we are still wondering if authentication of a reply carrying a > key is in line with RFC2002 - MN parses the reply, obtains the key > from an extension in the reply and uses this key to authenticate the > message. That is correct. PatC > > Thanks > Alpesh > > > > > > Pat, > > > > We can probably define the specifics/details of the operation of this > > in another draft. What we are asking is that you include a statement in > > this regard so that we have a basis for a new draft. We don't want to > > close the avenues through which we can define unsolicited key > > distribution. > > > > I personally think it is better to amend your draft now instead of going > > back to revise your rfc to support unsolicited key distribution. > > > > Alpesh > > > > Pat Calhoun wrote: > > > > > > 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. > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > -a > > -- > -a From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 2 17: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 RAA23654 for ; Thu, 2 Aug 2001 17:37: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 EAA25170; Thu, 2 Aug 2001 04:18: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 EAA01826; Thu, 2 Aug 2001 04:17:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f72BGIZ17906 for mobile-ip-dist; Thu, 2 Aug 2001 04:16:18 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f72BGED17899 for ; Thu, 2 Aug 2001 04:16:15 -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 EAA01763 for ; Thu, 2 Aug 2001 04:16: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 FAA29440 for ; Thu, 2 Aug 2001 05:17:46 -0600 (MDT) Received: (qmail 18968 invoked by uid 500); 2 Aug 2001 11:05:15 -0000 Date: Thu, 2 Aug 2001 04:05:15 -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: <20010802040515.W8990@charizard.diameter.org> References: <200107271107.HAA06650@ietf.org> <04fa01c11694$b08a2960$0ee0d5a5@telecom.samsung.co.kr> <20010727065112.L13541@charizard.diameter.org> <000901c1171b$71ccfd60$10e0d5a5@cychong> <20010728163959.B24014@charizard.diameter.org> <002d01c11b33$82e98a70$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: <002d01c11b33$82e98a70$10e0d5a5@cychong>; from cychong@telecom.samsung.co.kr on Thu, Aug 02, 2001 at 06:14:18PM +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: > I think you agreed that your draft is not a complete solution in RADIUS based architecture because > some other security association must be present betwen FA and HA. Right? > If so, someone want to use your draft in RADIUS based architecture and they want not to use > IPSec like secuirty protocol betwen FA and HA, then it is vulnerable to the DoS attack not because > of the security hole of your draft but because of the that of RADIUS. They should > have mandate FA-HA authentication extension in this case, I think. Isn't this similar to blaming the tire manufacturer about a car's performance, when the car itself only accepts square tires? ok, seriously, the original challenge draft didn't include support for RADIUS, but the authors were forced to add support for it by some folks that also attend 3GPP2 meetings. The text that you see in the RFC is the result of text proposed by folks within 3GPP2. If, as you state, a denial of service attack is possible on the HA because RADIUS doesn't lend itself very well to Mobile IP's operational model, I'm not sure that there's much that the FAC RFC can do to fix that problem. Now that no new RADIUS development is being done within the IETF, perhaps it is time for folks to embrace the new AAA work? Thanks, PatC From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 2 18:07: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 SAA25573 for ; Thu, 2 Aug 2001 18:07: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 QAA28060; Thu, 2 Aug 2001 16:08: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 PAA20140; Thu, 2 Aug 2001 15:08:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f72M7R921201 for mobile-ip-dist; Thu, 2 Aug 2001 15:07:27 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f72M7ND21194 for ; Thu, 2 Aug 2001 15:07:23 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA04752 for ; Thu, 2 Aug 2001 15:07:16 -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 QAA06194 for ; Thu, 2 Aug 2001 16:07:13 -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 f72M7DO27786 for ; Fri, 3 Aug 2001 00:07:13 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Fri Aug 03 00:07:12 2001 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 3 Aug 2001 00:00:55 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008B9F@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Michael Thomas '" , "'mobile-ip@sunroof.eng.sun.com '" Cc: "''Vijay Devarapalli ' '" Subject: RE: [mobile-ip] Concern over draft-team-mobileip-mipv6-sec-reqts- 00.txt Date: Fri, 3 Aug 2001 00:07:02 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) List-Subscribe: List-Unsubscribe: Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > 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. > > => The Home address destination option is not > relevant here. The BU is. These are 2 separate > options so you don't need to apply the AH to > every packet. I'm pretty sure that Vijay is correct here. => No because the statement assumed that the Home Address option implied that protection is required. It is the BU option that implies that. 2 different options. IPsec selectors do not define a standard way to use the port numbers in the ID payload to select for different destination options. This is probably not that hard to define, but it's not standard now. => My point has been that, provided there is no piggybacking we can keep the selectors' granularity as they are by creating a new nxt header value or increase the granularity by looking for the BU option. ONLY packets with the BU option will be protected in either case. Hesham > 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 Thu Aug 2 18:12: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 SAA25783 for ; Thu, 2 Aug 2001 18:12: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 QAA00951; Thu, 2 Aug 2001 16:12: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 PAA21189; Thu, 2 Aug 2001 15:12:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f72MBUP21275 for mobile-ip-dist; Thu, 2 Aug 2001 15:11:30 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f72MBRD21268 for ; Thu, 2 Aug 2001 15:11: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 PAA20881 for ; Thu, 2 Aug 2001 15:11:29 -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 QAA08351 for ; Thu, 2 Aug 2001 16:11:28 -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 f72MBQN14045 for ; Fri, 3 Aug 2001 00:11:26 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Fri Aug 03 00:11:25 2001 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 3 Aug 2001 00:05:07 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008BA0@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Charles E. Perkins '" , "'Pat Calhoun '" Cc: "'mobile-ip@sunroof.eng.sun.com '" , "'Phillip Neumiller '" Subject: RE: [mobile-ip] Analysis of Latency Propagation with Buffering Date: Fri, 3 Aug 2001 00:11:17 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) List-Subscribe: List-Unsubscribe: Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Pat Calhoun wrote: > > On Wed, Aug 01, 2001 at 12:42:14PM -0700, Charles E. Perkins wrote: > > Hello Phil, > > > > If I order a pizza, and somebody brings me two, and > > charges me twice, that's bad. > > > > If I get two for one for free, that's better, but from > > the standpoint of the restaurateur it would be nice > > if the government didn't tell him he HAD to serve me > > two for one. Furthermore, if I'm tired of eating and > > I still have to swallow the extra food, I might complain > > even about the freebie. > > > > If, on the other hand, I can buy just the pizza I want, > > and if I have to leave before I finish the meal but > > later I can ask for the slices that are still hot, > > that sounds about right to me. > > But chances are you'll end up with the remaining slices, which > are now cold, and a new pizza that is warm as well. > > So, if a packet stays around in a buffer long enough (and we're not > talking that long), the peer will most likely retransmit, and you'll > end up with dups anyways. This is a matter for managing the probabilities for such occurrences, and when it gets to that point the analogy cannot help any more. But simulation and prototype indicate that the necessary data (slices of pizza) can be consumed in enough time to help with voice. And it can be done in a way to avoid dups entirely. I thought the analogy would be useful for illustrating points about resource consumption and so on, but not for evaluating probabilities or other engineering parameters. Just to be clear, I am not categorically against bicasting, but I think it's true realm of applicability is not large enough to be mandated as part of fast handover protocol, and that there may often be more economical approaches available. => Mandating bicasting was _never_ intended or discussed. The assumption was always a MAY or a SHOULD. I think a MAY is sufficient. Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 2 18:18: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 SAA26223 for ; Thu, 2 Aug 2001 18:18:30 -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 PAA02049; Thu, 2 Aug 2001 15:19:14 -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 PAA22323; Thu, 2 Aug 2001 15:18:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f72MHj321367 for mobile-ip-dist; Thu, 2 Aug 2001 15:17:45 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f72MHgD21360 for ; Thu, 2 Aug 2001 15:17:42 -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 PAA22130 for ; Thu, 2 Aug 2001 15:17:44 -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 PAA14707 for ; Thu, 2 Aug 2001 15:17:43 -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 f72MHgO29417 for ; Fri, 3 Aug 2001 00:17:42 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Fri Aug 03 00:17:41 2001 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 3 Aug 2001 00:11:23 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008BA1@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Pat Calhoun '" , "'mobile-ip@sunroof.eng.sun.com '" Cc: "'James.Kempf@Sun.COM '" , "'charliep@iprg.nokia.com '" Subject: RE: [mobile-ip] Analysis of Latency Propagation with Buffering Date: Fri, 3 Aug 2001 00:17:32 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) List-Subscribe: List-Unsubscribe: Content-Type: text/plain; charset="iso-8859-1" Sender: owner-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, Charlie and James, > > > >>> I wanted to clarify that it isn't buffering itself that adds delay. > >>> A packet could be buffered AND transmitted to the mobile node at the > >>> same time, which then would show that buffering does not have to > >>> introduce any delay. If a packet is received by the mobile node, > >>> then presumably it would prefer not to receive the buffered copy of > >>> that packet at any time in the future. > > > >> Well, I guess I agree, but what is the point of buffering if you > >> are going to transmit it or of transmitting it if you are going > >> to buffer it? The two options seem mutually exclusive to me. > >> Am I missing something? > > > >The point of buffering and simultaneously transmitting is that > >sometimes the mobile node might not be there to receive the transmitted > >packet -- say because it moved to a new access router. Then it would > >request the previous access router to send the buffered packets that > >it had not already received. > > > > OK, now I understand. I suggested something like this, but with > the new AR doing the buffering, in Appendix B of the BETH draft. in which case the mobile doesn't have to request the packets, since opening the L2 would cause buffered packets to be released to the mobile node. => Two points to consider here: 1. What Charlie suggests above IS bicasting except that it is not explicitly requested by the MN. There are several issues here that I highlighted on the FMIPv6 list and on this list earlier. 2. How do you know the MN has detached ?? Is this a generic assumption ? The answer is you don't know on all link layers and it is not a generic assumption. Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 2 18:24: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 SAA26673 for ; Thu, 2 Aug 2001 18:24: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 QAA08423; Thu, 2 Aug 2001 16:24: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 PAA23383; Thu, 2 Aug 2001 15:24:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f72MNUj21456 for mobile-ip-dist; Thu, 2 Aug 2001 15:23:30 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f72MNQD21449 for ; Thu, 2 Aug 2001 15:23: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 PAA18464 for ; Thu, 2 Aug 2001 15:23:24 -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 QAA07490 for ; Thu, 2 Aug 2001 16:23:22 -0600 (MDT) Received: (qmail 20597 invoked by uid 500); 2 Aug 2001 22:12:24 -0000 Date: Thu, 2 Aug 2001 15:12:24 -0700 From: Pat Calhoun To: "Hesham Soliman \(ERA\)" Cc: "'Pat Calhoun '" , "'mobile-ip@sunroof.eng.sun.com '" , "'James.Kempf@Sun.COM '" , "'charliep@iprg.nokia.com '" Subject: [mobile-ip] So what is bicasting vs. buffering Message-ID: <20010802151223.E20321@charizard.diameter.org> References: <034BEFD03799D411A59F00508BDF754603008BA1@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: <034BEFD03799D411A59F00508BDF754603008BA1@esealnt448.al.sw.ericsson.se>; from Hesham.Soliman@era.ericsson.se on Fri, Aug 03, 2001 at 12:17:32AM +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: So in my mind, I believe that the main difference between the bicasting and buffering approaches is simply that the latter requires the mobile to *request* packets. Am I right? PatC From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 2 18:39: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 SAA27754 for ; Thu, 2 Aug 2001 18:39:50 -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 QAA17838; Thu, 2 Aug 2001 16:40: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 PAA26956; Thu, 2 Aug 2001 15:40:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f72MdCw21593 for mobile-ip-dist; Thu, 2 Aug 2001 15:39: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+Sun/8.11.5) with ESMTP id f72Md9D21586 for ; Thu, 2 Aug 2001 15:39:09 -0700 (PDT) Received: from awe171-106 (awe195-135.AWE.Sun.COM [192.29.195.135]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id PAA08151; Thu, 2 Aug 2001 15:39:09 -0700 (PDT) Message-Id: <200108022239.PAA08151@heliopolis.eng.sun.com> Date: Thu, 2 Aug 2001 15:30:11 -0700 (PDT) From: kempf Subject: RE: [mobile-ip] Analysis of Latency Propagation with Buffering To: pcalhoun@diameter.org, mobile-ip@sunroof.eng.sun.com, Hesham.Soliman@era.ericsson.se Cc: James.Kempf@Sun.COM, charliep@iprg.nokia.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: offgBu37zGBFmT+hSIPvQQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 i86pc i386 Sender: owner-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, >=> Two points to consider here: > >1. What Charlie suggests above IS bicasting > except that it is not explicitly requested by > the MN. There are several issues here that I highlighted > on the FMIPv6 list and on this list earlier. > Well, yes, to the extent that the buffered packet is sent down both links. >2. How do you know the MN has detached ?? Is this > a generic assumption ? The answer is you don't > know on all link layers and it is not a generic > assumption. > In general, smoothing is necessary IMHO when you only have L3 information or coarse gained L2 information about handover sequencing. For example, if the only information you have to go on about when handover begins is the receipt of a HACK, then you need to bicast or buffer for a long period, until the MN begins DAD or sends a F-BU on the new AR, and the probability is that your user will notice (i.e. dropped or duplicated packets for bicasting, propagated latency for buffering) because of the side effects of handover smoothing. If you have finer grained L2 sequencing information about handover, you can forget smoothing altogether, or only buffer or bicast for a very short time period. For example, if old AR gets a Link Drop L2 trigger on L2 handover and new AR gets a Link Active trigger when the mobile appears, old AR can stop sending packets down the old L2 as soon as L2 handover begins and start tunneling them to the new AR. The new AR can then either buffer or drop the packets until it gets the Link Up trigger with the mobile's L2 address, when it starts delivery. Thus, there is only a very short window during which L2 is completely unavailable when smoothing (if any) is needed. This is why getting requirements (i.e. draft-manyfolks-mobilereq-l2-00.txt) and possibily an API and/or protocol for L2 triggers is so important. Without proper L2 sequencing information, it won't be possible to provide high quality real time flows across handovers. jak From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 2 18:40: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 SAA27859 for ; Thu, 2 Aug 2001 18:40: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 PAA10400; Thu, 2 Aug 2001 15:41: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 PAA27054; Thu, 2 Aug 2001 15:41:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f72Me1T21611 for mobile-ip-dist; Thu, 2 Aug 2001 15:40:01 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f72MdwD21604 for ; Thu, 2 Aug 2001 15:39: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 PAA11416 for ; Thu, 2 Aug 2001 15:39: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 QAA20708 for ; Thu, 2 Aug 2001 16:39: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 PAA27339; Thu, 2 Aug 2001 15:39:57 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f72MduL21769; Thu, 2 Aug 2001 15:39:56 -0700 X-mProtect: Thu, 2 Aug 2001 15:39:56 -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 smtpdOq457D; Thu, 02 Aug 2001 15:39:54 PDT Message-ID: <3B69D6BB.6695FC98@iprg.nokia.com> Date: Thu, 02 Aug 2001 15:39:55 -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 (ERA)" CC: "'mobile-ip@sunroof.eng.sun.com '" Subject: Re: [mobile-ip] Analysis of Latency Propagation with Buffering References: <034BEFD03799D411A59F00508BDF754603008B9E@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: > > > Hello Charlie, > > > 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, > ^^^^^^^^delayed before reception > > and the more likely users will perceive the converstation as stilted > > or hear some artifact. > > I wanted to clarify that it isn't buffering itself that adds delay. > A packet could be buffered AND transmitted to the mobile node at the > same time, which then would show that buffering does not have to > introduce any delay. > > => And that is not bicasting ??! First, as a general comment, it is unfortunately the case that I have trouble sometimes figuring out which parts of messages are the words that you said (usually introduced by "=>", thankfully) and the parts that were already said. Of course, you may assert that this is my problem, and enough said... Second, if our buffering scheme fits your definition of bicasting, then it seems to me that we ought to work together to fashion a smooth-handover draft that covers all the bases. Lastly, I'll again point out what I have said a number of times in the past, I am not categorically against bicasting. I just want to be sure to avoid the duplicated pizza problems. Regards, Charlie P. PS. I have new information about the TCP problems; as could have been expected, when interpreted correctly, we are both right within certain restricted problem domains. Sorry for being so vague just now; I hope to work on it more and write more soon. > > Hesham > > If a packet is received by the mobile node, > then presumably it would prefer not to receive the buffered copy of > that packet at any time in the future. > > Regards, > Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 2 18:41: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 SAA27885 for ; Thu, 2 Aug 2001 18:41: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 QAA18863; Thu, 2 Aug 2001 16:42:04 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA27292; Thu, 2 Aug 2001 15:41:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f72Mf8F21637 for mobile-ip-dist; Thu, 2 Aug 2001 15:41:08 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f72Mf3D21630 for ; Thu, 2 Aug 2001 15:41:04 -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 PAA21919 for ; Thu, 2 Aug 2001 15:41:04 -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 QAA21237 for ; Thu, 2 Aug 2001 16:41:01 -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 f72Mf1N17760 for ; Fri, 3 Aug 2001 00:41:01 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Fri Aug 03 00:41:00 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Fri, 3 Aug 2001 00:41:00 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008BA2@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Pat Calhoun '" , "Hesham Soliman (ERA)" Cc: "''mobile-ip@sunroof.eng.sun.com ' '" , "''James.Kempf@Sun.COM ' '" , "''charliep@iprg.nokia.com ' '" Subject: [mobile-ip] RE: So what is bicasting vs. buffering Date: Fri, 3 Aug 2001 00:40:51 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: So in my mind, I believe that the main difference between the bicasting and buffering approaches is simply that the latter requires the mobile to *request* packets. Am I right? => Not at all :) The proposal that Charlie mentioned IS bicasting that is the point I'm trying to make. I don't understand why people assume that if you bicast then by definition you can't buffer. You can delay packets destined to the new AR/FA based on some calculations of the average time for a handover. In addition you can bicast without a request from the MN (ie. by default in the AR). However, if you say I will send packets to the MN at the current AR and send another copy to the new AR then you ARE bicasting but just don't want to say the word :)))))))) It doesn't matter how long you buffer or delay the packets destined to the new AR you are still sending TWO copies. There are hidden assumptions if you do it by default in the AR though (without the MN's request). The assumption is that you know when the MN disconnects. This is not generic of course so you still need to allow for the option of the MN requesting bicasting. Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 2 18:43: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 SAA28092 for ; Thu, 2 Aug 2001 18:43:54 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA20239; Thu, 2 Aug 2001 16:44: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 PAA27863; Thu, 2 Aug 2001 15:44:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f72Mhj121765 for mobile-ip-dist; Thu, 2 Aug 2001 15:43: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+Sun/8.11.5) with ESMTP id f72MhfD21750 for ; Thu, 2 Aug 2001 15:43:42 -0700 (PDT) Received: from awe171-106 (awe195-135.AWE.Sun.COM [192.29.195.135]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id PAA08364; Thu, 2 Aug 2001 15:43:41 -0700 (PDT) Message-Id: <200108022243.PAA08364@heliopolis.eng.sun.com> Date: Thu, 2 Aug 2001 15:34:43 -0700 (PDT) From: kempf Subject: [mobile-ip] Re: So what is bicasting vs. buffering To: Hesham.Soliman@era.ericsson.se, pcalhoun@diameter.org Cc: pcalhoun@diameter.org, mobile-ip@sunroof.eng.sun.com, James.Kempf@sun.com, charliep@iprg.nokia.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 2xF1ntw4+IioIz0gw02UMw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 i86pc i386 Sender: owner-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, > >So in my mind, I believe that the main difference between the bicasting >and buffering approaches is simply that the latter requires the mobile >to *request* packets. > I think this is the proposal in the primary reference (draft-krishnamurthi-mobileip-buffer6-01.txt). It need not, however, be so. If just the packets arriving during L2 handover are buffered on new AR, as proposed in Appendix B of the BETH draft, then new AR can quickly download the buffer when the MN arrives on the new link, as you pointed out yesterday. The advantage of this is no signalling over the radio link, which means the radio link is free for the user's real time traffic, not MIP signalling. jak From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 2 18:48: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 SAA28411 for ; Thu, 2 Aug 2001 18:48: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 PAA13768; Thu, 2 Aug 2001 15:49: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 PAA29033; Thu, 2 Aug 2001 15:49:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f72Mm9521885 for mobile-ip-dist; Thu, 2 Aug 2001 15:48: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+Sun/8.11.5) with ESMTP id f72Mm5D21873 for ; Thu, 2 Aug 2001 15:48:05 -0700 (PDT) Received: from awe171-106 (awe195-135.AWE.Sun.COM [192.29.195.135]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id PAA08541; Thu, 2 Aug 2001 15:48:05 -0700 (PDT) Message-Id: <200108022248.PAA08541@heliopolis.eng.sun.com> Date: Thu, 2 Aug 2001 15:39:07 -0700 (PDT) From: kempf Subject: Re: [mobile-ip] Analysis of Latency Propagation with Buffering To: Hesham.Soliman@era.ericsson.se, 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: sBuVeJ1TplR6CQgZyD8K0g== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 i86pc i386 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Charlie, >Second, if our buffering scheme fits your definition of bicasting, >then it seems to me that we ought to work together to fashion a >smooth-handover draft that covers all the bases. > Outstanding idea! A joint smoothing draft with both and some analysis would be a real benefit. We just need to figure out where everybody can agree, and also I think data on some experiments is needed to validate intuition. jak From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 2 19:08: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 TAA29646 for ; Thu, 2 Aug 2001 19:08: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 QAA21130; Thu, 2 Aug 2001 16:09:06 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA02977; Thu, 2 Aug 2001 16:08:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f72N80322004 for mobile-ip-dist; Thu, 2 Aug 2001 16:08:00 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f72N7uD21997 for ; Thu, 2 Aug 2001 16:07: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 QAA02743 for ; Thu, 2 Aug 2001 16:07:57 -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 RAA04627 for ; Thu, 2 Aug 2001 17:07:54 -0600 (MDT) Received: (qmail 20795 invoked by uid 500); 2 Aug 2001 22:56:56 -0000 Date: Thu, 2 Aug 2001 15:56:56 -0700 From: Pat Calhoun To: "Hesham Soliman \(ERA\)" Cc: "'Pat Calhoun '" , "''mobile-ip@sunroof.eng.sun.com ' '" , "''James.Kempf@Sun.COM ' '" , "''charliep@iprg.nokia.com ' '" Subject: [mobile-ip] Re: So what is bicasting vs. buffering Message-ID: <20010802155656.K20321@charizard.diameter.org> References: <034BEFD03799D411A59F00508BDF754603008BA2@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: <034BEFD03799D411A59F00508BDF754603008BA2@esealnt448.al.sw.ericsson.se>; from Hesham.Soliman@era.ericsson.se on Fri, Aug 03, 2001 at 12:40:51AM +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: ok, so then the options are: 1. mobile initiated (mn signalling over the air) 2. network initiated (no over the air signalling) and 1. don't buffer on NewAR 2. buffer on NewAR So, it is always bicasting, but some proposals use different mixes of the alternatives above. PatC On Fri, Aug 03, 2001 at 12:40:51AM +0200, Hesham Soliman (ERA) wrote: > > So in my mind, I believe that the main difference between the bicasting > and buffering approaches is simply that the latter requires the mobile > to *request* packets. > > Am I right? > > => Not at all :) > The proposal that Charlie mentioned IS bicasting > that is the point I'm trying to make. > I don't understand why people assume that if you bicast > then by definition you can't buffer. You can > delay packets destined to the new AR/FA based on some > calculations of the average time for a handover. > > In addition you can bicast without a request from the > MN (ie. by default in the AR). > However, if you say I will send packets to the MN > at the current AR and send another copy to the new > AR then you ARE bicasting but just don't want to > say the word :)))))))) > It doesn't matter how long you buffer or delay the > packets destined to the new AR you are still sending > TWO copies. > > There are hidden assumptions if you do it by default > in the AR though (without the MN's request). The > assumption is that you know when the MN disconnects. > This is not generic of course so you still need > to allow for the option of the MN requesting bicasting. > > > Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 2 19: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 TAA00301 for ; Thu, 2 Aug 2001 19:18:15 -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 RAA10012; Thu, 2 Aug 2001 17:19:01 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA05182; Thu, 2 Aug 2001 16:18:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f72NHp422103 for mobile-ip-dist; Thu, 2 Aug 2001 16:17: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+Sun/8.11.5) with ESMTP id f72NHmD22096 for ; Thu, 2 Aug 2001 16:17:48 -0700 (PDT) Received: from awe171-106 (awe195-135.AWE.Sun.COM [192.29.195.135]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id QAA09770; Thu, 2 Aug 2001 16:17:49 -0700 (PDT) Message-Id: <200108022317.QAA09770@heliopolis.eng.sun.com> Date: Thu, 2 Aug 2001 16:08:51 -0700 (PDT) From: kempf Subject: Re: [mobile-ip] Re: So what is bicasting vs. buffering To: Hesham.Soliman@era.ericsson.se, mobile-ip@sunroof.eng.sun.com Cc: pcalhoun@diameter.org, mobile-ip@sunroof.eng.sun.com, James.Kempf@Sun.COM, charliep@iprg.nokia.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: xdKOnS9wtCEdFXX9Wet53A== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 i86pc i386 Sender: owner-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, >ok, so then the options are: > >1. mobile initiated (mn signalling over the air) >2. network initiated (no over the air signalling) > >and > >1. don't buffer on NewAR >2. buffer on NewAR > >So, it is always bicasting, but some proposals use different mixes >of the alternatives above. 1-2 is not exclusive. In FMIPv6, new AR discovers the handover is happening via HI/HACK, so you could buffer on new AR even if the handover is mobile initiated. In low latency MIPv4, you would have to buffer on old FA 'cause there is no HI/HACK required unless you optionally do a HRqst/HRply to inform new FA. As to whether there is bicasting or not, if you buffer on old AR as recommended in draft-krishnamurthi..., you don't have to bicast. You just buffer on old AR until the mobile sends an over the air BU to old AR, then the mobile gets the buffer. No packets are sent through new AR until the mobile is done establishing its new CoA. jak From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 2 20: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 UAA02383 for ; Thu, 2 Aug 2001 20:00: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 OAA02493; Thu, 2 Aug 2001 14:49: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 NAA01559; Thu, 2 Aug 2001 13:49:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f72KmKZ20687 for mobile-ip-dist; Thu, 2 Aug 2001 13:48:20 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f72KmGD20680 for ; Thu, 2 Aug 2001 13:48:17 -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 NAA03577 for ; Thu, 2 Aug 2001 13:48:19 -0700 (PDT) Message-Id: <200108022048.NAA03577@heliopolis.eng.sun.com> Date: Thu, 2 Aug 2001 13:48:11 -0700 (PDT) From: James Kempf Subject: [mobile-ip] Re: 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: tPK1kzGeAp2LBDbNZeioBQ== 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: Erik Nordmark posted a note earlier this week pointing out that the formula I sent out was the total time over which incoming packets are delayed, not the delay experienced by an individual packet. My response was that the figure of merit of interest was the delay experienced by the user. Upon further reflection, I realized Erik's point. The user experience will, in fact, depend on the delay experienced by an individual packet. If a voice packet from the CN is delayed by 100 ms, then the user will perceive a gap in the converstation. The importance of the formula I sent out (R = T(0) / (1 - A/B)) is that it gives the total amount of time during which buffering is occuring. The fraction of that total amount during which the per packet delay is greater than the user perceivable delay indicates how long the user must wait until the conversation no longer sounds stilted. If that amount of time is short, then there is a short blip. If it is long, then the user ends up in a half duplex conversation. So R reflects how long the buffering latency from handover will propagate. IMHO, this alters the conclusions for buffering only a little. The handover latency will still propagate, but as long as the handover delay is less than the user perceivable amount, the latency will not be noticable. If it is greater, then either there will be a short blip (if the latency is small) or the user will have a half duplex converstation for a period with a duration depending on how long it takes the buffering series to move below the perception threshold. In any event, since the bound is pretty tight, it will be difficult to meet it if there is any L3 latency in handover. jak From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 2 20:30: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 UAA03758 for ; Thu, 2 Aug 2001 20:30: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 PAA18380; Thu, 2 Aug 2001 15:53: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 OAA16810; Thu, 2 Aug 2001 14:53:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f72LqaT21128 for mobile-ip-dist; Thu, 2 Aug 2001 14:52:36 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f72LqXD21121 for ; Thu, 2 Aug 2001 14:52: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 OAA16628 for ; Thu, 2 Aug 2001 14:52: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 PAA17341 for ; Thu, 2 Aug 2001 15:52:19 -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 f72LqKN11551 for ; Thu, 2 Aug 2001 23:52:20 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Thu Aug 02 23:52:19 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Thu, 2 Aug 2001 23:52:18 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008B9E@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Charles E. Perkins '" , "'mobile-ip@sunroof.eng.sun.com '" Subject: RE: [mobile-ip] Analysis of Latency Propagation with Buffering Date: Thu, 2 Aug 2001 23:52:13 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) List-Subscribe: List-Unsubscribe: Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hello Charlie, > 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, ^^^^^^^^delayed before reception > and the more likely users will perceive the converstation as stilted > or hear some artifact. I wanted to clarify that it isn't buffering itself that adds delay. A packet could be buffered AND transmitted to the mobile node at the same time, which then would show that buffering does not have to introduce any delay. => And that is not bicasting ??! Hesham If a packet is received by the mobile node, then presumably it would prefer not to receive the buffered copy of that packet at any time in the future. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 2 22:12: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 WAA10407 for ; Thu, 2 Aug 2001 22:12:39 -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 UAA08746; Thu, 2 Aug 2001 20:13: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 TAA08920; Thu, 2 Aug 2001 19:12:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f732A0d22495 for mobile-ip-dist; Thu, 2 Aug 2001 19:10:00 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7329bD22441 for ; Thu, 2 Aug 2001 19:09:37 -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 TAA15404 for ; Thu, 2 Aug 2001 19:09:40 -0700 (PDT) Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA08005 for ; Thu, 2 Aug 2001 19:09:40 -0700 (PDT) Received: from postoffice.sarnoff.com ([127.0.0.1]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with SMTP id GHGYI500.ICW for ; Thu, 2 Aug 2001 21:51:41 -0400 Received: from nova.sarnoff.com ([130.33.8.27]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with ESMTP id GH5D3L00.D1T; Fri, 27 Jul 2001 15:35:45 -0400 Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id JAA00410; Fri, 27 Jul 2001 09:23:17 -0400 (EDT) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id JAA14407 for ietf-123-outbound.05@ietf.org; Fri, 27 Jul 2001 09:05: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 HAA12875 for ; Fri, 27 Jul 2001 07:07:49 -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 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 Thu Aug 2 22:13: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 WAA10542 for ; Thu, 2 Aug 2001 22:13: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 TAA07938; Thu, 2 Aug 2001 19:14: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 TAA09080; Thu, 2 Aug 2001 19:13:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7329vv22494 for mobile-ip-dist; Thu, 2 Aug 2001 19:09:58 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7329cD22446 for ; Thu, 2 Aug 2001 19:09: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 TAA28254 for ; Thu, 2 Aug 2001 19:09:41 -0700 (PDT) Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA08013 for ; Thu, 2 Aug 2001 19:09:40 -0700 (PDT) Received: from postoffice.sarnoff.com ([127.0.0.1]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with SMTP id GHGYI800.0CQ for ; Thu, 2 Aug 2001 21:51:44 -0400 Received: from nova.sarnoff.com ([130.33.8.27]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with ESMTP id GH5D6R00.02C; Fri, 27 Jul 2001 15:37:39 -0400 Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id JAA00039; Fri, 27 Jul 2001 09:11:02 -0400 (EDT) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id IAA14266 for ietf-123-outbound.05@ietf.org; Fri, 27 Jul 2001 08:55: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 HAA12868 for ; Fri, 27 Jul 2001 07:07:46 -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 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 Thu Aug 2 22:13: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 WAA10581 for ; Thu, 2 Aug 2001 22:13: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 UAA09594; Thu, 2 Aug 2001 20:14:31 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA09056; Thu, 2 Aug 2001 19:13:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f732A1H22497 for mobile-ip-dist; Thu, 2 Aug 2001 19:10:01 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7329dD22450 for ; Thu, 2 Aug 2001 19:09: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 TAA28262 for ; Thu, 2 Aug 2001 19:09:41 -0700 (PDT) Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA08020 for ; Thu, 2 Aug 2001 19:09:41 -0700 (PDT) Received: from postoffice.sarnoff.com ([127.0.0.1]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with SMTP id GHGYUI00.9DM for ; Thu, 2 Aug 2001 21:59:06 -0400 Received: from nova.sarnoff.com ([130.33.8.27]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with ESMTP id GH5OXZ00.EB3; Fri, 27 Jul 2001 19:51:35 -0400 Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id LAA04869; Wed, 25 Jul 2001 11:56:57 -0400 (EDT) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id LAA29636 for ietf-123-outbound.05@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 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 Fri Aug 3 00:10: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 AAA16922 for ; Fri, 3 Aug 2001 00:10: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 VAA28618; Thu, 2 Aug 2001 21:11: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 VAA19840; Thu, 2 Aug 2001 21:11:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7349tp23337 for mobile-ip-dist; Thu, 2 Aug 2001 21:09:55 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7349qD23330 for ; Thu, 2 Aug 2001 21:09:52 -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 VAA08708 for ; Thu, 2 Aug 2001 21:09:54 -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 WAA19807 for ; Thu, 2 Aug 2001 22:09:51 -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 f7349S918423 for ; Fri, 3 Aug 2001 00:09:28 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Fri, 3 Aug 2001 00:09:40 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 3 Aug 2001 00:09:43 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5EC9@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'mobile-ip@sunroof.eng.sun.com'" , "Hesham Soliman (ERA)" Cc: "''James.Kempf@Sun.COM ' '" , "''charliep@iprg.nokia.com ' '" Subject: RE: [mobile-ip] Re: So what is bicasting vs. buffering Date: Fri, 3 Aug 2001 00:09:49 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C11BD2.233A25E0" 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_01C11BD2.233A25E0 Content-Type: text/plain; charset="iso-8859-1" Interesting discussion. But it seems to me that there is something missing with the distinguishment being drawn between "buffering" and "bicasting". It may be subtle, but here goes: To me, when you buffer something you explicitly store it for future forwarding. This would be in addition to any usually queuing delay. The idea behind bicasting is to forward the packets as soon as possible after they arrive. To make the distinction real, if the stream in question is EF, bicasting would maintain the forwarding delay bounds at both ARs. What happens the packets after they are forwarded is a different issue, and related to the discusson about dropped vs duplicated packets. When you buffer the EF stream, by my interpretation, are unlikely to fulfill a realistic EF bound, because you are buffering simply to hold the packets for future delivery, which adds delay, period. I realize I could be opening up a few bulk size cans of worms here. To me, the reason you bicast is to avoid delaying packets. I personally do not see duplicates as evil (but they must be removed at the reciever, and not by TCP - at least, the existing TCP). Gary -----Original Message----- From: Pat Calhoun [mailto:pcalhoun@diameter.org] Sent: August 2, 2001 18:57 To: Hesham Soliman (ERA) Cc: 'Pat Calhoun '; ''mobile-ip@sunroof.eng.sun.com ' '; ''James.Kempf@Sun.COM ' '; ''charliep@iprg.nokia.com ' ' Subject: [mobile-ip] Re: So what is bicasting vs. buffering ok, so then the options are: 1. mobile initiated (mn signalling over the air) 2. network initiated (no over the air signalling) and 1. don't buffer on NewAR 2. buffer on NewAR So, it is always bicasting, but some proposals use different mixes of the alternatives above. PatC On Fri, Aug 03, 2001 at 12:40:51AM +0200, Hesham Soliman (ERA) wrote: > > So in my mind, I believe that the main difference between the bicasting > and buffering approaches is simply that the latter requires the mobile > to *request* packets. > > Am I right? > > => Not at all :) > The proposal that Charlie mentioned IS bicasting > that is the point I'm trying to make. > I don't understand why people assume that if you bicast > then by definition you can't buffer. You can > delay packets destined to the new AR/FA based on some > calculations of the average time for a handover. > > In addition you can bicast without a request from the > MN (ie. by default in the AR). > However, if you say I will send packets to the MN > at the current AR and send another copy to the new > AR then you ARE bicasting but just don't want to > say the word :)))))))) > It doesn't matter how long you buffer or delay the > packets destined to the new AR you are still sending > TWO copies. > > There are hidden assumptions if you do it by default > in the AR though (without the MN's request). The > assumption is that you know when the MN disconnects. > This is not generic of course so you still need > to allow for the option of the MN requesting bicasting. > > > Hesham ------_=_NextPart_001_01C11BD2.233A25E0 Content-Type: text/html; charset="iso-8859-1" RE: [mobile-ip] Re: So what is bicasting vs. buffering

Interesting discussion.

But it seems to me that there is something missing with the
distinguishment being drawn between "buffering" and "bicasting".
It may be subtle, but here goes: To me, when you buffer something
you explicitly store it for future forwarding. This would be in
addition to any usually queuing delay. The idea behind bicasting
is to forward the packets as soon as possible after they arrive.

To make the distinction real, if the stream in question is EF,
bicasting would maintain the forwarding delay bounds at both ARs.
What happens the packets after they are forwarded is a different issue,
and related to the discusson about dropped vs duplicated packets.
When you buffer the EF stream, by my interpretation, are unlikely to
fulfill a realistic EF bound, because you are buffering simply to hold
the packets for future delivery, which adds delay, period.

I realize I could be opening up a few bulk size cans of worms here.
To me, the reason you bicast is to avoid delaying packets. I personally
do not see duplicates as evil (but they must be removed at the reciever,
and not by TCP - at least, the existing TCP).

Gary

-----Original Message-----
From: Pat Calhoun [mailto:pcalhoun@diameter.org]
Sent: August 2, 2001 18:57
To: Hesham Soliman (ERA)
Cc: 'Pat Calhoun '; ''mobile-ip@sunroof.eng.sun.com ' ';
''James.Kempf@Sun.COM ' '; ''charliep@iprg.nokia.com ' '
Subject: [mobile-ip] Re: So what is bicasting vs. buffering


ok, so then the options are:

1. mobile initiated (mn signalling over the air)
2. network initiated (no over the air signalling)

and

1. don't buffer on NewAR
2. buffer on NewAR

So, it is always bicasting, but some proposals use different mixes
of the alternatives above.

PatC
On Fri, Aug 03, 2001 at 12:40:51AM +0200, Hesham Soliman  (ERA) wrote:
> 
> So in my mind, I believe that the main difference between the bicasting
> and buffering approaches is simply that the latter requires the mobile
> to *request* packets.
>
> Am I right?
>
> => Not at all :)
> The proposal that Charlie mentioned IS bicasting
> that is the point I'm trying to make.
> I don't understand why people assume that if you bicast
> then by definition you can't buffer. You can
> delay packets destined to the new AR/FA based on some
> calculations of the average time for a handover.
>
> In addition you can bicast without a request from the
> MN (ie. by default in the AR).
> However, if you say I will send packets to the MN
> at the current AR and send another copy to the new
> AR then you ARE bicasting but just don't want to
> say the word :))))))))
> It doesn't matter how long you buffer or delay the
> packets destined to the new AR you are still sending
> TWO copies.
>
> There are hidden assumptions if you do it by default
> in the AR though (without the MN's request). The
> assumption is that you know when the MN disconnects.
> This is not generic of course so you still need
> to allow for the option of the MN requesting bicasting.
>
>
> Hesham

------_=_NextPart_001_01C11BD2.233A25E0-- From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 3 02:08: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 CAA05762 for ; Fri, 3 Aug 2001 02:08: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 XAA17430; Thu, 2 Aug 2001 23:09: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 XAA05695; Thu, 2 Aug 2001 23:08:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7367KX23576 for mobile-ip-dist; Thu, 2 Aug 2001 23:07:20 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.82.166] (may be forged)) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7367GD23569 for ; Thu, 2 Aug 2001 23:07:17 -0700 (PDT) Received: from teknoturk (dsl197-130.Eng.Sun.COM [129.146.197.130]) by jurassic.eng.sun.com (8.11.5+Sun/8.11.5) with SMTP id f7367Gb789943 for ; Thu, 2 Aug 2001 23:07:17 -0700 (PDT) From: "Alper" To: Subject: RE: [mobile-ip] BETH comments and questions Date: Thu, 2 Aug 2001 22:56:22 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <200108011704.KAA03023@heliopolis.eng.sun.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 Hi Jim, My response inlined... (sorry, late) > >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. > > > > This not strictly accurate. It takes out the signaling at L3. > There is still > signaling at L2. The MN must know when it comes up on the new > link, and what the L2 address of its router is, otherwise it can't > get packets out. Yes, L2 signals are there. But those signals don't reveal whether there's BETH going on between ARs or not. And I think MN should know this (see below). > > >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. > > > > I'm not sure I understand your example. Perhaps you have > identified a problem > here, but lacking more detail, I can't see it. If a situation > happens as you identify it, the MN can begin establishing a new CoA > at any time. As soon as the new AR detects that the MN has completed > this, it signals the old AR via a HRqst to tear down the tunnel. If > the MN succeeds in getting a new CoA on old AR, old AR simply doesn't > tunnel. My scenario, and question, is what should "a" MN do after it detects the movement at L2? Should it wait in the expectation that ARs are performing BETH in between and MN will start receiving packet sent to oldCoA? Since there's no L3 signalling between ARs and the MN, MN cannot know that. Or, should it attempt stock MIPv6 handoff (DAD, newCoA, which will delay transmission from MN). > > In general, BETH is not proposing to replace > or otherwise negate the existing handover mechanisms, just to augment > them. If the MN discovers a router, it is perfectly free to perform > a standard FMIPv6 handover, or even a stock Johnson and Perkins > handover if it so chooses. The mobile node is completely in control > of when it decides to begin the process of obtaining a new CoA. That, > in fact, is the key differentator between BETH and both the > standard FMIPv6 > and Johnson and Perkins algorithms. These algorithms leave the MN no > choice, it *must* obtain a new CoA regardless of whether the process > would interrupt a real time flow. > > > >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? > > > > Well, this is a policy question and something that I don't think is > appropriate for the protocol draft. There maybe be some need in > particular situations to codify the interaction between BETH > and FMIPv6 more precisely if there is interference, if so, then > we need to > clarify it. We probably need to go through some protocol flows to > check this, similarly for the interaction between FMIPv6 and > the original Johnson and Perkins algorithm. BETH is no different > than standard > FMIPv6 or the original Johnson and Perkins algorithm in this > regard. Should a > router advertise if it is capable of FMIPv6 so that it can > suppress MIPv6? The end2end L3 signalling between MN and oldCoA reveals what's going on. F-BU, F-Back, ProxyRtAdv are all new signals that indicate what's going on. At any time both sides know what's going on, and can choose to fail it or proceed. > If so, then perhaps we need some policy knobs that let a network > administrator configure what type of handover they want to support, > and a way to communicate that to the MN when it enters the network. The problem for BETH would be, at the time MN attaches to "a" new L2 (newAR), how is it going to be notified of this information? Can't wait for a L3 message, as BETH relies on non-existence of such a message. > > >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? > > I'm not clear on exactly what you are proposing, but if I understand > you correctly, I think there are more open questions about how > a second interface would get used than BETH. For example, if an interface > is already configured with a global IPv6 address and a MIP CoA, then > there would need to be some process on the MN to cause that binding > to be transferred to the new interface. The global IPv6 address would > need to be transferred and there would need to be a new CoA on the > new interface (unless, of course, the new interface is on the > same subnet). > The Neighbor Caches on the routers need to be updated, to reflect the > new binding between the CoA and L2 address. This is naturally > going to require a > certain amount of radio traffic, and so it is not appropriate for > BETH handover > to be used in this situation. BETH is only for extremely time > critical handover, > such as is involved in real time traffic. Before we start discussing > how to handle interaction between BETH and a MN with two interfaces, > I think we need a better understanding of how a MN with two interfaces > would perform a standard MIPv6 handover between them. They can do "forwarding from previous care-of address" as specified in MIPv6, I think. Let me try to explain my example (it wasn't clear, I admit). MN has interface1, attached to oldAR. It also has another interface, interface2. While oldAR and newAR decides to perform BETH for interface1, MN might decide to do a "forwarding from previous care-of address" between oldAR and thirdAR. Since MN doesn't know BETH is happening, it's very well possible that it does its own thing. So, I think we should define what happens if oldAR is in the middle of BETH and it receives a BU from MN. > > >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. > > > > The signal should be the BACK from the HA and any CNs, because it > is only at > that point when the new CoA can really be used. The ARs tear down > the tunnel at this point, though they may keep it up for some > configurable time period in order to assure that any laggard packets > get to the MN. The draft should be more precise about this. Is this based on newAR sniffing the traffic and seeing a Back sent to MN? > > >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. > > > > As I mentioned, the MN is completely informed via L2 and is, in fact, > more in control than in FMIPv6. In BETH, the MN can choose to use > the standard FMIPv6 algorithm, where it gets to choose which > router it wants, etc. *And* it gets to choose when to establish > a new CoA. With FMIPv6, it only gets the first. I agree with you on when to configure the CoA. But in BETH, somebody is doing a L3-ish handoff on behalf of MN, and MN doesn't even know this. > > > > >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. > > > > Delay occurs when the radio link is used for anything other than > real time traffic, regardless if it occurs on the old link or the new. > On a 9.6 Kbps radio link (currently used for 2.5G cellular voice), > signalling traffic on the dedicated traffic channel will block any other > traffic. Cellular protocols currently use the dedicated traffic > channel for IP signalling. One could imagine using the dedicated > signalling channel for IP signalling, and that would help to free the > traffic channel since the IP signalling can go on in parallel, but > even then the signalling channels tend to be substantially slower > than the traffic channels (I think wCDMA uses 3 Kbps if I remember > correctly), so there is the potential that a MN could start the > process of obtaining a new CoA by anticipation and end up moving > to a new access router before it actually had the new CoA. BETH would > handle this smoothly, so I think there is a place for it even > if IP signalling traffic moves to a dedicated channel. Not to mention: > moving IP signalling traffic to a dedicated signalling channel > would require > the 3Gs to actually modify their air interface, something difficult > and time consuming to do. OK, I see. Sending L3 signalling is blocking data transmission. I understand. This is the latency of transmiting the packet, not the latency for delivery. > > >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. > > > > > > My understanding from reading the FMIPv6 draft is that the F-NA is > what triggers the process of Neighbor Cache update at new AR, DAD, > and all the other good but time consuming stuff involved in > getting an IPv6 host up on a new subnet. Is that not so? F-NA can be replaced by a L2 trigger. Maybe we should clarify this better in FMIPv6. The information needed for neighbor cache is already in HI message. All newAR needs is an indication of arrival. > > Note that these calculations do not consider the BU/BACK from > the HA nor from CNs. If you add those into the picture, you > get considerably more time until the new CoA can be used. In that > sense, the > calculations are very optimistic, and for all but the first > scenario consider > that the MN will be using its old CoA on the new AR just like > in BETH (considered a corner case in the original FMIPv6). Once MN has a tunnel from oldAR to newCoA, it doesn't have to wait for BU/BACk from CN/HA. Packets sent to oldCoA will be tunneled. MN can use newCoA as its source address in the outgoing traffic. > > >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? > > > > As mentioned above, the tunnel should be kept up until all BU/BACK from > the HA and CNs have arrived, and perhaps even remain up for > a short period after to catch any laggard packets. It is only at > that point that the MN can begin to reliably send and receive > packets on the new > CoA. But this BAck arrival happens at the MN, right? Not at newAR. So, how does newAR know this? Sniffing on the network? > > > > >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. > > > > Alper, everything that involves radio traffic not related specifically > to applications running on the MN has a latency cost and is pure > overhead. I see. It's my misunderstanding. This is the transmission latency, not delivery. You are right. > Everything. At 9.6 Kbps, it takes 1.2 ms to send a byte. If the > byte is in a > mobile IP packet, or a routing advertisement, or anything other > than a packet involved in the application, that is 1.2 ms that > is not available for sending application data. If the application > is a real time application, you can only get away with sending > overhead for an extremely short time before the user notices. The > only way to > get around this is to either do the signalling on a separate channel or > crank up the speed of the radio link (if you can, wCDMA allows > this, cdma2000 doesn't). That's why the 3G radio protocols have > separate signalling channels in the first place, unfortunately, we > don't get to use them. > > I agree that we need to do some protocol flows to identify the interaction > between BETH, standard FMIPv6 and the original Johnson and > Perkins algorithm. > These flows should identify whether there are any situations in which > there is need for some additional work to allow suppression or switchover, > or perhaps specification about what the ARs and MN should or > should not do > in particular windows. I don't think, however, that BETH is any > different from > the other two algorithms in this regard. > > jak alper > From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 3 04: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 EAA09606 for ; Fri, 3 Aug 2001 04:57: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 BAA26289; Fri, 3 Aug 2001 01:57:45 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA26000; Fri, 3 Aug 2001 01:57:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f738t3s23842 for mobile-ip-dist; Fri, 3 Aug 2001 01:55:03 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f738sfD23803 for ; Fri, 3 Aug 2001 01:54: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 BAA25849 for ; Fri, 3 Aug 2001 01:54:44 -0700 (PDT) Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA27200 for ; Fri, 3 Aug 2001 02:54:41 -0600 (MDT) Received: from postoffice.sarnoff.com ([127.0.0.1]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with SMTP id GHHF9T00.QP5 for ; Fri, 3 Aug 2001 03:53:53 -0400 Received: from nova.sarnoff.com ([130.33.8.27]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with ESMTP id GH5OXZ00.EB3; Fri, 27 Jul 2001 19:51:35 -0400 Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id LAA04869; Wed, 25 Jul 2001 11:56:57 -0400 (EDT) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id LAA29636 for ietf-123-outbound.05@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 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 Fri Aug 3 04:57: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 EAA09628 for ; Fri, 3 Aug 2001 04:57: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 BAA26284; Fri, 3 Aug 2001 01:57: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 BAA26018; Fri, 3 Aug 2001 01:57:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f738t3W23841 for mobile-ip-dist; Fri, 3 Aug 2001 01:55:03 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f738seD23800 for ; Fri, 3 Aug 2001 01:54:40 -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 BAA13301 for ; Fri, 3 Aug 2001 01:54:43 -0700 (PDT) Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA27181 for ; Fri, 3 Aug 2001 02:54:38 -0600 (MDT) Received: from postoffice.sarnoff.com ([127.0.0.1]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with SMTP id GHHF4N00.VQH for ; Fri, 3 Aug 2001 03:50:47 -0400 Received: from nova.sarnoff.com ([130.33.8.27]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with ESMTP id GH5D6R00.02C; Fri, 27 Jul 2001 15:37:39 -0400 Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id JAA00039; Fri, 27 Jul 2001 09:11:02 -0400 (EDT) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id IAA14266 for ietf-123-outbound.05@ietf.org; Fri, 27 Jul 2001 08:55: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 HAA12868 for ; Fri, 27 Jul 2001 07:07:46 -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 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 Aug 3 05:01: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 FAA09934 for ; Fri, 3 Aug 2001 05:01: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 CAA27957; Fri, 3 Aug 2001 02:01: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 BAA26038; Fri, 3 Aug 2001 01:57:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f738svW23840 for mobile-ip-dist; Fri, 3 Aug 2001 01:54:57 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f738sbD23787 for ; Fri, 3 Aug 2001 01:54: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 BAA13296 for ; Fri, 3 Aug 2001 01:54:40 -0700 (PDT) Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA27169 for ; Fri, 3 Aug 2001 02:54:37 -0600 (MDT) Received: from postoffice.sarnoff.com ([127.0.0.1]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with SMTP id GHHF4M00.PQJ for ; Fri, 3 Aug 2001 03:50:46 -0400 Received: from nova.sarnoff.com ([130.33.8.27]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with ESMTP id GH5D3L00.D1T; Fri, 27 Jul 2001 15:35:45 -0400 Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id JAA00410; Fri, 27 Jul 2001 09:23:17 -0400 (EDT) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id JAA14407 for ietf-123-outbound.05@ietf.org; Fri, 27 Jul 2001 09:05: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 HAA12875 for ; Fri, 27 Jul 2001 07:07:49 -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 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 Aug 3 09:57: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 JAA16230 for ; Fri, 3 Aug 2001 09:57:30 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA17329; Fri, 3 Aug 2001 07:57:59 -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 GAA09749; Fri, 3 Aug 2001 06:57:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f73Dtll24955 for mobile-ip-dist; Fri, 3 Aug 2001 06:55:47 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f73DthD24948 for ; Fri, 3 Aug 2001 06:55: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 GAA05624 for ; Fri, 3 Aug 2001 06:55:44 -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 HAA27030 for ; Fri, 3 Aug 2001 07:55:42 -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 PAA27258; Fri, 3 Aug 2001 15:55:39 +0200 (MET DST) Message-ID: <3B6AAE5D.300C14AC@ipsi.fraunhofer.de> Date: Fri, 03 Aug 2001 15:59:57 +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] Re: So what is bicasting vs. buffering References: <9FBD322B7824D511B36900508BF93C9C9F5EC9@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: > > Interesting discussion. I agree (and usually regret that, since I live in a different time zone, it is hard for me to synchronize with such discussions). > > But it seems to me that there is something missing with the > distinguishment being drawn between "buffering" and "bicasting". > It may be subtle, but here goes: To me, when you buffer something > you explicitly store it for future forwarding. This would be in > addition to any usually queuing delay. The idea behind bicasting > is to forward the packets as soon as possible after they arrive. > > To make the distinction real, if the stream in question is EF, > bicasting would maintain the forwarding delay bounds at both ARs. > What happens the packets after they are forwarded is a different issue, > and related to the discusson about dropped vs duplicated packets. > When you buffer the EF stream, by my interpretation, are unlikely to > fulfill a realistic EF bound, because you are buffering simply to hold > the packets for future delivery, which adds delay, period. Please remember that mobility means to change connectivity. Hence, it may simply the case that, when your data arrive at the (old or new) access router, the link is just down. You can nothing do but buffering in the hope that the link will come up again. > > I realize I could be opening up a few bulk size cans of worms here. > To me, the reason you bicast is to avoid delaying packets. I personally > do not see duplicates as evil (but they must be removed at the reciever, > and not by TCP - at least, the existing TCP). > > Gary For a better understanding of the problem, I practiced a little bit with Charlie Perkin's pizzas (in Phil Neumiller's business model, with slight modifications). And I arrived at: 1. Bicasting may make sense without buffering. 2. Buffering may make sense without Bicasting. 3. Both may complement each other. Assume that you have to serve one pizza P to one dignitary D which moves through your city. The city is ful of your kiosks where you can deliver P within a certain range. If you know D's itinerary in advance and where she will be when, you can do some (not easy) computations for timely delivery, taking speed both of P and D into account. Neither bicasting nor buffering is needed. Now assume that you only know the itinerary. If the delivery ranges of kiosks along the itinerary overlap, you may multicast P along it. If all copies of P arrive at their respective kiosk at one and the same time, then at least one copy reaches D in time, i.e. without buffering. Hence 1. If delivery ranges do not overlap, you have to both multicast and buffer. Hence 3. Finally, assume that you only know for sure one kiosk where D will pass by. Then you unicast P there, and it has to be buffered. Hence 2. Note that the latter case seems quite common whereas 1. is rather artificial. Does this help? Did I make a mistake? I never delivered a single pizza... 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 Fri Aug 3 11:49: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 LAA19021 for ; Fri, 3 Aug 2001 11: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 IAA05201; Fri, 3 Aug 2001 08:50:04 -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 IAA20979; Fri, 3 Aug 2001 08:47:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f73Fjsm25219 for mobile-ip-dist; Fri, 3 Aug 2001 08:45:54 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f73FjpD25212 for ; Fri, 3 Aug 2001 08:45: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 IAA27583 for ; Fri, 3 Aug 2001 08:45:51 -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 IAA20891 for ; Fri, 3 Aug 2001 08:45:47 -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 f73FhkN03984 for ; Fri, 3 Aug 2001 17:43:46 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Fri Aug 03 17:43:40 2001 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 3 Aug 2001 17:37:24 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008BA3@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Pat Calhoun '" , "Hesham Soliman (ERA)" Cc: "'''mobile-ip@sunroof.eng.sun.com ' ' '" , "'''James.Kempf@Sun.COM ' ' '" , "'''charliep@iprg.nokia.com ' ' '" Subject: [mobile-ip] RE: So what is bicasting vs. buffering Date: Fri, 3 Aug 2001 17:43:37 +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: ok, so then the options are: 1. mobile initiated (mn signalling over the air) 2. network initiated (no over the air signalling) and 1. don't buffer on NewAR 2. buffer on NewAR So, it is always bicasting, but some proposals use different mixes of the alternatives above. => Exactly. As for (1) above, I certainly prefer it (or strongly propose) that we work within the current Fast Handovers draft. Ie. The MN signals before moving. Signalling after the movement would imply an unnecessary RTT to release the buffers. In addition I don't think we need a buffer management protocol. The calculation of buffer sizes and release ...etc should be left to the oAR (or nAR if needed). Hesham PatC On Fri, Aug 03, 2001 at 12:40:51AM +0200, Hesham Soliman (ERA) wrote: > > So in my mind, I believe that the main difference between the bicasting > and buffering approaches is simply that the latter requires the mobile > to *request* packets. > > Am I right? > > => Not at all :) > The proposal that Charlie mentioned IS bicasting > that is the point I'm trying to make. > I don't understand why people assume that if you bicast > then by definition you can't buffer. You can > delay packets destined to the new AR/FA based on some > calculations of the average time for a handover. > > In addition you can bicast without a request from the > MN (ie. by default in the AR). > However, if you say I will send packets to the MN > at the current AR and send another copy to the new > AR then you ARE bicasting but just don't want to > say the word :)))))))) > It doesn't matter how long you buffer or delay the > packets destined to the new AR you are still sending > TWO copies. > > There are hidden assumptions if you do it by default > in the AR though (without the MN's request). The > assumption is that you know when the MN disconnects. > This is not generic of course so you still need > to allow for the option of the MN requesting bicasting. > > > Hesham From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 3 12:37: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 MAA20246 for ; Fri, 3 Aug 2001 12:37: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 JAA26061; Fri, 3 Aug 2001 09:38: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 JAA27244; Fri, 3 Aug 2001 09:36:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f73GZJ925422 for mobile-ip-dist; Fri, 3 Aug 2001 09:35:19 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f73GZFD25415 for ; Fri, 3 Aug 2001 09:35:15 -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 JAA26887 for ; Fri, 3 Aug 2001 09:34: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 KAA13252 for ; Fri, 3 Aug 2001 10:34:32 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA08074; Fri, 3 Aug 2001 09:34:34 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f73GYXg30954; Fri, 3 Aug 2001 09:34:33 -0700 X-mProtect: Fri, 3 Aug 2001 09:34:33 -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 smtpddV2RFh; Fri, 03 Aug 2001 09:34:32 PDT Message-ID: <3B6AD298.D237D602@iprg.nokia.com> Date: Fri, 03 Aug 2001 09:34:32 -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 (ERA)" CC: Mobile IP Working Group Subject: [mobile-ip] Re: So what is bicasting vs. buffering References: <034BEFD03799D411A59F00508BDF754603008BA3@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 et al., > ok, so then the options are: > > 1. mobile initiated (mn signalling over the air) > 2. network initiated (no over the air signalling) Isn't it possible for a network initiated handover to utilize signalling over the air to tell the mobile node to get moving? > and > > 1. don't buffer on NewAR > 2. buffer on NewAR Buffering at the OldAR should be an allowed option. > > So, it is always bicasting, but some proposals use different mixes > of the alternatives above. > > => Exactly. As for (1) above, I certainly prefer it > (or strongly propose) that we work within the current > Fast Handovers draft. Ie. The MN signals before > moving. Signalling after the movement would imply an > unnecessary RTT to release the buffers. This is great as long as it is possible. However, for some systems it may not be possible, and I don't see any reason to _restrict_ the smoothing request so that it could never be issued from the new AR. > In addition I don't think we need a buffer management > protocol. The calculation of buffer sizes and > release ...etc should be left to the oAR (or nAR if > needed). Unfortunately, the details about how much to buffer and so on are application dependent, and not able to be reliably calculated by the access routers. There should probably be a default minimum capability, agreed. Furthermore, buffering should be done without request only when it isn't being charged for, and when doing so doesn't affect the ability to offer buffering for other customers who might really need it. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 3 12:44: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 MAA20402 for ; Fri, 3 Aug 2001 12:44: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 KAA21101; Fri, 3 Aug 2001 10:44: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 JAA28637; Fri, 3 Aug 2001 09:43:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f73Gggt25491 for mobile-ip-dist; Fri, 3 Aug 2001 09:42:42 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f73GgaD25484 for ; Fri, 3 Aug 2001 09:42:36 -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 JAA01621 for ; Fri, 3 Aug 2001 09:42:36 -0700 (PDT) Received: from birch.ee.vt.edu (birch.ee.vt.edu [128.173.88.34]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA19366 for ; Fri, 3 Aug 2001 10:42:28 -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 MAA21759; Fri, 3 Aug 2001 12:42:28 -0400 (EDT) Received: (from wells@localhost) by eagle.ee.vt.edu (8.10.2+Sun/8.10.2) id f73GgS113114; Fri, 3 Aug 2001 12:42:28 -0400 (EDT) Date: Fri, 3 Aug 2001 12:42:28 -0400 From: John Wells To: mobile-ip@sunroof.eng.sun.com Cc: Charlie Perkins Subject: Re: [mobile-ip] Concerns about draft-mipv6-14 section 4.8 Message-ID: <20010803124227.H11736@horus.imag.fr> References: <3B65AD55.A3068A5E@inrialpes.fr> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="81JctsDUVPekGcy+" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B65AD55.A3068A5E@inrialpes.fr>; from thierry.ernst@inrialpes.fr on Mon, Jul 30, 2001 at 08:54:13PM +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: --81JctsDUVPekGcy+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Thierry, I've already responded to you personally, but I'll repeat them for the working group. Here are some reasons why a thoughtful analysis of mobile networking is needed: - How will network renumbering work? If the mobile network is a /64 and the visiting network only has a /64 allocated, how will this work? Ideally, the visiting network should be big enough to house the entire network, avoiding host level address changes. - Additionally, you raise this problem well, but I think it's worth emphasizing: how will the router be authenticated and authorized to send BUs for its nodes? How will it participate in site routing? ND and also IGP protocols such as RIPng, OSPF, etc. need to be analyzed. - Finally, you also discuss this in the requirements, but we need to explore multihoming possibilities, either with two mobile routers connected to an AR or one MR connected to two or more ARs or both. For these reasons, I think it would be premature to add mobile networking support a posteriori without further consideration of the problem. --John --=20 John WELLS Virginia Tech Networking and Visualization Lab PGP Public key: http://www.ee.vt.edu/~wells/pgpkey.txt --81JctsDUVPekGcy+ 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 iD8DBQE7atRztvPFKAfa3SIRAjDWAJ40xFvRg+KNjuuG6yHishbwI/JyCQCgkJ4u WJ56XCOv564231yb4Vzj9dA= =zSMV -----END PGP SIGNATURE----- --81JctsDUVPekGcy+-- From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 3 13:19: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 NAA22043 for ; Fri, 3 Aug 2001 13:19: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 LAA13245; Fri, 3 Aug 2001 11:14: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 KAA22936; Fri, 3 Aug 2001 10:12:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f73HAq725682 for mobile-ip-dist; Fri, 3 Aug 2001 10:10:52 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f73HAmD25672 for ; Fri, 3 Aug 2001 10:10: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 KAA22637 for ; Fri, 3 Aug 2001 10:10:49 -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 LAA22866 for ; Fri, 3 Aug 2001 11:10:37 -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 NAA21941 for ; Fri, 3 Aug 2001 13:10:36 -0400 (EDT) Received: (from wells@localhost) by eagle.ee.vt.edu (8.10.2+Sun/8.10.2) id f73HAaL13168 for mobile-ip@sunroof.eng.sun.com; Fri, 3 Aug 2001 13:10:36 -0400 (EDT) Date: Fri, 3 Aug 2001 13:10:36 -0400 From: John Wells To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] [mleech@nortelnetworks.com: Position statement on IKE development] Message-ID: <20010803131036.J11736@horus.imag.fr> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="iUV/lbBrmPtUT9dM" 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: --iUV/lbBrmPtUT9dM Content-Type: multipart/mixed; boundary="zH41lVBEV8cLJnCl" Content-Disposition: inline --zH41lVBEV8cLJnCl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable It's probably a good idea to go forward with a non-IPsec based solution, particularly in light of this news.. john --=20 John WELLS Virginia Tech Networking and Visualization Lab PGP Public key: http://www.ee.vt.edu/~wells/pgpkey.txt --zH41lVBEV8cLJnCl Content-Type: message/rfc822 Content-Disposition: inline Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by birch.ee.vt.edu (8.9.3/8.9.3) with ESMTP id WAA17587 for ; Thu, 2 Aug 2001 22:25:59 -0400 (EDT) Received: from horus.imag.fr (horus.imag.fr [129.88.38.2]) by imag.imag.fr (8.11.3/8.11.3) with ESMTP id f732Pow29664 for ; Fri, 3 Aug 2001 04:25:50 +0200 (MEST) Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by horus.imag.fr (8.11.3/8.11.3/ImagV2) with ESMTP id f732PpG20201 for ; Fri, 3 Aug 2001 04:25:52 +0200 (MET DST) Received: from above.proper.com (above.proper.com [208.184.76.39]) by imag.imag.fr (8.11.3/8.11.3) with ESMTP id f732Pkw29647 for ; Fri, 3 Aug 2001 04:25:47 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f731gMj04101 for ietf-ipsra-bks; Thu, 2 Aug 2001 18:42:22 -0700 (PDT) Received: from zcars0m9.ca.nortel.com ([47.129.242.157]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f731USs03932; Thu, 2 Aug 2001 18:30:28 -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 f731Tv911913; Thu, 2 Aug 2001 21:29:58 -0400 (EDT) Received: from rftzy232.ca.nortel.com by zcars04e.ca.nortel.com; Thu, 2 Aug 2001 21:30:17 -0400 Received: from nortelnetworks.com (acart13a.ca.nortel.com [47.129.8.153]) by rftzy232.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NKPL6BZ0; Thu, 2 Aug 2001 21:29:59 -0400 Message-ID: <3B69FF7B.85CF61@nortelnetworks.com> Date: Thu, 02 Aug 2001 21:33:47 -0400 From: "Marcus Leech" Organization: Nortel Networks: Information Systems X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19 i686) X-Accept-Language: en MIME-Version: 1.0 To: msec@securemulticast.org, ietf-ipsra@vpnc.org, ipsec-policy@vpnc.org, ipsec@lists.tislabs.com Subject: Position statement on IKE development Content-Type: multipart/mixed; boundary="------------700C1CE7C41A16595853A0C3" X-Orig: Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------700C1CE7C41A16595853A0C3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I'm sending the attached ASCII TEXT document on behalf of myself, Jeff Schiller, and Steve Bellovin, to clarify our position with respect to IKE development. It is our hope that it will clarify, to some extent, some fuzziness in this area that has evolved over the last year or so. --------------700C1CE7C41A16595853A0C3 Content-Type: text/plain; charset=us-ascii; name="statement.txt" Content-Disposition: inline; filename="statement.txt" Content-Transfer-Encoding: 7bit In the several years since the standardization of the IPSEC protocols (ESP, AH, and ISAKMP/IKE), there have come to light several security problems with the protocols, most notably the key-agreement protocol, IKE. Formal and semi-formal analyses by Meadows, Schneier et al, and Simpson, have shown that the security problems in IKE stem directly from its complexity. It seems only a matter of time before more analyses show more serious security issues in the protocol design that stem directly from its complexity. It seems also, only a matter of time, before serious *implementation* problems become apparent, again due to the complex nature of the protocol, and the complex implementation that must surely follow. Despite the obviously complex nature of IKE, several proposals have been put forward to extend ISAKMP/IKE in various ways, for various purposes. Proposals such as IKECFG, XAUTH, Hybrid-AUTH, CRACK, and others do nothing to improve the complexity situation with regard to IKE as a whole. While many of these proposals are, individually, based on sound engineering and reasonably prudent practice, when cast in the larger context of IKE, it seems clear that they can do nothing to improve the complexity picture. It is with that in mind that the Security Area directors in the IETF, with the consultation of appropriate people on the IESG and IAB, hereby place a temporary moratorium on the addition of new features to IKE. It is fairly clear that work on IKE should focus on fixing identified weaknesses in the protocol, rather than adding features that detract from the goal of simplicity and correctness. We are concerned that trying to reuse too much of the IKE code base in new protocols -- PIC and GDOI come to mind -- will lead to more complex (and hence vulnerable) implementations. We suggest that implementors resist this temptation, with the obvious exception of common library functions that perform functions such as large modular exponentiations. Attempts to share state or to optimize message exchanges are likely to lead to disaster. The Security Area Directors have asked the IPSEC working group to come up with a replacement for IKE. This work is underway and is known in the community as "Son of IKE". This effort is at serious risk of suffering the "second system effect", where all the features that were left out of the first version, end up in the second. For this to happen would be a spectacular disaster, and very much detract from the goal: to produce a more secure, simpler, and more robust version of IKE. Arriving at this point has been exceedingly difficult and harrowing. Understandably, egos have been bruised, and the "change not the IKE, for it is subtle and quick to anger" position has been taken as a personal afront by some members of the IPSEC community. Nothing could be further from the intent of either of the Security Area directors. If IKE is vulnerable, we must all share a burden of responsibility for allowing it to get to the state it is in and we must all work together to correct the problems. The IPSEC community must act prudently in moving forward with a replacement for IKE. The IPSEC auxillary groups (IPSRA, MSEC, IPSP) must act with good judgment (chairs and members alike) in designing protocols that don't interfere with the goal of security and simplifying our IPSEC key-agreement protocol. Marcus Leech (IESG) Jeff Schiller (IESG) Steve Bellovin (IAB) --------------700C1CE7C41A16595853A0C3-- --zH41lVBEV8cLJnCl-- --iUV/lbBrmPtUT9dM 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 iD8DBQE7atsLtvPFKAfa3SIRAiezAJ9JKYk6aOKA+vEdftZrcCsZh7cWeQCeOvc/ 3qLQXgQAldODI6/xQ7kpl1M= =Id1H -----END PGP SIGNATURE----- --iUV/lbBrmPtUT9dM-- From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 3 13:26: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 NAA22203 for ; Fri, 3 Aug 2001 13:26:32 -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 KAA15549; Fri, 3 Aug 2001 10:22: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 KAA23942; Fri, 3 Aug 2001 10:17:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f73HGJX25735 for mobile-ip-dist; Fri, 3 Aug 2001 10:16: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+Sun/8.11.5) with ESMTP id f73HGFD25727 for ; Fri, 3 Aug 2001 10:16:15 -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 KAA08198 for ; Fri, 3 Aug 2001 10:16:17 -0700 (PDT) Message-Id: <200108031716.KAA08198@heliopolis.eng.sun.com> Date: Fri, 3 Aug 2001 10:16:09 -0700 (PDT) From: James Kempf Subject: RE: [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: 9FdKonpRQrvFhRbNmyh0Bw== 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 Alper, Replies included. >My scenario, and question, is what should "a" MN do after it detects the >movement at L2? Should it wait in the expectation that ARs are performing >BETH in between and MN will start receiving packet sent to oldCoA? Since >there's no L3 signalling between ARs and the MN, MN cannot know that. Or, >should it attempt stock MIPv6 handoff (DAD, newCoA, which will delay >transmission from MN). > > Tunneling under the old CoA between old AR and new AR is handled even under the stock FMIPv6 algorithm as a corner case. In BETH, the difference is that when the MN detects it has moved, it can either begin the process of establishing a new CoA using the standard FMIPv6 algorithm, or it can wait until its real time stream is complete, or until it moves again. The decision is up to the MN. The tunnel should not be a corner case, but rather the norm. The ARs should always set up the tunnel for network initiated handover (this is, incidentally, how low latency MIPv4 does it), and it is up to the MN as to whether and when it should establish a new CoA (this is not currenly in low latency MIPv4 but we will add it if the WG agrees). If it has a real time stream going, it can wait, if not, it can go forward with the CoA change. For the mobile initiated case, it is completely different. Because the MN is signalling over the air to control the handover, the algorithm presumes enough radio bandwidth (or a completely separate signalling channel) so the MIP signalling doesn't interfere with real time streams. In that case, the AR is warned sufficiently ahead of time by the RqstPrxyAdv that the MN will be handling the handover, and so it should not initiate the tunnel. >The end2end L3 signalling between MN and oldCoA reveals what's going on. >F-BU, F-Back, ProxyRtAdv are all new signals that indicate what's going on. >At any time both sides know what's going on, and can choose to fail it or >proceed. > If FMIPv6 is modified as I've described above, then there should be no interference. Whether or not mobile initiated/controlled or network initiated/controlled handover is done is a policy question that probably will be determined by the amount of radio bandwidth available or the availability of a signalling channel for IP related signalling. This will have to be established beforehand. There is no need, in the network initiated/controlled case, for any signalling from the MN until it decides it wants a new CoA. >The problem for BETH would be, at the time MN attaches to "a" new L2 >(newAR), >how is it going to be notified of this information? Can't wait for a L3 >message, as BETH relies on non-existence of such a message. > See above. >Let me try to explain my example (it wasn't clear, I admit). > >MN has interface1, attached to oldAR. It also has another interface, >interface2. Does interface2 have a global IP address and CoA or not? >While oldAR and newAR decides to perform BETH for interface1, MN might >decide >to do a "forwarding from previous care-of address" between oldAR and >thirdAR. ??? where does thirdAR come into this? I guess I'm still not getting this example, sorry. Maybe we can talk about it in person in London? >Since MN doesn't know BETH is happening, it's very well possible that it >does >its own thing. So, I think we should define what happens if oldAR is in the >middle of BETH and it receives a BU from MN. > I'm not clear what you mean by "in the middle of BETH." As I stated above, BETH is just extending what is a corner case in the FMIPv6 draft to be the norm. MN knows when the L2 handover completes on L2 via the Link Up trigger. At that point, it can start the process of establishing a new CoA on the new AR if it wants, or not. This isn't any different from the case in standard FMIPv6 where none of the signaling for establishing a new CoA goes through the old AR and all of it goes through the new AR. >> The signal should be the BACK from the HA and any CNs, because it >> is only at >> that point when the new CoA can really be used. The ARs tear down >> the tunnel at this point, though they may keep it up for some >> configurable time period in order to assure that any laggard packets >> get to the MN. The draft should be more precise about this. > > >Is this based on newAR sniffing the traffic and seeing a Back sent to MN? > It would have to track the BACK. As for sniffing, BU/BACK are destination options and I thought that routers were allowed to process destination options? >I agree with you on when to configure the CoA. But in BETH, somebody >is doing a L3-ish handoff on behalf of MN, and MN doesn't even know this. > It is no different than the corner case of standard FMIPv6 in which the MN does no new CoA establishment signalling on old AR and all of it on new AR. This is a real possibility in the standard FMIPv6 algorithm, if movement into the coverage area of the new AR is too fast. There is no L3-ish handover occuring, everything is happening at L2 and the ARs are fixing things up at L3 to make sure the MN's traffic gets to it (this is, after all, what routers are supposed to do). The L3 handover occurs after the MN is on new AR, if MN so chooses. I'm adhering to the following definitions here: L2 handover - a change in link connectivity from one radio access point to another as a consequence of mobile node movement between radio coverage areas. L3 handover - a change in mobile IP care-of address as a consequence of mobile node movement between one subnet and another. >F-NA can be replaced by a L2 trigger. Maybe we should clarify this better >in FMIPv6. The information needed for neighbor cache is already >in HI message. All newAR needs is an indication of arrival. > I think the draft needs to clarify this. There are a couple places in the draft that state that the F-NA is the gate. If that's the case, then I agree that the handover times in Appendix A may need to be modified. >Once MN has a tunnel from oldAR to newCoA, it doesn't have to wait for >BU/BACk from CN/HA. Packets sent to oldCoA will be tunneled. MN can >use newCoA as its source address in the outgoing traffic. > So the only way this is different from BETH is that the MN uses its old CoA to send outgoing traffic, saving the signalling traffic over the radio channel for establishing the new CoA. And the routers maintain the tunnel until the MN is ready to change CoA. >But this BAck arrival happens at the MN, right? Not at newAR. So, >how does newAR know this? Sniffing on the network? > BU and BACK are destination options, aren't routers allowed to process destination options? If they can, then they can note them as the packets go by. jak From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 3 15:09: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 PAA24524 for ; Fri, 3 Aug 2001 15:09: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 MAA00878; Fri, 3 Aug 2001 12:10:24 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA09505; Fri, 3 Aug 2001 12:09:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f73J8pU25972 for mobile-ip-dist; Fri, 3 Aug 2001 12:08:51 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f73J8mD25965 for ; Fri, 3 Aug 2001 12:08: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 MAA03116 for ; Fri, 3 Aug 2001 12:08:48 -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 NAA05162 for ; Fri, 3 Aug 2001 13:08:45 -0600 (MDT) content-class: urn:content-classes:message Subject: RE: [mobile-ip] [mleech@nortelnetworks.com: Position statement on IKE development] MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 3 Aug 2001 15:08:47 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Message-ID: Thread-Topic: [mobile-ip] [mleech@nortelnetworks.com: Position statement on IKE development] Thread-Index: AcEcP9GY0fNqIpGwSkSnjUM1EgPTUAAGK7rw From: "Qiang Zhang" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f73J8mD25966 Sender: owner-mobile-ip@sunroof.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 It sounds terrible, but having said all those, what is the better solution now? -----Original Message----- From: John Wells [mailto:wells@ee.vt.edu] Sent: Friday, August 03, 2001 12:11 PM To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] [mleech@nortelnetworks.com: Position statement on IKE development] It's probably a good idea to go forward with a non-IPsec based solution, particularly in light of this news.. john -- John WELLS Virginia Tech Networking and Visualization Lab PGP Public key: http://www.ee.vt.edu/~wells/pgpkey.txt From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 3 16:47:28 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28915 for ; Fri, 3 Aug 2001 16:47: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 NAA17618; Fri, 3 Aug 2001 13:48: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 NAA06062; Fri, 3 Aug 2001 13:46:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f73KjQf26140 for mobile-ip-dist; Fri, 3 Aug 2001 13:45:26 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f73KjND26133 for ; Fri, 3 Aug 2001 13:45:23 -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 NAA14321 for ; Fri, 3 Aug 2001 13:45:24 -0700 (PDT) Received: from birch.ee.vt.edu (birch.ee.vt.edu [128.173.88.34]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA15633 for ; Fri, 3 Aug 2001 14:45:21 -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 QAA23963 for ; Fri, 3 Aug 2001 16:45:22 -0400 (EDT) Received: (from wells@localhost) by eagle.ee.vt.edu (8.10.2+Sun/8.10.2) id f73KjME13500 for mobile-ip@sunroof.eng.sun.com; Fri, 3 Aug 2001 16:45:22 -0400 (EDT) Date: Fri, 3 Aug 2001 16:45:22 -0400 From: John Wells To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] [mleech@nortelnetworks.com: Position statement on IKE development] Message-ID: <20010803164521.B13410@horus.imag.fr> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="ALfTUftag+2gvp1h" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from qzhang@ecutel.com on Fri, Aug 03, 2001 at 03:08:47PM -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: --ALfTUftag+2gvp1h Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable =46rom the message, it would appear that the IESG is pushing towards a lighter replacement IKE which some folks refer to as the son of IKE. It will be interesting to see what they have in mind.. john vendredi, le 03 ao=FBt 2001 =E0 15h08 -0400, Qiang Zhang a =E9crit : > It sounds terrible, but having said all those, what is the better > solution now? --=20 John WELLS Virginia Tech Networking and Visualization Lab PGP Public key: http://www.ee.vt.edu/~wells/pgpkey.txt --ALfTUftag+2gvp1h 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 iD8DBQE7aw1htvPFKAfa3SIRAkYtAJ9OVjDl33IIEkEkLbtLHaq8/8+KvgCeMRqP skETlKDf3UIjNNKb1mZFnSw= =fFEq -----END PGP SIGNATURE----- --ALfTUftag+2gvp1h-- From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 3 17:20:00 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29451 for ; Fri, 3 Aug 2001 17:20: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 PAA09491; Fri, 3 Aug 2001 15:20: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 OAA05666; Fri, 3 Aug 2001 14:19:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f73LIjV26257 for mobile-ip-dist; Fri, 3 Aug 2001 14:18:45 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f73LIgD26250 for ; Fri, 3 Aug 2001 14:18:42 -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 OAA12719 for ; Fri, 3 Aug 2001 14:18:43 -0700 (PDT) Received: from idcpa4.pa.interdigital.com ([12.32.197.142]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA07841 for ; Fri, 3 Aug 2001 15:18:41 -0600 (MDT) Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19) id ; Fri, 3 Aug 2001 17:17:32 -0400 Message-ID: From: "Shahrier, Sharif M." To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] slides fror IETF ad-hoc on NATs Date: Fri, 3 Aug 2001 17:17:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: I will be showing a few slides at the ad-hoc on NATs. You can find it at: ftp://ftp.interdigital.com usr: mobileip pass: ident file_name: nat_2.ppt Sharif. From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 3 19: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 ESMTP id TAA01236 for ; Fri, 3 Aug 2001 19:51: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 QAA18925; Fri, 3 Aug 2001 16:52: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 QAA02409; Fri, 3 Aug 2001 16:52:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f73NpAI26507 for mobile-ip-dist; Fri, 3 Aug 2001 16:51:10 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.85.31] (may be forged)) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f73Np7D26500 for ; Fri, 3 Aug 2001 16:51:07 -0700 (PDT) Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.11.5+Sun/8.11.5) with SMTP id f73Np6b130775; Fri, 3 Aug 2001 16:51:06 -0700 (PDT) Message-Id: <200108032351.f73Np6b130775@jurassic.eng.sun.com> Date: Fri, 3 Aug 2001 16:52:31 -0700 (PDT) From: Samita Chakrabarti Subject: [mobile-ip] Comments on draft-ietf-mobileip-qos-requirements-00.txt To: Hemant.Chaskar@nokia.com, mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: yGTY1tN3u+tKz/VB6rx7ow== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.9 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hello Hemant: I am reading the mobileip-qos requirement draft again, and I think it is still missing some clarification and some of my comments on mip-qos alias were not addressed. Let me explain them here again, and why I think they should be in the requirement document. 1. I assume the goal of the requirement document is not to provide or point to any particular qos solution for mobile-ip. Yet, at number of cases, in the document we have references and examples of RSVP qos mechanism. Is it because we do not have any experience or data available for other Qos mechanism(such as diffserv) for mobile ip ? Or is it trying to point out some of the drawbacks of RSVP in mobileip environment ? If we discuss problems or merits of qos mechanism, we should discuss that for different mechanisms. May be the examples belong to appendix. For example, diffserv seems more appropriate to me in mobileip case, but then it may need to have some dynamic service level agreements between the nodes where the handover is taking place. 2. section 3.1, bullet item 2, it states: "Of course, if the end-to-end path changes at large after handover, the QoS mechanism MUST be able to address that in a manner that is consistent with the QoS scheme(s) used along the new end-to-end packet path." By "new end-to-end" path it means the path between two communicating nodes. Should not it say that Qos mechanism should be established in the 'changed or new end-to-end' path depending on the Qos mechanism ? 3. The scalabality is a mobileip specific qos issue that this requirement draft needs to clarify. As JC Martin and I requested the following item in our earlier comments to mip-qos alias: A salability requirement could be that no per MN state should be kept in the inner nodes: state should be contained as close as possible to the MN. Also : if the QoS Mechanism is using signaling, it should be aggregated as close as possible to the MN. 4. How about adding a section here for 'inter-technology handoff'. What's our qos requirement there? Do we expect it to be transparent as it's happening in IP layer ? 5. The obvious requirement section is not too obvious to many. Can we clarify? Thanks! -Samita From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 3 21: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 ESMTP id VAA02022 for ; Fri, 3 Aug 2001 21:24: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 TAA25599; Fri, 3 Aug 2001 19:25:03 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA13824; Fri, 3 Aug 2001 18:24:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f741Nb726663 for mobile-ip-dist; Fri, 3 Aug 2001 18:23:37 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f741NYD26656 for ; Fri, 3 Aug 2001 18:23:34 -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 SAA22237 for ; Fri, 3 Aug 2001 18:23:35 -0700 (PDT) Received: from hotmail.com (f188.law7.hotmail.com [216.33.237.188]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA15402 for ; Fri, 3 Aug 2001 18:23:35 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 3 Aug 2001 18:23:35 -0700 Received: from 63.78.179.4 by lw7fd.law7.hotmail.msn.com with HTTP; Sat, 04 Aug 2001 01:23:35 GMT X-Originating-IP: [63.78.179.4] From: "Hemant Chaskar" To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Comments on draft-ietf-mobileip-qos-requirements-00.txt Date: Sat, 04 Aug 2001 01:23:35 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 04 Aug 2001 01:23:35.0752 (UTC) FILETIME=[150D0480:01C11C84] Sender: owner-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 Samita: Please see some answers inline: >From: Samita Chakrabarti >Reply-To: mobile-ip@sunroof.eng.sun.com >To: Hemant.Chaskar@nokia.com, mobile-ip@sunroof.eng.sun.com >Subject: [mobile-ip] Comments on >draft-ietf-mobileip-qos-requirements-00.txt >Date: Fri, 3 Aug 2001 16:52:31 -0700 (PDT) > >Hello Hemant: > >I am reading the mobileip-qos requirement draft again, and I think it >is still missing some clarification and some of my comments on mip-qos >alias were not addressed. Let me explain them here again, and why I think >they should be in the requirement document. > >1. I assume the goal of the requirement document is not to provide or point > to any particular qos solution for mobile-ip. Yet, at number of cases, >in > the document we have references and examples of RSVP qos mechanism. Is >it > because we do not have any experience or data available for other Qos > mechanism(such as diffserv) for mobile ip ? Or is it trying to point >out > some of the drawbacks of RSVP in mobileip environment ? [Hemant] It was argued on the MIP QoS the mailing list that it is not sufficient just to quote requirements, but provide some insight into what is missing from the current QoS mechanisms. The idea was this would help the relevant working groups to focus on the precise missing piece and work out the solution. RSVP (intserv or intserv+diffserv(RFC 2998)) is one such QoS mechanism that exists as an RFC. That is why the mention of RSVP. > > If we discuss problems or merits of qos mechanism, we should discuss > that for different mechanisms. May be the examples belong to appendix. > For example, diffserv seems more appropriate to me in mobileip case, >but > then it may need to have some dynamic service level agreements between > the nodes where the handover is taking place. [Hemant] We can put DiffServ in there as well and also quote the point that you are mentioning about dynamic service level agreements. Anyway, that work has already started in Seamoby in the form of moving diffserv context in the context transfer protocol. > > >2. section 3.1, bullet item 2, it states: > "Of course, if > the end-to-end path changes at large after handover, the QoS > mechanism MUST be able to address that in a manner that is > consistent with the QoS scheme(s) used along the new > end-to-end packet path." > > By "new end-to-end" path it means the path between two communicating >nodes. > Should not it say that Qos mechanism should be established in the >'changed > or new end-to-end' path depending on the Qos mechanism ? [Hemant] There was a concern raised on the language that you are proposing. Somebody said that such a language implies that new end-to-end QoS must be established. The message that we are sending is that "handovers may change end-to-end path", so solution may not only focus only on the local path changes. Now if the QoS mechanism cares about end-to-end path it will have to be reinitiated, if not it may ignore the end-to-end change. > > >3. The scalabality is a mobileip specific qos issue that this requirement > draft needs to clarify. As JC Martin and I requested the following item >in > our earlier comments to mip-qos alias: > > A salability requirement could be that no per MN state should be kept > in the inner nodes: state should be contained as close as possible to >the > MN. Also : if the QoS Mechanism is using signaling, it should be >aggregated > as close as possible to the MN. [Hemant] This is a general requirement for QoS, even for fixed hosts. Could you please explain why it is relevant "only for mobile IP." This draft does not want to address requirements that are "common" to both fixed and mobile hosts, rather we should focus on requirements that are "exclusively" for mobile IP. > > >4. > How about adding a section here for 'inter-technology > handoff'. What's our qos requirement there? > Do we expect it to be transparent as it's happening in IP layer ? [Hemant] The question we should ask is whether inter-technology handover apparent at IP layer. Also what is the requirement as such? I think such a handover is transparent to IP layer, but I can put that requirement (what is it first?) in if WG agrees on it. > > >5. The obvious requirement section is not too obvious to many. Can we >clarify? [Hemant] Could you please be more specific and point out which item there is not obvious and what the confusion might be. > > >Thanks! >-Samita > Thanks for your comments. Hemant _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 3 21:47:39 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03189 for ; Fri, 3 Aug 2001 21:47:39 -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 SAA08729; Fri, 3 Aug 2001 18:48: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 SAA15798; Fri, 3 Aug 2001 18:48:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f741kX926820 for mobile-ip-dist; Fri, 3 Aug 2001 18:46:33 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.84.31] (may be forged)) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f741kUD26813 for ; Fri, 3 Aug 2001 18:46:30 -0700 (PDT) Received: from istanbul.Eng.Sun.COM (istanbul.Eng.Sun.COM [129.146.86.247]) by jurassic.eng.sun.com (8.11.5+Sun/8.11.5) with SMTP id f741kVb151886 for ; Fri, 3 Aug 2001 18:46:31 -0700 (PDT) Message-Id: <200108040146.f741kVb151886@jurassic.eng.sun.com> Date: Fri, 3 Aug 2001 18:46:31 -0700 (PDT) From: Alper Yegin Subject: RE: [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: P8CRQ+vqdL0NUhHPjAxNxA== 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: Jim, Let me rephrase my questions/concerns.. - During a real-time communication, if your MN detects that it has attached to a new L2, what does it do? It'd hope that oldAR and newAR are doing BETH and MN would do nothing, as I understand. But, what if the newAR is not BETH capable, or BETH has failed for some reason. The only way to figure this out is to wait, I think. There seems to be no other way, because there's no L3 signalling between MN and newAR. And this wait will effect the handoff time, if newAR is not doing BETH. - BU/Back are destination options. Therefore they are only processed by the destinations, MN/CN/HA. If routers want to take a peek on them, they can do so. But, designing the protocol based on sniffing packets on the wire makes me worried. One thing, it's not guaranteed that this packet will go through this router, as there can be more than one on the link. Secondly, if one day this packet is encrypted, or a new flavor of BU/BAck is used, this won't work. As far as what kind of L? handover this is, I agree this is more like a L2 handover (at least as far as MN is concerned). We should clarify the use of L2 triggers in FMIPv6. alper > > >My scenario, and question, is what should "a" MN do after it detects the > >movement at L2? Should it wait in the expectation that ARs are performing > >BETH in between and MN will start receiving packet sent to oldCoA? Since > >there's no L3 signalling between ARs and the MN, MN cannot know that. Or, > >should it attempt stock MIPv6 handoff (DAD, newCoA, which will delay > >transmission from MN). > > > > > > Tunneling under the old CoA between old AR and new AR is handled even under the > stock FMIPv6 algorithm as a corner case. In BETH, the > difference is that when the MN detects it has moved, > it can either begin the process of establishing a new CoA using > the standard FMIPv6 algorithm, or it can wait until its real time > stream is complete, or until it moves again. The decision is > up to the MN. The tunnel should not be a corner case, but rather the norm. The > ARs should always set up the tunnel for network initiated handover (this is, > incidentally, how low latency MIPv4 does it), and it is up to the MN as to > whether and when it should establish a new CoA (this is not currenly > in low latency MIPv4 but we will add it if the WG agrees). If it has a real time > stream going, it can wait, if not, it can go forward with the CoA change. > > For the mobile initiated case, it is completely different. Because > the MN is signalling over the air to control the handover, the algorithm > presumes enough radio bandwidth (or a completely separate signalling channel) so > the MIP signalling doesn't interfere with real time streams. In > that case, the AR is warned sufficiently ahead of time by the > RqstPrxyAdv that the MN will be handling the handover, and so > it should not initiate the tunnel. > > >The end2end L3 signalling between MN and oldCoA reveals what's going on. > >F-BU, F-Back, ProxyRtAdv are all new signals that indicate what's going on. > >At any time both sides know what's going on, and can choose to fail it or > >proceed. > > > > If FMIPv6 is modified as I've described above, then there should > be no interference. Whether or not mobile initiated/controlled > or network initiated/controlled handover is done is a policy question > that probably will be determined by the amount of radio bandwidth > available or the availability of a signalling channel for IP related > signalling. This will have to be established beforehand. There > is no need, in the network initiated/controlled case, for any > signalling from the MN until it decides it wants a new CoA. > > > >The problem for BETH would be, at the time MN attaches to "a" new L2 > >(newAR), > >how is it going to be notified of this information? Can't wait for a L3 > >message, as BETH relies on non-existence of such a message. > > > > See above. > > >Let me try to explain my example (it wasn't clear, I admit). > > > >MN has interface1, attached to oldAR. It also has another interface, > >interface2. > > Does interface2 have a global IP address and CoA or not? > > >While oldAR and newAR decides to perform BETH for interface1, MN might > >decide > >to do a "forwarding from previous care-of address" between oldAR and > >thirdAR. > > ??? where does thirdAR come into this? I guess I'm still not getting > this example, sorry. Maybe we can talk about it in person in London? > > >Since MN doesn't know BETH is happening, it's very well possible that it > >does > >its own thing. So, I think we should define what happens if oldAR is in the > >middle of BETH and it receives a BU from MN. > > > > I'm not clear what you mean by "in the middle of BETH." As I stated > above, BETH is just extending what is a corner case in the FMIPv6 > draft to be the norm. MN knows when the L2 handover completes on > L2 via the Link Up trigger. At that point, it can start the process > of establishing a new CoA on the new AR if it wants, or not. This > isn't any different from the case in standard FMIPv6 where none > of the signaling for establishing a new CoA goes through the old > AR and all of it goes through the new AR. > > > >> The signal should be the BACK from the HA and any CNs, because it > >> is only at > >> that point when the new CoA can really be used. The ARs tear down > >> the tunnel at this point, though they may keep it up for some > >> configurable time period in order to assure that any laggard packets > >> get to the MN. The draft should be more precise about this. > > > > > >Is this based on newAR sniffing the traffic and seeing a Back sent to MN? > > > > It would have to track the BACK. As for sniffing, BU/BACK are > destination options and I thought that routers were allowed > to process destination options? > > >I agree with you on when to configure the CoA. But in BETH, somebody > >is doing a L3-ish handoff on behalf of MN, and MN doesn't even know this. > > > > It is no different than the corner case of standard FMIPv6 in which the > MN does no new CoA establishment signalling on old AR and all of it > on new AR. This is a real possibility in the standard FMIPv6 algorithm, > if movement into the coverage area of the new AR is too fast. > There is no L3-ish handover occuring, everything is happening at > L2 and the ARs are fixing things up at L3 to make sure the MN's traffic > gets to it (this is, after all, what routers are supposed to do). > The L3 handover occurs after the MN is on new AR, if MN so chooses. > > I'm adhering to the following definitions here: > > L2 handover - a change in link connectivity from one > radio access point to another as a consequence of mobile > node movement between radio coverage areas. > > L3 handover - a change in mobile IP care-of address as > a consequence of mobile node movement between one > subnet and another. > > > >F-NA can be replaced by a L2 trigger. Maybe we should clarify this better > >in FMIPv6. The information needed for neighbor cache is already > >in HI message. All newAR needs is an indication of arrival. > > > > I think the draft needs to clarify this. There are a couple places > in the draft that state that the F-NA is the gate. If that's the > case, then I agree that the handover times in Appendix A may > need to be modified. > > > >Once MN has a tunnel from oldAR to newCoA, it doesn't have to wait for > >BU/BACk from CN/HA. Packets sent to oldCoA will be tunneled. MN can > >use newCoA as its source address in the outgoing traffic. > > > > So the only way this is different from BETH is that the MN uses > its old CoA to send outgoing traffic, saving the > signalling traffic over the radio channel for establishing the new CoA. > And the routers maintain the tunnel until the MN is ready to > change CoA. > > > >But this BAck arrival happens at the MN, right? Not at newAR. So, > >how does newAR know this? Sniffing on the network? > > > > BU and BACK are destination options, aren't routers allowed to > process destination options? If they can, then they can note > them as the packets go by. > > jak > alper From owner-mobile-ip@sunroof.eng.sun.com Sat Aug 4 03:07:27 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23016 for ; Sat, 4 Aug 2001 03:07: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 AAA23779; Sat, 4 Aug 2001 00:03: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 XAA07210; Fri, 3 Aug 2001 23:03:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7461Gu27150 for mobile-ip-dist; Fri, 3 Aug 2001 23:01:17 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7461CD27143 for ; Fri, 3 Aug 2001 23:01:12 -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 XAA22564 for ; Fri, 3 Aug 2001 23:01:14 -0700 (PDT) Received: from fep02-app.kolumbus.fi (fep02-0.kolumbus.fi [193.229.0.44]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA23196 for ; Sat, 4 Aug 2001 00:01:11 -0600 (MDT) Received: from jariws1 ([62.248.155.56]) by fep02-app.kolumbus.fi (InterMail vM.5.01.03.08 201-253-122-118-108-20010628) with SMTP id <20010804060111.USZ26212.fep02-app.kolumbus.fi@jariws1>; Sat, 4 Aug 2001 09:01:11 +0300 Message-ID: <01e701c11caa$e54c85a0$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: Cc: "John Wells" References: <20010803131036.J11736@horus.imag.fr> Subject: Re: [mobile-ip] [mleech@nortelnetworks.com: Position statement on IKE development] Date: Sat, 4 Aug 2001 09:01:25 +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 John Wells wrote: >It's probably a good idea to go forward with a non-IPsec based solution, >particularly in light of this news.. It is indeed bad news. But, I'd just like to point out that the position statement said that a replacement for IKE should be designed (and is being designed, called Son-of-IKE). That is, a redesign of IPsec AH/ESP wasn't called for. In the mobile IPv6 case we have already given up the hope of using IKE to key BUs in the global Internet. But we could still use AH/ESP to protect the BUs, BAKE for keying in the global Internet, and IKE, KINK or Son-of-IKE (when available) for keying in the Intranet. Jari From owner-mobile-ip@sunroof.eng.sun.com Sat Aug 4 10:17:14 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26485 for ; Sat, 4 Aug 2001 10:17:14 -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 HAA02641; Sat, 4 Aug 2001 07:18:04 -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 HAA11784; Sat, 4 Aug 2001 07:17:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f74EGQb27633 for mobile-ip-dist; Sat, 4 Aug 2001 07:16:26 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f74EGLD27626 for ; Sat, 4 Aug 2001 07:16: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 HAA11742 for ; Sat, 4 Aug 2001 07:16:21 -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 HAA08847 for ; Sat, 4 Aug 2001 07:16:20 -0700 (PDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id HAA28286 for ; Sat, 4 Aug 2001 07:16:19 -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 HAA14715 for ; Sat, 4 Aug 2001 07:16:19 -0700 (MST)] Received: from [140.101.173.9] by m-il06-r4.mot.com with ESMTP for mobile-ip@sunroof.eng.sun.com; Sat, 4 Aug 2001 09:16:18 -0500 Received: (from root@localhost) by zorglub.crm.mot.com (8.8.8/8.8.8/crm-1.6) id QAA17480 for mobile-ip@sunroof.eng.sun.com.DELIVER; Sat, 4 Aug 2001 16:16:16 +0200 (METDST) Received: from test9.crm.mot.com.crm.mot.com (zfr24-sr2-09.corp.mot.com [140.101.145.9]) by zorglub.crm.mot.com (8.8.8/8.8.8/crm-1.6) with ESMTP id QAA17450 for ; Sat, 4 Aug 2001 16:16:14 +0200 (METDST) To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Concerns about draft-mipv6-14 section 4.8 From: Alexandru Petrescu Date: 04 Aug 2001 16:11:42 +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: 23 Sender: owner-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, When discussing mobile routers/networks in the Mobile IPv6 context I see the following issues raised by your draft as well as Charlie's latest additions: o searching in the binding cache of HA and CN: longest prefix match? CAn you have several entries in the binding cache for the same mobile node (one for the MR, one for the node itself)? o MR specific behaviour: -should not advertise its moving subnet prefix on the foreign network. However should allow communications between its nodes and nodes behind another MR visiting same foreign network, without going through any HA. How? -when does MR send BU's to CN's? How MR knows about the CN's of fixed nodes in its moving subnet? -it's assumed that the moving subnet prefix is aggregated within the home net prefix. Is it a MUST? o A new kind of MN? The MN's attached to the moving subnet, are they fixed, do they have a binding cache, do they send binding updates? Alex From owner-mobile-ip@sunroof.eng.sun.com Sat Aug 4 11:44:25 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27621 for ; Sat, 4 Aug 2001 11:44: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 JAA06525; Sat, 4 Aug 2001 09:45: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 IAA23419; Sat, 4 Aug 2001 08:44:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f74FhYN27793 for mobile-ip-dist; Sat, 4 Aug 2001 08:43:34 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f74FhUD27786 for ; Sat, 4 Aug 2001 08:43: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 IAA14958 for ; Sat, 4 Aug 2001 08:43:30 -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 JAA10541 for ; Sat, 4 Aug 2001 09:43:30 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id IAA07944; Sat, 4 Aug 2001 08:43:28 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f74FhSn14522; Sat, 4 Aug 2001 08:43:28 -0700 X-mProtect: Sat, 4 Aug 2001 08:43:28 -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 smtpdEg0eAE; Sat, 04 Aug 2001 08:43:26 PDT Message-ID: <3B6C181E.38245FC6@iprg.nokia.com> Date: Sat, 04 Aug 2001 08:43:26 -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: Thierry Ernst CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Concerns about draft-mipv6-14 section 4.8 References: <0DF9FBC42474A24CA50F7A27FB08E0484455F8@meshpdc.meshnetworks.com> <3B671944.E9F1F0B0@Kniveton.com> <3B67F996.BD665A40@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 Hello folks, As noted, I had made an attempt to update the Mobile IPv6 specification towards assisting the problems with mobile routers. However, making it into a separate draft looks like a better idea. For the base draft, should the prefix length bits be marked as "reserved"? The Mobile Router Prefix Length Sub-Option would be removed, too. Regards, Charlie P. Thierry Ernst wrote: > > "T.J. Kniveton" wrote: > > > > 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? > > Indeed, there would be such one good reason: mobile networks have an > implication on other aspects not related to Mobile IP. For instance, on > routing protocols, but the right place for the discussion is still > Mobile IP because we have to determine whether Mobile IPv6 is the right > base protocol for network mobility support. Mobile IPv6 may not be able > to address all issues, but it surely can help. > > I agree that MANET WG could benefit from this discussion (how do you > manage mobility of an ad-hoc network that changes its point of > attachment ?), but it's not a better place than Mobile IP WG. MANET WG > is more concerned by "how things are done INSIDE the network" than "how > to manage subsequent point of attachments to the Internet", which is > Mobile IP WG's. > > Anyway, seems clear to me that everyone agree that this should not be > addressed in the MIPv6 draft itself, but in a separate document. > > Thierry. > > > 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? > > -- > * 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 Sat Aug 4 11:58:22 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27805 for ; Sat, 4 Aug 2001 11:58: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 IAA09523; Sat, 4 Aug 2001 08:59: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 IAA25346; Sat, 4 Aug 2001 08:58:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f74Fvu627874 for mobile-ip-dist; Sat, 4 Aug 2001 08:57:56 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f74FvrD27867 for ; Sat, 4 Aug 2001 08:57: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 IAA25304; Sat, 4 Aug 2001 08:57: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 IAA24525; Sat, 4 Aug 2001 08:57:53 -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 IAA08495; Sat, 4 Aug 2001 08:57:53 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f74Fvrs30496; Sat, 4 Aug 2001 08:57:53 -0700 X-mProtect: Sat, 4 Aug 2001 08:57: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 smtpdNnEZpc; Sat, 04 Aug 2001 08:57:51 PDT Message-ID: <3B6C1B7E.E227DB4B@iprg.nokia.com> Date: Sat, 04 Aug 2001 08:57:50 -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: Pat Calhoun CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Handover Smoothing - What to Do? References: <9FBD322B7824D511B36900508BF93C9C9F5EAC@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 Hello Pat, >> 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 You point out that the network already creates duplicate packets. For every such occurrence, bicasting becomes quadricasting and suddenly we have a problem. Thus, bicasting works better when the rest of the network can be trusted not to produce duplicate packets. Put another way, bicasting removes the resiliency which exists today for TCP traffic. My conclusion is that any use of bicasting needs to be strictly limited in time, with well-defined start and stop times. The ability to define these start and stop times is crucial, and yet whenever it is possible to do so, it might equally well be possible to design protocol so that unicast packets go where they ought to go. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Sat Aug 4 12:49:15 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28742 for ; Sat, 4 Aug 2001 12:49: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 KAA18861; Sat, 4 Aug 2001 10:49: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 JAA17881; Sat, 4 Aug 2001 09:49:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f74GmfF27968 for mobile-ip-dist; Sat, 4 Aug 2001 09:48:41 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f74GmbD27961 for ; Sat, 4 Aug 2001 09:48: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 JAA27292 for ; Sat, 4 Aug 2001 09:48:33 -0700 (PDT) Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA03659 for ; Sat, 4 Aug 2001 09:48:32 -0700 (PDT) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by hoemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f74GmUq28813 for ; Sat, 4 Aug 2001 12:48:31 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id <3YP2L87N>; Sat, 4 Aug 2001 17:48:29 +0100 Message-ID: <976F7C55E3B2D111A0720008C728549C097CC99D@en0060exch001u.uk.lucent.com> From: "Casati, Alessio (Alessio)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Handover Smoothing - What to Do? Date: Sat, 4 Aug 2001 17:46:46 +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: *My conclusion is that any use of bicasting needs to be strictly *limited in time, with well-defined start and stop times. The *ability to define these start and stop times is crucial, and yet *whenever it is possible to do so, it might equally well be possible *to design protocol so that unicast packets go where they ought to go. Another point one could consider is that the assumption we would be better off with bicasting than with any other solution may not pass some checkpoints, like fast movement thru a sequence > 2 access points. Would this require ">2-casting"? also, bicasting is implicitly assuming some movement prediction, to be any different than non bicasting based solutions. Clearly, many times tricasting or quadricasting or ... would be required, when multiple handoff candidates need to be considered. Reality is that a mobile node has (at most) one point of attachment at a time and other possible points of reachability of the MN are only point of collection of packets that were "in flight" before the MN hooked up to the current point of attachment ("Before" is defined w.r.t the time when a HA or a CN is updated about the current point of attachment to the internet). These point of collection of packets may be kind enough to forward packets to the current point of attachment (and they can be kind only if somebody, most likely upon request of the MN, kindly asked to forward packets to some appropriate next-hop). This is to me a model that meets the "sufficient" engineering criterion, so I'm hesitant to encourage bi(?)casting based solutions. alessio From owner-mobile-ip@sunroof.eng.sun.com Sat Aug 4 19:08:23 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02192 for ; Sat, 4 Aug 2001 19:08: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 QAA11746; Sat, 4 Aug 2001 16:09: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 QAA28094; Sat, 4 Aug 2001 16:08:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f74N7vn28707 for mobile-ip-dist; Sat, 4 Aug 2001 16:07:57 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f74N7sD28700 for ; Sat, 4 Aug 2001 16:07:54 -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 QAA03354 for ; Sat, 4 Aug 2001 16:07:54 -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 RAA28609 for ; Sat, 4 Aug 2001 17:07:52 -0600 (MDT) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate2.mot.com (motgate2 2.1) with ESMTP id QAA02885 for ; Sat, 4 Aug 2001 16:07:49 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id QAA26467 for ; Sat, 4 Aug 2001 16:07:48 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2653.19) id <3XDB0SJY>; Sat, 4 Aug 2001 18:07:48 -0500 Message-ID: From: Singh Ajoy-ASINGH1 To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] BETH comments and questions Date: Sat, 4 Aug 2001 18:07:44 -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 Alper: Sorry for jumping in the middle of discussion. Please find my inline response. regards, ajoy During a real-time communication, if your MN detects that it has attached to a new L2, what does it do? It'd hope that oldAR and newAR are doing BETH and MN would do nothing, as I understand. But, what if the newAR is not BETH capable, or BETH has failed for some reason. The only way to figure this out is to wait, I think. There seems to be no other way, because there's no L3 signaling between MN and newAR. And this wait will effect the handoff time, if newAR is not doing BETH. ajoy: If BETH is deployed in particular access technology, it is assumed that neighboring routers will be BETH capable. Neighboring routers have to understand same protocol to support fast handover. For example, if neighboring routers do not support same protocol, we cannot support context transfer, the MN has to negotiate context. This is true for any protocol in general. If BETH fails due to any reason, MN will detect service disruption because real time traffic flow will stop. MN can use this information as a trigger to acquire new COA. If you do not support BETH in low data rate channel, the service of user will be affected every time MN moves from one AR to other. Which one you will choose ? -----Original Message----- From: Alper Yegin [mailto:Alper.Yegin@eng.sun.com] Sent: Friday, August 03, 2001 8:47 PM To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] BETH comments and questions Jim, Let me rephrase my questions/concerns.. - During a real-time communication, if your MN detects that it has attached to a new L2, what does it do? It'd hope that oldAR and newAR are doing BETH and MN would do nothing, as I understand. But, what if the newAR is not BETH capable, or BETH has failed for some reason. The only way to figure this out is to wait, I think. There seems to be no other way, because there's no L3 signalling between MN and newAR. And this wait will effect the handoff time, if newAR is not doing BETH. - BU/Back are destination options. Therefore they are only processed by the destinations, MN/CN/HA. If routers want to take a peek on them, they can do so. But, designing the protocol based on sniffing packets on the wire makes me worried. One thing, it's not guaranteed that this packet will go through this router, as there can be more than one on the link. Secondly, if one day this packet is encrypted, or a new flavor of BU/BAck is used, this won't work. As far as what kind of L? handover this is, I agree this is more like a L2 handover (at least as far as MN is concerned). We should clarify the use of L2 triggers in FMIPv6. alper > > >My scenario, and question, is what should "a" MN do after it detects the > >movement at L2? Should it wait in the expectation that ARs are performing > >BETH in between and MN will start receiving packet sent to oldCoA? Since > >there's no L3 signalling between ARs and the MN, MN cannot know that. Or, > >should it attempt stock MIPv6 handoff (DAD, newCoA, which will delay > >transmission from MN). > > > > > > Tunneling under the old CoA between old AR and new AR is handled even under the > stock FMIPv6 algorithm as a corner case. In BETH, the > difference is that when the MN detects it has moved, > it can either begin the process of establishing a new CoA using > the standard FMIPv6 algorithm, or it can wait until its real time > stream is complete, or until it moves again. The decision is > up to the MN. The tunnel should not be a corner case, but rather the norm. The > ARs should always set up the tunnel for network initiated handover (this is, > incidentally, how low latency MIPv4 does it), and it is up to the MN as to > whether and when it should establish a new CoA (this is not currenly > in low latency MIPv4 but we will add it if the WG agrees). If it has a real time > stream going, it can wait, if not, it can go forward with the CoA change. > > For the mobile initiated case, it is completely different. Because > the MN is signalling over the air to control the handover, the algorithm > presumes enough radio bandwidth (or a completely separate signalling channel) so > the MIP signalling doesn't interfere with real time streams. In > that case, the AR is warned sufficiently ahead of time by the > RqstPrxyAdv that the MN will be handling the handover, and so > it should not initiate the tunnel. > > >The end2end L3 signalling between MN and oldCoA reveals what's going on. > >F-BU, F-Back, ProxyRtAdv are all new signals that indicate what's going on. > >At any time both sides know what's going on, and can choose to fail it or > >proceed. > > > > If FMIPv6 is modified as I've described above, then there should > be no interference. Whether or not mobile initiated/controlled > or network initiated/controlled handover is done is a policy question > that probably will be determined by the amount of radio bandwidth > available or the availability of a signalling channel for IP related > signalling. This will have to be established beforehand. There > is no need, in the network initiated/controlled case, for any > signalling from the MN until it decides it wants a new CoA. > > > >The problem for BETH would be, at the time MN attaches to "a" new L2 > >(newAR), > >how is it going to be notified of this information? Can't wait for a L3 > >message, as BETH relies on non-existence of such a message. > > > > See above. > > >Let me try to explain my example (it wasn't clear, I admit). > > > >MN has interface1, attached to oldAR. It also has another interface, > >interface2. > > Does interface2 have a global IP address and CoA or not? > > >While oldAR and newAR decides to perform BETH for interface1, MN might > >decide > >to do a "forwarding from previous care-of address" between oldAR and > >thirdAR. > > ??? where does thirdAR come into this? I guess I'm still not getting > this example, sorry. Maybe we can talk about it in person in London? > > >Since MN doesn't know BETH is happening, it's very well possible that it > >does > >its own thing. So, I think we should define what happens if oldAR is in the > >middle of BETH and it receives a BU from MN. > > > > I'm not clear what you mean by "in the middle of BETH." As I stated > above, BETH is just extending what is a corner case in the FMIPv6 > draft to be the norm. MN knows when the L2 handover completes on > L2 via the Link Up trigger. At that point, it can start the process > of establishing a new CoA on the new AR if it wants, or not. This > isn't any different from the case in standard FMIPv6 where none > of the signaling for establishing a new CoA goes through the old > AR and all of it goes through the new AR. > > > >> The signal should be the BACK from the HA and any CNs, because it > >> is only at > >> that point when the new CoA can really be used. The ARs tear down > >> the tunnel at this point, though they may keep it up for some > >> configurable time period in order to assure that any laggard packets > >> get to the MN. The draft should be more precise about this. > > > > > >Is this based on newAR sniffing the traffic and seeing a Back sent to MN? > > > > It would have to track the BACK. As for sniffing, BU/BACK are > destination options and I thought that routers were allowed > to process destination options? > > >I agree with you on when to configure the CoA. But in BETH, somebody > >is doing a L3-ish handoff on behalf of MN, and MN doesn't even know this. > > > > It is no different than the corner case of standard FMIPv6 in which the > MN does no new CoA establishment signalling on old AR and all of it > on new AR. This is a real possibility in the standard FMIPv6 algorithm, > if movement into the coverage area of the new AR is too fast. > There is no L3-ish handover occuring, everything is happening at > L2 and the ARs are fixing things up at L3 to make sure the MN's traffic > gets to it (this is, after all, what routers are supposed to do). > The L3 handover occurs after the MN is on new AR, if MN so chooses. > > I'm adhering to the following definitions here: > > L2 handover - a change in link connectivity from one > radio access point to another as a consequence of mobile > node movement between radio coverage areas. > > L3 handover - a change in mobile IP care-of address as > a consequence of mobile node movement between one > subnet and another. > > > >F-NA can be replaced by a L2 trigger. Maybe we should clarify this better > >in FMIPv6. The information needed for neighbor cache is already > >in HI message. All newAR needs is an indication of arrival. > > > > I think the draft needs to clarify this. There are a couple places > in the draft that state that the F-NA is the gate. If that's the > case, then I agree that the handover times in Appendix A may > need to be modified. > > > >Once MN has a tunnel from oldAR to newCoA, it doesn't have to wait for > >BU/BACk from CN/HA. Packets sent to oldCoA will be tunneled. MN can > >use newCoA as its source address in the outgoing traffic. > > > > So the only way this is different from BETH is that the MN uses > its old CoA to send outgoing traffic, saving the > signalling traffic over the radio channel for establishing the new CoA. > And the routers maintain the tunnel until the MN is ready to > change CoA. > > > >But this BAck arrival happens at the MN, right? Not at newAR. So, > >how does newAR know this? Sniffing on the network? > > > > BU and BACK are destination options, aren't routers allowed to > process destination options? If they can, then they can note > them as the packets go by. > > jak > alper From owner-mobile-ip@sunroof.eng.sun.com Sun Aug 5 07:33:34 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12605 for ; Sun, 5 Aug 2001 07:33:34 -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 EAA03440; Sun, 5 Aug 2001 04:33: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 EAA24741; Sun, 5 Aug 2001 04:32:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f75BW4p29359 for mobile-ip-dist; Sun, 5 Aug 2001 04:32:04 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f75BW0D29352 for ; Sun, 5 Aug 2001 04:32: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 EAA01068 for ; Sun, 5 Aug 2001 04:32:00 -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 EAA27919 for ; Sun, 5 Aug 2001 04:31: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 f75BVxg14487 for ; Sun, 5 Aug 2001 04:31: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 ABR02387; Sun, 5 Aug 2001 04:31:59 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id EAA14277; Sun, 5 Aug 2001 04:31:59 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15213.11950.934909.815406@thomasm-u1.cisco.com> Date: Sun, 5 Aug 2001 04:31:58 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] [mleech@nortelnetworks.com: Position statement on IKE development] In-Reply-To: <20010803131036.J11736@horus.imag.fr> References: <20010803131036.J11736@horus.imag.fr> 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 In fact, it's probably just the opposite: first of all, it's not really an indictment of IPsec (2401, 2402, 2406) so much as an indictment of IKE. What that says is that the _last_ thing that MIP should be doing is positing extensions or new key distribution protocols when the people who actually understand this are having serious trouble getting it right. Mike John Wells writes: > It's probably a good idea to go forward with a non-IPsec based solution, > particularly in light of this news.. > > john > > -- > John WELLS > Virginia Tech Networking and Visualization Lab > PGP Public key: http://www.ee.vt.edu/~wells/pgpkey.txt > Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) > by birch.ee.vt.edu (8.9.3/8.9.3) with ESMTP id WAA17587 > for ; Thu, 2 Aug 2001 22:25:59 -0400 (EDT) > Received: from horus.imag.fr (horus.imag.fr [129.88.38.2]) > by imag.imag.fr (8.11.3/8.11.3) with ESMTP id f732Pow29664 > for ; Fri, 3 Aug 2001 04:25:50 +0200 (MEST) > Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) > by horus.imag.fr (8.11.3/8.11.3/ImagV2) with ESMTP id f732PpG20201 > for ; Fri, 3 Aug 2001 04:25:52 +0200 (MET DST) > Received: from above.proper.com (above.proper.com [208.184.76.39]) > by imag.imag.fr (8.11.3/8.11.3) with ESMTP id f732Pkw29647 > for ; Fri, 3 Aug 2001 04:25:47 +0200 (MEST) > Received: from localhost (localhost [[UNIX: localhost]]) > by above.proper.com (8.11.3/8.11.3) id f731gMj04101 > for ietf-ipsra-bks; Thu, 2 Aug 2001 18:42:22 -0700 (PDT) > Received: from zcars0m9.ca.nortel.com ([47.129.242.157]) > by above.proper.com (8.11.3/8.11.3) with ESMTP id f731USs03932; > Thu, 2 Aug 2001 18:30:28 -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 f731Tv911913; > Thu, 2 Aug 2001 21:29:58 -0400 (EDT) > Received: from rftzy232.ca.nortel.com by zcars04e.ca.nortel.com; > Thu, 2 Aug 2001 21:30:17 -0400 > Received: from nortelnetworks.com (acart13a.ca.nortel.com [47.129.8.153]) > by rftzy232.ca.nortel.com > with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) > id NKPL6BZ0; Thu, 2 Aug 2001 21:29:59 -0400 > Message-ID: <3B69FF7B.85CF61@nortelnetworks.com> > Date: Thu, 02 Aug 2001 21:33:47 -0400 > From: "Marcus Leech" > Organization: Nortel Networks: Information Systems > X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19 i686) > X-Accept-Language: en > MIME-Version: 1.0 > To: msec@securemulticast.org, ietf-ipsra@vpnc.org, ipsec-policy@vpnc.org, > ipsec@lists.tislabs.com > Subject: Position statement on IKE development > Content-Type: multipart/mixed; boundary="------------700C1CE7C41A16595853A0C3" > X-Orig: > Sender: owner-ietf-ipsra@mail.vpnc.org > Precedence: bulk > List-Archive: > List-ID: > List-Unsubscribe: > > > This is a multi-part message in MIME format. > --------------700C1CE7C41A16595853A0C3 > Content-Type: text/plain; charset=us-ascii > Content-Transfer-Encoding: 7bit > > I'm sending the attached ASCII TEXT document on behalf of myself, Jeff > Schiller, and > Steve Bellovin, to clarify our position with respect to IKE > development. It is our hope > that it will clarify, to some extent, some fuzziness in this area that > has evolved over > the last year or so. > --------------700C1CE7C41A16595853A0C3 > Content-Type: text/plain; charset=us-ascii; > name="statement.txt" > Content-Transfer-Encoding: 7bit > Content-Disposition: inline; > filename="statement.txt" > > In the several years since the standardization of the IPSEC protocols > (ESP, AH, and ISAKMP/IKE), there have come to light several security > problems with the protocols, most notably the key-agreement protocol, > IKE. Formal and semi-formal analyses by Meadows, Schneier et al, and > Simpson, have shown that the security problems in IKE stem directly > from its complexity. It seems only a matter of time before more > analyses show more serious security issues in the protocol design that > stem directly from its complexity. It seems also, only a matter of > time, before serious *implementation* problems become apparent, again > due to the complex nature of the protocol, and the complex > implementation that must surely follow. > > Despite the obviously complex nature of IKE, several proposals have > been put forward to extend ISAKMP/IKE in various ways, for various > purposes. Proposals such as IKECFG, XAUTH, Hybrid-AUTH, CRACK, and > others do nothing to improve the complexity situation with regard to > IKE as a whole. While many of these proposals are, individually, > based on sound engineering and reasonably prudent practice, when cast > in the larger context of IKE, it seems clear that they can do nothing > to improve the complexity picture. > > It is with that in mind that the Security Area directors in the IETF, > with the consultation of appropriate people on the IESG and IAB, hereby > place a temporary moratorium on the addition of new features to IKE. > It is fairly clear that work on IKE should focus on fixing identified > weaknesses in the protocol, rather than adding features that detract > from the goal of simplicity and correctness. > > We are concerned that trying to reuse too much of the IKE > code base in new protocols -- PIC and GDOI come to mind -- > will lead to more complex (and hence vulnerable) implementations. > We suggest that implementors resist this temptation, with the > obvious exception of common library functions that perform > functions such as large modular exponentiations. Attempts > to share state or to optimize message exchanges are likely to > lead to disaster. > > The Security Area Directors have asked the IPSEC working group to come > up with a replacement for IKE. This work is underway and is known in > the community as "Son of IKE". This effort is at serious risk of > suffering the "second system effect", where all the features that were > left out of the first version, end up in the second. For this to > happen would be a spectacular disaster, and very much detract from the > goal: to produce a more secure, simpler, and more robust version of IKE. > > Arriving at this point has been exceedingly difficult and harrowing. > Understandably, egos have been bruised, and the "change not the IKE, > for it is subtle and quick to anger" position has been taken as a > personal afront by some members of the IPSEC community. Nothing could > be further from the intent of either of the Security Area directors. > If IKE is vulnerable, we must all share a burden of responsibility for > allowing it to get to the state it is in and we must all work together > to correct the problems. > > The IPSEC community must act prudently in moving forward with a > replacement for IKE. The IPSEC auxillary groups (IPSRA, MSEC, IPSP) > must act with good judgment (chairs and members alike) in designing > protocols that don't interfere with the goal of security and > simplifying our IPSEC key-agreement protocol. > > > Marcus Leech (IESG) > Jeff Schiller (IESG) > Steve Bellovin (IAB) > > --------------700C1CE7C41A16595853A0C3-- From owner-mobile-ip@sunroof.eng.sun.com Sun Aug 5 07:58:44 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12892 for ; Sun, 5 Aug 2001 07:58:43 -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 EAA05357; Sun, 5 Aug 2001 04:59: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 EAA25405; Sun, 5 Aug 2001 04:58:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f75Bw4i29455 for mobile-ip-dist; Sun, 5 Aug 2001 04:58:04 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f75Bw0D29448 for ; Sun, 5 Aug 2001 04:58:00 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA10538 for ; Sun, 5 Aug 2001 04:57:55 -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 FAA22164 for ; Sun, 5 Aug 2001 05:57:54 -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 f75Bw8Y19125; Sun, 5 Aug 2001 04:58: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 ABR02413; Sun, 5 Aug 2001 04:57:53 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id EAA14286; Sun, 5 Aug 2001 04:57:52 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15213.13504.864265.809872@thomasm-u1.cisco.com> Date: Sun, 5 Aug 2001 04:57:52 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Cc: "John Wells" Subject: Re: [mobile-ip] [mleech@nortelnetworks.com: Position statement on IKE development] In-Reply-To: <01e701c11caa$e54c85a0$8a1b6e0a@arenanet.fi> References: <20010803131036.J11736@horus.imag.fr> <01e701c11caa$e54c85a0$8a1b6e0a@arenanet.fi> 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 agree with Jari. With the potential exception of nuking AH (which is discussed and re-discussed often; Steve Bellovin may make one final attempt to kill it. I hope.), base 2401 is not what is really at issue. Indeed, I just spoke to Marcus about KINK's reuse of IKE phase 2 (quick mode) and he thought that that was OK as is. It's main mode (aka the authentication phase) that needs simplification. This shouldn't be surprising since it's the Really Hard Problem. Mike Jari Arkko writes: > John Wells wrote: > > >It's probably a good idea to go forward with a non-IPsec based solution, > >particularly in light of this news.. > > It is indeed bad news. But, I'd just like to point out that the position statement > said that a replacement for IKE should be designed (and is being > designed, called Son-of-IKE). That is, a redesign of IPsec AH/ESP > wasn't called for. In the mobile IPv6 case we have already > given up the hope of using IKE to key BUs in the global Internet. > But we could still use AH/ESP to protect the BUs, BAKE for keying > in the global Internet, and IKE, KINK or Son-of-IKE (when available) for > keying in the Intranet. > > Jari > > > From owner-mobile-ip@sunroof.eng.sun.com Sun Aug 5 08:42:30 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13440 for ; Sun, 5 Aug 2001 08:42: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 FAA08182; Sun, 5 Aug 2001 05:43: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 FAA26894; Sun, 5 Aug 2001 05:43:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f75CgGt29590 for mobile-ip-dist; Sun, 5 Aug 2001 05:42:16 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f75CgCD29583 for ; Sun, 5 Aug 2001 05:42:12 -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 FAA02147 for ; Sun, 5 Aug 2001 05:42:13 -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 GAA03752 for ; Sun, 5 Aug 2001 06:42:10 -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 f75CgRY25442; Sun, 5 Aug 2001 05:42:27 -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 ABR02474; Sun, 5 Aug 2001 05:42:11 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id FAA14296; Sun, 5 Aug 2001 05:42:11 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15213.16163.492329.650235@thomasm-u1.cisco.com> Date: Sun, 5 Aug 2001 05:42:11 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Cc: Hemant.Chaskar@nokia.com Subject: [mobile-ip] Comments on draft-ietf-mobileip-qos-requirements-00.txt In-Reply-To: <200108032351.f73Np6b130775@jurassic.eng.sun.com> References: <200108032351.f73Np6b130775@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 In general, it would be better to steer clear of "better" or "worse" wrt wireless (as if that were a monolithic thing anyway). RSVP as a general qos signaling mechanism is what we have now, and it seems quite reasonable to point out things which are not going to work well. The same thing obviously needs to be done with diffserv too, but you wouldn't expect nearly as many issues since it's mainly a L2/L3 queuing problem which can be safely brushed aside :-) Mike Samita Chakrabarti writes: > Hello Hemant: > > I am reading the mobileip-qos requirement draft again, and I think it > is still missing some clarification and some of my comments on mip-qos > alias were not addressed. Let me explain them here again, and why I think > they should be in the requirement document. > > 1. I assume the goal of the requirement document is not to provide or point > to any particular qos solution for mobile-ip. Yet, at number of cases, in > the document we have references and examples of RSVP qos mechanism. Is it > because we do not have any experience or data available for other Qos > mechanism(such as diffserv) for mobile ip ? Or is it trying to point out > some of the drawbacks of RSVP in mobileip environment ? > > If we discuss problems or merits of qos mechanism, we should discuss > that for different mechanisms. May be the examples belong to appendix. > For example, diffserv seems more appropriate to me in mobileip case, but > then it may need to have some dynamic service level agreements between > the nodes where the handover is taking place. > > > 2. section 3.1, bullet item 2, it states: > "Of course, if > the end-to-end path changes at large after handover, the QoS > mechanism MUST be able to address that in a manner that is > consistent with the QoS scheme(s) used along the new > end-to-end packet path." > > By "new end-to-end" path it means the path between two communicating nodes. > Should not it say that Qos mechanism should be established in the 'changed > or new end-to-end' path depending on the Qos mechanism ? > > > 3. The scalabality is a mobileip specific qos issue that this requirement > draft needs to clarify. As JC Martin and I requested the following item in > our earlier comments to mip-qos alias: > > A salability requirement could be that no per MN state should be kept > in the inner nodes: state should be contained as close as possible to the > MN. Also : if the QoS Mechanism is using signaling, it should be aggregated > as close as possible to the MN. > > > 4. > How about adding a section here for 'inter-technology > handoff'. What's our qos requirement there? > Do we expect it to be transparent as it's happening in IP layer ? > > > 5. The obvious requirement section is not too obvious to many. Can we clarify? > > > Thanks! > -Samita > From owner-mobile-ip@sunroof.eng.sun.com Sun Aug 5 09:06:33 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13649 for ; Sun, 5 Aug 2001 09:06: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 GAA09859; Sun, 5 Aug 2001 06:07: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 GAA27675; Sun, 5 Aug 2001 06:07:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f75D60T29683 for mobile-ip-dist; Sun, 5 Aug 2001 06:06:00 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f75D5uD29676 for ; Sun, 5 Aug 2001 06:05: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 GAA27620 for ; Sun, 5 Aug 2001 06:05:57 -0700 (PDT) Received: from hygro.adsl.duke.edu (host217-33-136-191.ietf.ignite.net [217.33.136.191]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA06928 for ; Sun, 5 Aug 2001 07:05:54 -0600 (MDT) Received: from hygro.adsl.duke.edu (narten@localhost) by hygro.adsl.duke.edu (8.11.2/8.9.3) with ESMTP id f75D47014959 for ; Sun, 5 Aug 2001 09:04:07 -0400 Message-Id: <200108051304.f75D47014959@hygro.adsl.duke.edu> To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Concerns about draft-mipv6-14 section 4.8 In-Reply-To: Message from "Charles E. Perkins" of "Sat, 04 Aug 2001 08:43:26 PDT." <3B6C181E.38245FC6@iprg.nokia.com> Date: Sun, 05 Aug 2001 09:04:07 -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: > As noted, I had made an attempt to update the Mobile IPv6 > specification towards assisting the problems with mobile routers. > However, making it into a separate draft looks like a better idea. > For the base draft, should the prefix length bits be marked as > "reserved"? The Mobile Router Prefix Length Sub-Option would be > removed, too. Another reason for why MR should be stand alone. How one properly secures and authorizes a BU for an entire prefix would seem to be to add significant additional non-trivial issues to consider. It would seem to me that the address ownership problem is plenty hard for just one address. Trying to extend it to the case where a node (i.e, the MR) is asserting to a CN that the CN should tunnel *all* packets covered by an entire prefix would seem to be even harder. Thomas From owner-mobile-ip@sunroof.eng.sun.com Sun Aug 5 09:20:56 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13733 for ; Sun, 5 Aug 2001 09:20: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 HAA09252; Sun, 5 Aug 2001 07:21: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 GAA12865; Sun, 5 Aug 2001 06:20:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f75DJtn29764 for mobile-ip-dist; Sun, 5 Aug 2001 06:19:55 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f75DJpD29757 for ; Sun, 5 Aug 2001 06:19: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 GAA04014 for ; Sun, 5 Aug 2001 06:19:52 -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 GAA08375 for ; Sun, 5 Aug 2001 06:19:52 -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 f75DJug00548 for ; Sun, 5 Aug 2001 06:19: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 ABR02529; Sun, 5 Aug 2001 06:19:51 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id GAA14321; Sun, 5 Aug 2001 06:19:40 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15213.18412.718267.985105@thomasm-u1.cisco.com> Date: Sun, 5 Aug 2001 06:19:40 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Concerns about draft-mipv6-14 section 4.8 In-Reply-To: <200108051304.f75D47014959@hygro.adsl.duke.edu> References: <3B6C181E.38245FC6@iprg.nokia.com> <200108051304.f75D47014959@hygro.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: > "Charles E. Perkins" writes: > > > As noted, I had made an attempt to update the Mobile IPv6 > > specification towards assisting the problems with mobile routers. > > However, making it into a separate draft looks like a better idea. > > For the base draft, should the prefix length bits be marked as > > "reserved"? The Mobile Router Prefix Length Sub-Option would be > > removed, too. > > Another reason for why MR should be stand alone. How one properly > secures and authorizes a BU for an entire prefix would seem to be to > add significant additional non-trivial issues to consider. I doubt it. While I agree that mobile routers ought to be broken out, I'd be very, very afraid of any security solution which made a distinction between /32 (/128)) and a smaller prefix. They really are the exact same routing authorization problem (eg, something wants you to modify your routing entry for prefix X). Mike From owner-mobile-ip@sunroof.eng.sun.com Sun Aug 5 09: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 ESMTP id JAA13772 for ; Sun, 5 Aug 2001 09:23:09 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA09641; Sun, 5 Aug 2001 07:23: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 GAA13016; Sun, 5 Aug 2001 06:23:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f75DMe629809 for mobile-ip-dist; Sun, 5 Aug 2001 06:22:40 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f75DMbD29802 for ; Sun, 5 Aug 2001 06:22: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 GAA03410 for ; Sun, 5 Aug 2001 06:22:37 -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 GAA06800; Sun, 5 Aug 2001 06:22:36 -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 f75DMXg00990; Sun, 5 Aug 2001 06:22: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 ABR02532; Sun, 5 Aug 2001 06:22:24 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id GAA14324; Sun, 5 Aug 2001 06:22:24 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15213.18576.561468.994392@thomasm-u1.cisco.com> Date: Sun, 5 Aug 2001 06:22:24 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Cc: Hesham.Soliman@era.ericsson.se, pcalhoun@diameter.org, James.Kempf@sun.com, charliep@iprg.nokia.com Subject: [mobile-ip] Re: So what is bicasting vs. buffering In-Reply-To: <200108022243.PAA08364@heliopolis.eng.sun.com> References: <200108022243.PAA08364@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 To my mind, signaling/not singaling and bicasting/buffering are orthogonal. In fact, bicasting and buffering aren't even in opposition to one another; you may or may not buffer bicasted packets. Mike kempf writes: > Pat, > > > >So in my mind, I believe that the main difference between the bicasting > >and buffering approaches is simply that the latter requires the mobile > >to *request* packets. > > > > I think this is the proposal in the primary reference > (draft-krishnamurthi-mobileip-buffer6-01.txt). It need not, however, be > so. If just the packets arriving during L2 handover are > buffered on new AR, as proposed in Appendix B of the BETH draft, then > new AR can quickly download the buffer when the MN arrives on the new > link, as you pointed out yesterday. The advantage of this is no > signalling over the radio link, which means the radio link is free > for the user's real time traffic, not MIP signalling. > > jak > From owner-mobile-ip@sunroof.eng.sun.com Sun Aug 5 09:57:13 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14056 for ; Sun, 5 Aug 2001 09:57: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 HAA14334; Sun, 5 Aug 2001 07:57: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 GAA29169; Sun, 5 Aug 2001 06:57:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f75DuFI00056 for mobile-ip-dist; Sun, 5 Aug 2001 06:56:15 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f75DuAD00048 for ; Sun, 5 Aug 2001 06:56:11 -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 GAA14124 for ; Sun, 5 Aug 2001 06:56:11 -0700 (PDT) Received: from hygro.adsl.duke.edu (host217-33-136-191.ietf.ignite.net [217.33.136.191]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA14022 for ; Sun, 5 Aug 2001 07:56:08 -0600 (MDT) Received: from hygro.adsl.duke.edu (narten@localhost) by hygro.adsl.duke.edu (8.11.2/8.9.3) with ESMTP id f75DsMW15414 for ; Sun, 5 Aug 2001 09:54:22 -0400 Message-Id: <200108051354.f75DsMW15414@hygro.adsl.duke.edu> To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Concerns about draft-mipv6-14 section 4.8 In-Reply-To: Message from Michael Thomas of "Sun, 05 Aug 2001 06:19:40 PDT." <15213.18412.718267.985105@thomasm-u1.cisco.com> Date: Sun, 05 Aug 2001 09:54: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: > I doubt it. While I agree that mobile routers ought to be broken > out, I'd be very, very afraid of any security solution which made > a distinction between /32 (/128)) and a smaller prefix. They > really are the exact same routing authorization problem (eg, > something wants you to modify your routing entry for prefix X). Authorization seems harder (but perhaps I'm wrong). There are already drafts that describe ways of for a particular node to assert it "owns" address X, and then later have that node reassert that it can still prove that it is the same entity that made the assertion earlier, even when its address has changed. So, here we have one address being able to assert that was used by the same entity as a previous addresss. This would seem to me to be a rather different (and even orthogonal) problem to that of a router being able to assert that is is authorized to "intercept" all traffic covered by a prefix. How can one prove to a correspondent node that some router foo, is authorized to have all traffic destined to (say) MIT rerouted through it? Thomas From owner-mobile-ip@sunroof.eng.sun.com Sun Aug 5 11:10:27 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14689 for ; Sun, 5 Aug 2001 11:10: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 JAA24758; Sun, 5 Aug 2001 09:11: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 IAA01285; Sun, 5 Aug 2001 08:10:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f75FA0I00263 for mobile-ip-dist; Sun, 5 Aug 2001 08:10:00 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f75F9uD00256 for ; Sun, 5 Aug 2001 08:09: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 IAA15853 for ; Sun, 5 Aug 2001 08:09:56 -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 IAA19573 for ; Sun, 5 Aug 2001 08:09:56 -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 f75FABY17981 for ; Sun, 5 Aug 2001 08:10: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 ABR02689; Sun, 5 Aug 2001 08:09:56 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA14354; Sun, 5 Aug 2001 08:09:56 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15213.25027.999621.497966@thomasm-u1.cisco.com> Date: Sun, 5 Aug 2001 08:09:55 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Concerns about draft-mipv6-14 section 4.8 In-Reply-To: <200108051354.f75DsMW15414@hygro.adsl.duke.edu> References: <15213.18412.718267.985105@thomasm-u1.cisco.com> <200108051354.f75DsMW15414@hygro.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: > > I doubt it. While I agree that mobile routers ought to be broken > > out, I'd be very, very afraid of any security solution which made > > a distinction between /32 (/128)) and a smaller prefix. They > > really are the exact same routing authorization problem (eg, > > something wants you to modify your routing entry for prefix X). > > Authorization seems harder (but perhaps I'm wrong). Service Problem Authentication Impossible to scale globally Authorization Breeds impossible and arbitrary bureaucrats > There are already > drafts that describe ways of for a particular node to assert it "owns" > address X, and then later have that node reassert that it can still > prove that it is the same entity that made the assertion earlier, even > when its address has changed. So, here we have one address being able > to assert that was used by the same entity as a previous addresss. > > This would seem to me to be a rather different (and even orthogonal) > problem to that of a router being able to assert that is is authorized > to "intercept" all traffic covered by a prefix. I think that the concept that needs to be recognized is that a host receiving a binding update is conceptually a *router*, not a host per se. That is, it creates and maintains routing tables. As such, there's really no difference between the actions which one performs on a /128 vs. a /8, say. Or at least that's how I'd view something that causes you to FIB entires, create tunnel interfacess, etc. > How can one prove to a correspondent node that some router foo, is > authorized to have all traffic destined to (say) MIT rerouted through > it? Well, the two methods being floated right now are 1) strong authentication based on some form of strong crypto. 2) weak authentication based on a return routability test. It seems pretty clear that (1) will suffer the same scaling limitations as /128's in a world of Jetson car based mobile routers... that seems to leave (2) unless we have some sort of breakthrough alternative that's neither (1) or (2); unless R, S, A, D, or H have another miracle up their sleaves, I'm not real confident about that though. Maybe this is a case where the security realities inform the protocol design rather than the more usual reverse? Naw... never happen. :-) Mike From owner-mobile-ip@sunroof.eng.sun.com Sun Aug 5 11:24:17 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14820 for ; Sun, 5 Aug 2001 11:24: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 JAA26876; Sun, 5 Aug 2001 09:24:54 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA01768; Sun, 5 Aug 2001 08:24:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f75FNNQ00368 for mobile-ip-dist; Sun, 5 Aug 2001 08:23:23 -0700 (PDT) Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f75FNGD00355 for ; Sun, 5 Aug 2001 08:23:16 -0700 (PDT) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f75FNA217862; Sun, 5 Aug 2001 17:23:10 +0200 (MET DST) Date: Sun, 5 Aug 2001 14:55:46 +0200 (CEST) From: Erik Nordmark Subject: Re: [mobile-ip] Concern over draft-team-mobileip-mipv6-sec-reqts-00.txt To: "Charles E. Perkins" Cc: Erik Nordmark , mobile-ip@sunroof.eng.sun.com, Jari Arkko , Jean-Michel COMBES 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 Erik, > > I thought that we were going to have to devise a way for all > IPv6 nodes to get security associations with mobile nodes. > Isn't IKE too much to ask from every IPv6 node? And, yet, > I agree that we should have a way to use IKE to get keys that > would be useful for authenticating Binding Updates. I just > expected it wouldn't be the universally mandated way. Charlie, your comments seem to be unrelated to my comment. I was merely commenting on what looked like a statement that IKE can be used to create security associations for something other that ESP and AH. Thus my comment had no direct association with mobile IPv6. Erik > Erik Nordmark wrote: > > > > > Therefore, we are free to choose between > > > MIP-specific BU protection and IPsec AH independent of how > > > the key management is solved. > > > > You are assuming that it is easy to use IKE to create non-IPsec keys e.g. > > for MIP specific BU protection. > > Are you sure it is that easy? > > (I don't have any data - but I thought IKE was tied to IPsec.) > > > > Erik From owner-mobile-ip@sunroof.eng.sun.com Sun Aug 5 11:24:51 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14848 for ; Sun, 5 Aug 2001 11:24: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 JAA27183; Sun, 5 Aug 2001 09:25: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 IAA01858; Sun, 5 Aug 2001 08:25:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f75FOWV00397 for mobile-ip-dist; Sun, 5 Aug 2001 08:24:32 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f75FORD00390 for ; Sun, 5 Aug 2001 08:24:27 -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 IAA16784 for ; Sun, 5 Aug 2001 08:24:27 -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 IAA22780 for ; Sun, 5 Aug 2001 08:24:26 -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 f75FMdJ14437 for ; Sun, 5 Aug 2001 08:22: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 ABR02718; Sun, 5 Aug 2001 08:24:24 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA14357; Sun, 5 Aug 2001 08:24:24 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15213.25896.160897.773274@thomasm-u1.cisco.com> Date: Sun, 5 Aug 2001 08:24:24 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Re: Analysis of Latency Propagation with Buffering In-Reply-To: <200108022048.NAA03577@heliopolis.eng.sun.com> References: <200108022048.NAA03577@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 Jim -- I hope that this is obvious, but whether the user experiences a blip or not is dependent on the length of the jitter buffer. If you have long jitter buffer, you can smooth out blips like handover delays quite nicely, so it's not necessarily the user experience per se. This comes at the expense of added e2e delay, but it's probably not linearly additive with point sources of delay. That is, the sum of the worst case jitter per hop >> average jitter experienced. That said, I think it's worth considering the effect of the rather large and potentially frequent effect of handoffs and/or buffering, but I don't think it's worthwhile to think of this in terms of absoulte numbers at individual hops since jitter buffer hueristics along with intra-speech spurt repositioning of the playback delay can go a very long way to smoothing a lot of network kruftiness. (this would be even more true if you have application layer triggers in your jitter adjustments on impending handoffs.) Mike James Kempf writes: > Erik Nordmark posted a note earlier this week pointing out that > the formula I sent out was the total time over which incoming > packets are delayed, not the delay experienced by an individual > packet. My response was that the figure of merit of interest > was the delay experienced by the user. > > Upon further reflection, I realized Erik's point. The user experience > will, in fact, depend on the delay experienced by an individual > packet. If a voice packet from the CN is delayed by 100 ms, then > the user will perceive a gap in the converstation. The importance > of the formula I sent out (R = T(0) / (1 - A/B)) is that it gives > the total amount of time during which buffering is occuring. The > fraction of that total amount during which the per packet delay is > greater than the user perceivable delay indicates how long the > user must wait until the conversation no longer sounds stilted. > If that amount of time is short, then there is a short blip. If > it is long, then the user ends up in a half duplex conversation. > So R reflects how long the buffering latency from handover will propagate. > > IMHO, this alters the conclusions for buffering only a little. > The handover latency will still propagate, but as long as the handover delay is > less than the user perceivable amount, the latency will not be noticable. > If it is greater, then either there will be a short blip (if the > latency is small) or the user will have a half duplex converstation > for a period with a duration depending on how long it takes the > buffering series to move below the perception threshold. In any event, > since the bound is pretty tight, it will be difficult to meet it if > there is any L3 latency in handover. > > jak > > From owner-mobile-ip@sunroof.eng.sun.com Sun Aug 5 11:29:52 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14910 for ; Sun, 5 Aug 2001 11:29: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 IAA19461; Sun, 5 Aug 2001 08:30: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 IAA10707; Sun, 5 Aug 2001 08:30:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f75FTUb00511 for mobile-ip-dist; Sun, 5 Aug 2001 08:29:30 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f75FTQD00504 for ; Sun, 5 Aug 2001 08:29:26 -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 IAA02078 for ; Sun, 5 Aug 2001 08:29:26 -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 IAA23493 for ; Sun, 5 Aug 2001 08:29:26 -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 f75FTRg21757; Sun, 5 Aug 2001 08:29:27 -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 ABR02728; Sun, 5 Aug 2001 08:29:21 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA14360; Sun, 5 Aug 2001 08:29:21 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15213.26193.532083.393462@thomasm-u1.cisco.com> Date: Sun, 5 Aug 2001 08:29:21 -0700 (PDT) To: "Hesham Soliman (ERA)" Cc: "'Michael Thomas '" , "'mobile-ip@sunroof.eng.sun.com '" , "''Vijay Devarapalli ' '" Subject: RE: [mobile-ip] Concern over draft-team-mobileip-mipv6-sec-reqts- 00.txt In-Reply-To: <034BEFD03799D411A59F00508BDF754603008B9F@esealnt448.al.sw.ericsson.se> References: <034BEFD03799D411A59F00508BDF754603008B9F@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: > IPsec selectors > do not define a standard way to use the port numbers in > the ID payload to select for different destination options. > This is probably not that hard to define, but it's not > standard now. > > => My point has been that, provided there is no piggybacking > we can keep the selectors' granularity as they > are by creating a new nxt header value or > increase the granularity by looking for > the BU option. ONLY packets with the BU option > will be protected in either case. If we burned a new protocol number, that's correct. Maybe I'm the only one who has a lot of reluctance of burning protocol numbers... Mike From owner-mobile-ip@sunroof.eng.sun.com Sun Aug 5 11:39:01 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15084 for ; Sun, 5 Aug 2001 11:39: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 JAA29670; Sun, 5 Aug 2001 09:39:51 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA11096; Sun, 5 Aug 2001 08:38:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f75Fbel00636 for mobile-ip-dist; Sun, 5 Aug 2001 08:37:40 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f75FbaD00629 for ; Sun, 5 Aug 2001 08: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 IAA02471; Sun, 5 Aug 2001 08:37:36 -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 JAA29323; Sun, 5 Aug 2001 09:37:34 -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 f75FbZg23247; Sun, 5 Aug 2001 08:37:35 -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 ABR02751; Sun, 5 Aug 2001 08:37:34 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA14363; Sun, 5 Aug 2001 08:37:34 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15213.26686.182075.513610@thomasm-u1.cisco.com> Date: Sun, 5 Aug 2001 08:37:34 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Cc: hesham.soliman@era.ericsson.se, mohan.parthasarathy@eng.sun.com Subject: Re: [mobile-ip] Authentication Data as a BU suboption In-Reply-To: <3B686ACF.AFCA9F86@iprg.nokia.com> References: <034BEFD03799D411A59F00508BDF754603008B9C@esealnt448.al.sw.ericsson.se> <3B686ACF.AFCA9F86@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: > from Mohan's mail > > > From RFC2409, > > > > Phase 2 is where Security Associations are negotiated on behalf of > > services such as IPsec or any other service which needs key material > > and/or parameter negotiation. "Quick Mode" accomplishes a phase 2 > > exchange. "Quick Mode" MUST ONLY be used in phase 2. > > > > the main thing in the above paragraph is "or any other service which > needs key material". > > IKE is for key exchange. IKE/BAKE/PKI/AAA can all establish > a key between two nodes. extract the security association from > the database, store it in the binding update list and use > it to authenticate the BU. the SA is stored in the binding > cache entry in case of the CN. BAKE & friends can only establish a key if they do an ephemeral Diffie Hellman, which according to the analysis draft is discouraged. As I've said earlier, since we have the opportunity to have soft state with weak authorization, we should seize the opportunity since it makes life much, much more robust on many fronts. Mike From owner-mobile-ip@sunroof.eng.sun.com Sun Aug 5 11:46:08 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15134 for ; Sun, 5 Aug 2001 11:46: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 JAA00859; Sun, 5 Aug 2001 09:46: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 IAA11449; Sun, 5 Aug 2001 08:46:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f75Fji600742 for mobile-ip-dist; Sun, 5 Aug 2001 08:45:44 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f75FjeD00731 for ; Sun, 5 Aug 2001 08:45:40 -0700 (PDT) Received: from heliopolis.Eng.Sun.COM (euroapp.Holland.Sun.COM [129.159.197.58]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA14879; Sun, 5 Aug 2001 08:45:34 -0700 (PDT) From: James Kempf Message-Id: <200108051545.IAA14879@heliopolis.eng.sun.com> Date: Sun, 5 Aug 2001 16:44:09 +0-100 To: , Subject: RE: [mobile-ip] BETH comments and questions 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 Alper, >- During a real-time communication, if your MN detects that it has attached to a >new L2, what does it do? It'd hope that oldAR and newAR are doing BETH and MN >would do nothing, as I understand. But, what if the newAR is not BETH capable, >or BETH has failed for some reason. The only way to figure this out is to wait, >I think. There seems to be no other way, because there's no L3 signalling >between MN and newAR. And this wait will effect the handoff time, if newAR is >not doing BETH. > As Ajoy pointed out, if the real time packet stream fails, the MN can simply go ahead and establish its CoA. The point of BETH is to eliminate L3 signalling so the radio link is free for real time traffic. If there is no real time traffic, then the MN can go ahead and get a new CoA. But the issue you bring up about a router not being BETH capable obviously holds for FMIPv6 too. In that case, the MN learns that it can't do FMIPv6 because it doesn't get a reply for RqstPrxyRtAdv, but by that time it could already be on the new AR. Though I dislike adding knobs where they might not be needed (because they add complexity) perhaps the admission control procedure needs to inform the MN about what handover options it has. Better would be to simply make fast handover a required part of MIPv6, to avoid having the situation where a router doesn't support it (in the long run). >- BU/Back are destination options. Therefore they are only processed by the >destinations, MN/CN/HA. If routers want to take a peek on them, they can do so. >But, designing the protocol based on sniffing packets on the wire makes me >worried. One thing, it's not guaranteed that this packet will go through this >router, as there can be more than one on the link. Secondly, if one day this >packet is encrypted, or a new flavor of BU/BAck is used, this won't work. > OK. Perhaps an explicit BU to the new AR when the new CoA is totally in place is the right way to go. >We should clarify the use of L2 triggers in FMIPv6. > Yes, while I agree with trying to make it general, if there are abstract L2 triggers, it should be possible to write the draft such that there is no dependence on a specific L2. As it now is, there are implicit assumptions about L3 obtaining handover sequencing information that I think might make it difficult to implement by someone who was not part of the initial design group. jak From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 6 04:30:49 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19349 for ; Mon, 6 Aug 2001 04:30:48 -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 BAA22435; Mon, 6 Aug 2001 01:31: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 BAA06654; Mon, 6 Aug 2001 01:29:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f768SBH02258 for mobile-ip-dist; Mon, 6 Aug 2001 01:28:11 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f768S7D02247 for ; Mon, 6 Aug 2001 01:28:07 -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 BAA06495 for ; Mon, 6 Aug 2001 01:28: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 CAA24430 for ; Mon, 6 Aug 2001 02:28:05 -0600 (MDT) Received: (qmail 8266 invoked by uid 500); 6 Aug 2001 08:16:56 -0000 Date: Mon, 6 Aug 2001 01:16:56 -0700 From: Pat Calhoun To: mobile-ip@sunroof.eng.sun.com Cc: Pat Calhoun Subject: Re: [mobile-ip] Handover Smoothing - What to Do? Message-ID: <20010806011656.V7242@charizard.diameter.org> References: <9FBD322B7824D511B36900508BF93C9C9F5EAC@zcard031.ca.nortel.com> <3B6C1B7E.E227DB4B@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: <3B6C1B7E.E227DB4B@iprg.nokia.com>; from charliep@iprg.nokia.com on Sat, Aug 04, 2001 at 08:57:50AM -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 conclusion is that any use of bicasting needs to be strictly > limited in time, with well-defined start and stop times. The > ability to define these start and stop times is crucial, and yet > whenever it is possible to do so, it might equally well be possible > to design protocol so that unicast packets go where they ought to go. That sounds reasonable. PatC From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 6 04:44:56 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19680 for ; Mon, 6 Aug 2001 04:44: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 BAA26077; Mon, 6 Aug 2001 01:45: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 BAA08076; Mon, 6 Aug 2001 01:44:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f768hwB02352 for mobile-ip-dist; Mon, 6 Aug 2001 01:43:58 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f768hsD02345 for ; Mon, 6 Aug 2001 01:43: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 BAA07965 for ; Mon, 6 Aug 2001 01:43:56 -0700 (PDT) Received: from hygro.adsl.duke.edu (host217-33-136-192.ietf.ignite.net [217.33.136.192]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA09039 for ; Mon, 6 Aug 2001 01:43:55 -0700 (PDT) Received: from hygro.adsl.duke.edu (narten@localhost) by hygro.adsl.duke.edu (8.11.2/8.9.3) with ESMTP id f768g7a19627 for ; Mon, 6 Aug 2001 04:42:07 -0400 Message-Id: <200108060842.f768g7a19627@hygro.adsl.duke.edu> To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Concerns about draft-mipv6-14 section 4.8 In-Reply-To: Message from Michael Thomas of "Sun, 05 Aug 2001 08:09:55 PDT." <15213.25027.999621.497966@thomasm-u1.cisco.com> Date: Mon, 06 Aug 2001 04:42:07 -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: > > There are already > > drafts that describe ways of for a particular node to assert it "owns" > > address X, and then later have that node reassert that it can still > > prove that it is the same entity that made the assertion earlier, even > > when its address has changed. So, here we have one address being able > > to assert that was used by the same entity as a previous addresss. > > > > This would seem to me to be a rather different (and even orthogonal) > > problem to that of a router being able to assert that is is authorized > > to "intercept" all traffic covered by a prefix. > I think that the concept that needs to be recognized is > that a host receiving a binding update is conceptually > a *router*, not a host per se. That is, it creates > and maintains routing tables. As such, there's really > no difference between the actions which one performs > on a /128 vs. a /8, say. Or at least that's how I'd > view something that causes you to FIB entires, create > tunnel interfacess, etc. This may be true, from the specific view of the mechanics of installing a route into the routing tables of a local device, route lookup while forwarding a packet, etc. That is not the point I'm trying to make. > > How can one prove to a correspondent node that some router foo, is > > authorized to have all traffic destined to (say) MIT rerouted through > > it? > Well, the two methods being floated right now are > 1) strong authentication based on some form of strong > crypto. My question concerns *authorization*, not authentication. If a CN gets a BU from a node claiming to be a router for a prefix (e.g., all of MIT), how does the CN decide that this is really a legitimate route entry to install, as opposed to an intruder attempting to hijact MIT's traffic? > Maybe this is a case where the security realities inform the > protocol design rather than the more usual reverse? Indeed. One needs to understand the security requirements prior to designing the protocol, as some protocol designs may turn out to be inherently flawed once the security requirements are understood. Thomas From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 6 05:38:27 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20410 for ; Mon, 6 Aug 2001 05:38:26 -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 DAA01470; Mon, 6 Aug 2001 03:39:09 -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 CAA17668; Mon, 6 Aug 2001 02:38:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f769bXY02540 for mobile-ip-dist; Mon, 6 Aug 2001 02:37:33 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f769bTD02533 for ; Mon, 6 Aug 2001 02:37:29 -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 CAA17600 for ; Mon, 6 Aug 2001 02:37:31 -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 CAA28257 for ; Mon, 6 Aug 2001 02:37:31 -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 f769bf325311 for ; Mon, 6 Aug 2001 02:37:41 -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 ABS01379; Mon, 6 Aug 2001 02:37:29 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id CAA14626; Mon, 6 Aug 2001 02:37:29 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15214.25945.21229.61552@thomasm-u1.cisco.com> Date: Mon, 6 Aug 2001 02:37:29 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Concerns about draft-mipv6-14 section 4.8 In-Reply-To: <200108060842.f768g7a19627@hygro.adsl.duke.edu> References: <15213.25027.999621.497966@thomasm-u1.cisco.com> <200108060842.f768g7a19627@hygro.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: > Michael Thomas writes: > > > > There are already > > > drafts that describe ways of for a particular node to assert it "owns" > > > address X, and then later have that node reassert that it can still > > > prove that it is the same entity that made the assertion earlier, even > > > when its address has changed. So, here we have one address being able > > > to assert that was used by the same entity as a previous addresss. > > > > > > This would seem to me to be a rather different (and even orthogonal) > > > problem to that of a router being able to assert that is is authorized > > > to "intercept" all traffic covered by a prefix. > > > I think that the concept that needs to be recognized is > > that a host receiving a binding update is conceptually > > a *router*, not a host per se. That is, it creates > > and maintains routing tables. As such, there's really > > no difference between the actions which one performs > > on a /128 vs. a /8, say. Or at least that's how I'd > > view something that causes you to FIB entires, create > > tunnel interfacess, etc. > > This may be true, from the specific view of the mechanics of > installing a route into the routing tables of a local device, route > lookup while forwarding a packet, etc. That is not the point I'm > trying to make. > > > > How can one prove to a correspondent node that some router foo, is > > > authorized to have all traffic destined to (say) MIT rerouted through > > > it? > > > Well, the two methods being floated right now are > > > 1) strong authentication based on some form of strong > > crypto. > > My question concerns *authorization*, not authentication. If a CN > gets a BU from a node claiming to be a router for a prefix (e.g., all > of MIT), how does the CN decide that this is really a legitimate route > entry to install, as opposed to an intruder attempting to hijact MIT's > traffic? Both /128 and /8 are about authentication and authorization. The main difference seems to be the stakes. If I subvert a /128, I only dork one node. If I subvert a /8 it's... more. The question is whether either is more or less acceptible. Is /128 ok, but /64 not? How about /48? I rather doubt that devine artificial boundaries is going to be especially productive. > > Maybe this is a case where the security realities inform the > > protocol design rather than the more usual reverse? > > Indeed. One needs to understand the security requirements prior to > designing the protocol, as some protocol designs may turn out to be > inherently flawed once the security requirements are understood. Considering that routing table update at a distance is a fundamental shift in the current security practices of the internet, I'd say that this is pretty important problem to be considered, and may very well be the lynch pin. Indeed, it's quite possible that if the requirements are significantly different than what is currently being proposed with the varoius return routability test, it's not solvable at all within the current MIP design. It would probably be nice to know that sooner rather than later. Mike From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 6 06: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 ESMTP id GAA20862 for ; Mon, 6 Aug 2001 06:20:02 -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 EAA22335; Mon, 6 Aug 2001 04:20: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 DAA20348; Mon, 6 Aug 2001 03:20:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f76AIqw02665 for mobile-ip-dist; Mon, 6 Aug 2001 03:18:52 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.86.31] (may be forged)) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f76AIiD02658 for ; Mon, 6 Aug 2001 03:18:44 -0700 (PDT) Received: from emirgan (vpn-129-150-4-12.EBay.Sun.COM [129.150.4.12]) by jurassic.eng.sun.com (8.11.4+Sun/8.11.5) with SMTP id f76AIma114996; Mon, 6 Aug 2001 03:18:48 -0700 (PDT) From: "alper" To: , Subject: [mobile-ip] BETH comments and questions Date: Mon, 6 Aug 2001 03:19:00 -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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-mobile-ip@sunroof.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 [my mail server was down. I dont seem to receive these e-mails. following them from the mobile-ip archieve..] Hi Ajoy, I understand that the BETH should be deployed in a domain, therefore neighbor ARs in this domain will be BETH capable. But we cannot claim "all" the neighbor routers will be BETH capable, as the whole Internet is not a single domain, and we don't expect every ARs to support BETH. Therefore, I cannot speculate how often but, MN will attach to BETH-incapable ARs. It's perfectly fine if handoff performance is better when BETH kicks in, and the performance is as good as stock-MIPv6 whenever BETH is not available. But, I think performance of handoff is worse than stock-MIPv6 when MN does a BETH-to-nonBETH handoff. First it has to wait and detect that BETH didn't work. Only after than it can start stock-MIPv6 handoff. I don't know how much delay this introduces as the draft doesn't outline the process in this case. So, how soon can we detect a real-time flow is cut? Also once the MN enters a non-BETH domain, it better "learn" that this is a non-BETH domain, so it doesn't get hit at every handoff in this domain. alper Hello Alper: Sorry for jumping in the middle of discussion. Please find my inline response. regards, ajoy During a real-time communication, if your MN detects that it has attached to a new L2, what does it do? It'd hope that oldAR and newAR are doing BETH and MN would do nothing, as I understand. But, what if the newAR is not BETH capable, or BETH has failed for some reason. The only way to figure this out is to wait, I think. There seems to be no other way, because there's no L3 signaling between MN and newAR. And this wait will effect the handoff time, if newAR is not doing BETH. ajoy: If BETH is deployed in particular access technology, it is assumed that neighboring routers will be BETH capable. Neighboring routers have to understand same protocol to support fast handover. For example, if neighboring routers do not support same protocol, we cannot support context transfer, the MN has to negotiate context. This is true for any protocol in general. If BETH fails due to any reason, MN will detect service disruption because real time traffic flow will stop. MN can use this information as a trigger to acquire new COA. If you do not support BETH in low data rate channel, the service of user will be affected every time MN moves from one AR to other. Which one you will choose ? From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 6 07:13:41 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21331 for ; Mon, 6 Aug 2001 07:13: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 FAA14249; Mon, 6 Aug 2001 05:14: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 EAA05804; Mon, 6 Aug 2001 04:12:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f76BBm702769 for mobile-ip-dist; Mon, 6 Aug 2001 04:11:48 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f76BBiD02762 for ; Mon, 6 Aug 2001 04:11:44 -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 EAA23138 for ; Mon, 6 Aug 2001 04:11:50 -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 EAA28431 for ; Mon, 6 Aug 2001 04:11:48 -0700 (PDT) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f76BBkN19347 for ; Mon, 6 Aug 2001 13:11:47 +0200 (MEST) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id NAA11101; Mon, 6 Aug 2001 13:11:46 +0200 Message-ID: <3B6E7B0D.AF296993@era.ericsson.se> Date: Mon, 06 Aug 2001 13:10:05 +0200 From: Mattias Pettersson Organization: Ericsson Research X-Mailer: Mozilla 4.77 [en] (Win95; 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: <200108060842.f768g7a19627@hygro.adsl.duke.edu> 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 Thomas, Thomas Narten wrote: > > Michael Thomas writes: > > > > How can one prove to a correspondent node that some router foo, is > > > authorized to have all traffic destined to (say) MIT rerouted through > > > it? > > > Well, the two methods being floated right now are > > > 1) strong authentication based on some form of strong > > crypto. > > My question concerns *authorization*, not authentication. If a CN > gets a BU from a node claiming to be a router for a prefix (e.g., all > of MIT), how does the CN decide that this is really a legitimate route > entry to install, as opposed to an intruder attempting to hijact MIT's > traffic? Is there such a big need for sending BUs covering an entire prefix rather than /128? If a MH behind the MR needs to update a CN, there is pretty low probability that another MH behind the MR would be talking to the same CN and thus send a BU to that. So each MH should take care of sending BUs to CNs, and the MR should not aggregate them. So, we don't need to allow more than /128. > Thomas /Mattias From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 6 08:11:25 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21831 for ; Mon, 6 Aug 2001 08:11: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 FAA14526; Mon, 6 Aug 2001 05:11:15 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA14485; Mon, 6 Aug 2001 05:11:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f76C9qt02863 for mobile-ip-dist; Mon, 6 Aug 2001 05:09:52 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f76C9nD02856 for ; Mon, 6 Aug 2001 05:09:49 -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 FAA21162 for ; Mon, 6 Aug 2001 05:09:55 -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 FAA15433 for ; Mon, 6 Aug 2001 05:09:55 -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 f76C87J14909 for ; Mon, 6 Aug 2001 05:08: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 ABS02003; Mon, 6 Aug 2001 05:09:54 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id FAA14685; Mon, 6 Aug 2001 05:09:53 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15214.35089.740171.879641@thomasm-u1.cisco.com> Date: Mon, 6 Aug 2001 05:09:53 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Concerns about draft-mipv6-14 section 4.8 In-Reply-To: <3B6E7B0D.AF296993@era.ericsson.se> References: <200108060842.f768g7a19627@hygro.adsl.duke.edu> <3B6E7B0D.AF296993@era.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 Mattias Pettersson writes: > Hi Thomas, > > Thomas Narten wrote: > > > > Michael Thomas writes: > > > > > > How can one prove to a correspondent node that some router foo, is > > > > authorized to have all traffic destined to (say) MIT rerouted through > > > > it? > > > > > Well, the two methods being floated right now are > > > > > 1) strong authentication based on some form of strong > > > crypto. > > > > My question concerns *authorization*, not authentication. If a CN > > gets a BU from a node claiming to be a router for a prefix (e.g., all > > of MIT), how does the CN decide that this is really a legitimate route > > entry to install, as opposed to an intruder attempting to hijact MIT's > > traffic? > > Is there such a big need for sending BUs covering an entire prefix > rather than /128? If a MH behind the MR needs to update a CN, there is > pretty low probability that another MH behind the MR would be talking to > the same CN and thus send a BU to that. So each MH should take care of > sending BUs to CNs, and the MR should not aggregate them. So, we don't > need to allow more than /128. This depends a whole lot on whether MH behind MR is aware of its mobility. If it's not, then MH clearly won't be sending any BU's at all. There's quite a bit of appeal to not having the MH's realize they are mobile (what for example would happen when an aircraft carrier full of PC's moved it's attachment point?). This is a pretty fundamental question that needs to be answered, and needs to be evaluated in the context of renumbering and security. Mike From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 6 08:49:54 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22378 for ; Mon, 6 Aug 2001 08:49:54 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA29102; Mon, 6 Aug 2001 06:50: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 FAA17244; Mon, 6 Aug 2001 05:50:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f76CnLC02956 for mobile-ip-dist; Mon, 6 Aug 2001 05:49:21 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic-89-b [129.146.89.50]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f76CnID02949 for ; Mon, 6 Aug 2001 05:49:18 -0700 (PDT) Received: from emirgan (vpn-129-150-4-27.EBay.Sun.COM [129.150.4.27]) by jurassic.eng.sun.com (8.11.4+Sun/8.11.5) with SMTP id f76CnNa134546; Mon, 6 Aug 2001 05:49:24 -0700 (PDT) From: "alper" To: , Subject: RE: [mobile-ip] BETH comments and questions Date: Mon, 6 Aug 2001 05:49:35 -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) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Jim, Please see my responses below with prefix "aey >". ---- Hi Alper, >- During a real-time communication, if your MN detects that it has attached >to a >new L2, what does it do? It'd hope that oldAR and newAR are doing BETH and >MN >would do nothing, as I understand. But, what if the newAR is not BETH >capable, >or BETH has failed for some reason. The only way to figure this out is to >wait, >I think. There seems to be no other way, because there's no L3 signalling >between MN and newAR. And this wait will effect the handoff time, if newAR >is >not doing BETH. > As Ajoy pointed out, if the real time packet stream fails, the MN can simply go ahead and establish its CoA. The point of BETH is to eliminate aey > I think the key here is, how soon can the MN detect "real time packet stream failed"? If BETH is not available, and until this detection takes place, MN is not reachable. Only after this is detected, stock-MIPv6 can kick in. And this is even slower than doing stock-MIPv6 as soon as MN attaches to new link. This is my main concern. L3 signalling so the radio link is free for real time traffic. If there is no real time traffic, then the MN can go ahead and get a new CoA. But the issue you bring up about a router not being BETH capable obviously holds for FMIPv6 too. In that case, the MN learns that it can't do FMIPv6 because it doesn't get a reply for RqstPrxyRtAdv, but by that time it could already be on the new AR. Though I dislike adding knobs aey > Therefore by the time MN attaches to new link, it knows FMIPv6 didn't work, and start stock-MIPv6 handoff immediately. In BETH case, MN needs to wait until it detects BETH didn't work. So, FMIPv6, and even stock MIPv6, works faster than BETH in this case. And I think this is not a rare case, as not all the routers will support BETH. where they might not be needed (because they add complexity) perhaps the admission control procedure needs to inform the MN about what handover options it has. Better would be to simply make fast handover a required part of MIPv6, to avoid having the situation where a router doesn't support it (in the long run). aey > I'm not sure if we can expect all routers to support a specific handoff mechanism, but having a L2 capability than can convey the "L3 handoff mechanism" in the link-up trigger could be useful. >- BU/Back are destination options. Therefore they are only processed by the >destinations, MN/CN/HA. If routers want to take a peek on them, they can do >so. >But, designing the protocol based on sniffing packets on the wire makes me >worried. One thing, it's not guaranteed that this packet will go through >this >router, as there can be more than one on the link. Secondly, if one day this >packet is encrypted, or a new flavor of BU/BAck is used, this won't work. > OK. Perhaps an explicit BU to the new AR when the new CoA is totally in place is the right way to go. >We should clarify the use of L2 triggers in FMIPv6. > Yes, while I agree with trying to make it general, if there are abstract L2 triggers, it should be possible to write the draft such that there is no dependence on a specific L2. As it now is, there are implicit assumptions about L3 obtaining handover sequencing information that I think might make it difficult to implement by someone who was not part of the initial design group. aey > Now we have the L2 requirements draft, I think we can re-work the L2 wording in the FMIPv6 draft (Gopal, are you reading this? :) jak From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 6 08:50:26 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22395 for ; Mon, 6 Aug 2001 08:50: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 FAA25254; Mon, 6 Aug 2001 05:51:14 -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 FAA17304; Mon, 6 Aug 2001 05:51:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f76CoHS02974 for mobile-ip-dist; Mon, 6 Aug 2001 05:50:17 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f76CoDD02967 for ; Mon, 6 Aug 2001 05:50: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 FAA23762 for ; Mon, 6 Aug 2001 05:50: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 FAA29377 for ; Mon, 6 Aug 2001 05:50:18 -0700 (PDT) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f76CoDN22373 for ; Mon, 6 Aug 2001 14:50:17 +0200 (MEST) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id OAA13556; Mon, 6 Aug 2001 14:50:13 +0200 Message-ID: <3B6E9220.A51D27BF@era.ericsson.se> Date: Mon, 06 Aug 2001 14:48:32 +0200 From: Mattias Pettersson Organization: Ericsson Research X-Mailer: Mozilla 4.77 [en] (Win95; 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: <200108060842.f768g7a19627@hygro.adsl.duke.edu> <3B6E7B0D.AF296993@era.ericsson.se> <15214.35089.740171.879641@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: > > Mattias Pettersson writes: > > Is there such a big need for sending BUs covering an entire prefix > > rather than /128? If a MH behind the MR needs to update a CN, there is > > pretty low probability that another MH behind the MR would be talking to > > the same CN and thus send a BU to that. So each MH should take care of > > sending BUs to CNs, and the MR should not aggregate them. So, we don't > > need to allow more than /128. > > This depends a whole lot on whether MH behind MR > is aware of its mobility. If it's not, then MH > clearly won't be sending any BU's at all. There's > quite a bit of appeal to not having the MH's > realize they are mobile (what for example would > happen when an aircraft carrier full of PC's > moved it's attachment point?). I can see two quite different paths to go: 1. Allow only the simpliest mobile networks. They have one MR (which is single point of failure) and the MHs behind are in fact only Hs (i.e. not mobile-aware). MR takes care of the mobility and maybe use a bi-directional tunnel between itself and HA. draft-ernst-mobileip-v6-network-0x focuses on this. 2. Make things end-to-end. Let MNs in the mobile network be aware of that the network is mobile. At a higher cost, that is. Hopefully this can also take into consideration multiple MRs, MNs leaving the mobile network, multihoming, etc. The requirements draft doesn't exclude this case. /Mattias > > This is a pretty fundamental question that needs > to be answered, and needs to be evaluated in the > context of renumbering and security. > > Mike From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 6 09:01:55 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22653 for ; Mon, 6 Aug 2001 09:01: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 HAA06041; Mon, 6 Aug 2001 07:02: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 GAA18310; Mon, 6 Aug 2001 06:02:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f76D1Jf03083 for mobile-ip-dist; Mon, 6 Aug 2001 06:01:19 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f76D1FD03076 for ; Mon, 6 Aug 2001 06:01:15 -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 GAA18198 for ; Mon, 6 Aug 2001 06:01:22 -0700 (PDT) Received: from prserv.net (out2.prserv.net [32.97.166.32]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA05379 for ; Mon, 6 Aug 2001 07:01:19 -0600 (MDT) Received: from attglobal.net (slip-32-101-121-154.il.us.prserv.net[32.101.121.154]) by prserv.net (out2) with SMTP id <20010806130119202039p01je>; Mon, 6 Aug 2001 13:01:20 +0000 Message-ID: <3B6E9519.27E3462@attglobal.net> Date: Mon, 06 Aug 2001 08:01:14 -0500 From: Sebastian Thalanany X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com CC: sebastn@attglobal.net Subject: Re: [mobile-ip] BETH comments and questions 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 Alper, To achieve the BETH support for real-time traffic streams, the assumption is that the neighboring ARs are BETH capable. BETH capability is required to be installed via system engineering to support the handoff of real-time traffic streams. In the absence of BETH, the stock MIPv6 procedures are applicable. In the case that BETH was only partially deployed, the impact on the handoff of real-time traffic streams would be less severe than if only the stock MIPv6 procedures were available. In the specific cases, where a handoff occurred from a BETH capable AR to a non-BETH capable AR, the additional latency incurred in the detection and switching to the stock MIPv6 procedures could be used as a trigger for network management to re-engineer the system for BETH deployment. Regards, Sebastian alper wrote: > [my mail server was down. I dont seem to receive these e-mails. following > them from the mobile-ip archieve..] > > Hi Ajoy, > > I understand that the BETH should be deployed in a domain, therefore > neighbor > ARs in this domain will be BETH capable. But we cannot claim "all" the > neighbor > routers will be BETH capable, as the whole Internet is not a single domain, > and > we don't expect every ARs to support BETH. > > Therefore, I cannot speculate how often but, MN will attach to > BETH-incapable > ARs. > > It's perfectly fine if handoff performance is better when BETH kicks in, and > the performance is as good as stock-MIPv6 whenever BETH is not available. > > But, I think performance of handoff is worse than stock-MIPv6 when MN does a > BETH-to-nonBETH handoff. First it has to wait and detect that BETH didn't > work. > Only after than it can start stock-MIPv6 handoff. I don't know how much > delay > this introduces as the draft doesn't outline the process in this case. So, > how > soon can we detect a real-time flow is cut? > > Also once the MN enters a non-BETH domain, it better "learn" that this is a > non-BETH domain, so it doesn't get hit at every handoff in this domain. > > alper > > Hello Alper: > > Sorry for jumping in the middle of discussion. > Please find my inline response. > > regards, > ajoy > > During a real-time communication, if your MN detects that it has attached to > a new L2, what does it do? It'd hope that oldAR and newAR are doing BETH and > MN would do nothing, as I understand. But, what if the newAR is not BETH > capable, or BETH has failed for some reason. The only way to figure this out > is to wait, I think. There seems to be no other way, because there's no L3 > signaling between MN and newAR. And this wait will effect the handoff time, > if newAR is not doing BETH. > > ajoy: If BETH is deployed in particular access technology, it is assumed > that > neighboring routers will be BETH capable. Neighboring routers have to > understand same protocol to support fast handover. For example, if > neighboring routers do not support same protocol, we cannot support context > transfer, the MN has to negotiate context. This is true for any protocol in > general. If BETH fails due to any reason, MN will detect service disruption > because real time traffic flow will stop. MN can use this information as a > trigger to acquire new COA. If you do not support BETH in low data rate > channel, the service of user will be affected every time MN moves from one > AR > to other. Which one you will choose ? From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 6 09:24:25 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22928 for ; Mon, 6 Aug 2001 09:24: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 HAA19869; Mon, 6 Aug 2001 07:25: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 GAA14636; Mon, 6 Aug 2001 06:24:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f76DNZu03194 for mobile-ip-dist; Mon, 6 Aug 2001 06:23:35 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f76DNVD03187 for ; Mon, 6 Aug 2001 06:23: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 GAA02280 for ; Mon, 6 Aug 2001 06:23: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 HAA18844 for ; Mon, 6 Aug 2001 07:23:35 -0600 (MDT) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Mon, 6 Aug 2001 09:23:35 -0400 Message-ID: <8C92E23A3E87FB479988285F9E22BE46054714@ftmail> From: George Tsirtsis To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] BETH comments and questions Date: Mon, 6 Aug 2001 09:23:09 -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 Alper makes a good point. We have a number of different handoff mechanisms by now and the mobile node needs to know what is going on. IP Layer handoffs, like MIPv6 do provide information about the network's capabilities in the Router Advertisement and MIPv4 is using Foreign Agent Adverts to do the same. In the case of BETH where L2 triggers are used instead of IP messages the information about what the network supports could also be part of the L2 triggers. e.g.: a BETH capable network could announce its capability in an L2 trigger to the MN...This way during a handoff the IP layer in the MN will know that it should not do anything since BETH is working...lack of such a trigger would make the MN use traditional MIP mechanisms to handoff. Thoughts? George -----Original Message----- From: Sebastian Thalanany [mailto:sebastn@attglobal.net] Sent: Monday, August 06, 2001 2:01 PM To: mobile-ip@sunroof.eng.sun.com Cc: sebastn@attglobal.net Subject: Re: [mobile-ip] BETH comments and questions Hello Alper, To achieve the BETH support for real-time traffic streams, the assumption is that the neighboring ARs are BETH capable. BETH capability is required to be installed via system engineering to support the handoff of real-time traffic streams. In the absence of BETH, the stock MIPv6 procedures are applicable. In the case that BETH was only partially deployed, the impact on the handoff of real-time traffic streams would be less severe than if only the stock MIPv6 procedures were available. In the specific cases, where a handoff occurred from a BETH capable AR to a non-BETH capable AR, the additional latency incurred in the detection and switching to the stock MIPv6 procedures could be used as a trigger for network management to re-engineer the system for BETH deployment. Regards, Sebastian alper wrote: > [my mail server was down. I dont seem to receive these e-mails. following > them from the mobile-ip archieve..] > > Hi Ajoy, > > I understand that the BETH should be deployed in a domain, therefore > neighbor > ARs in this domain will be BETH capable. But we cannot claim "all" the > neighbor > routers will be BETH capable, as the whole Internet is not a single domain, > and > we don't expect every ARs to support BETH. > > Therefore, I cannot speculate how often but, MN will attach to > BETH-incapable > ARs. > > It's perfectly fine if handoff performance is better when BETH kicks in, and > the performance is as good as stock-MIPv6 whenever BETH is not available. > > But, I think performance of handoff is worse than stock-MIPv6 when MN does a > BETH-to-nonBETH handoff. First it has to wait and detect that BETH didn't > work. > Only after than it can start stock-MIPv6 handoff. I don't know how much > delay > this introduces as the draft doesn't outline the process in this case. So, > how > soon can we detect a real-time flow is cut? > > Also once the MN enters a non-BETH domain, it better "learn" that this is a > non-BETH domain, so it doesn't get hit at every handoff in this domain. > > alper > > Hello Alper: > > Sorry for jumping in the middle of discussion. > Please find my inline response. > > regards, > ajoy > > During a real-time communication, if your MN detects that it has attached to > a new L2, what does it do? It'd hope that oldAR and newAR are doing BETH and > MN would do nothing, as I understand. But, what if the newAR is not BETH > capable, or BETH has failed for some reason. The only way to figure this out > is to wait, I think. There seems to be no other way, because there's no L3 > signaling between MN and newAR. And this wait will effect the handoff time, > if newAR is not doing BETH. > > ajoy: If BETH is deployed in particular access technology, it is assumed > that > neighboring routers will be BETH capable. Neighboring routers have to > understand same protocol to support fast handover. For example, if > neighboring routers do not support same protocol, we cannot support context > transfer, the MN has to negotiate context. This is true for any protocol in > general. If BETH fails due to any reason, MN will detect service disruption > because real time traffic flow will stop. MN can use this information as a > trigger to acquire new COA. If you do not support BETH in low data rate > channel, the service of user will be affected every time MN moves from one > AR > to other. Which one you will choose ? From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 6 11:02:49 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24988 for ; Mon, 6 Aug 2001 11:02:48 -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 IAA13640; Mon, 6 Aug 2001 08:03:33 -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 IAA08380; Mon, 6 Aug 2001 08:03:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f76F1g803416 for mobile-ip-dist; Mon, 6 Aug 2001 08:01:42 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f76F1cD03409 for ; Mon, 6 Aug 2001 08:01:38 -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 IAA16926 for ; Mon, 6 Aug 2001 08:01:43 -0700 (PDT) Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA02923 for ; Mon, 6 Aug 2001 09:01:41 -0600 (MDT) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate3.mot.com (motgate3 2.1) with ESMTP id HAA02748 for ; Mon, 6 Aug 2001 07:54:11 -0700 (MST)] Received: [from m-il06-r3.mot.com (m-il06-r3.mot.com [129.188.137.194]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id IAA11196 for ; Mon, 6 Aug 2001 08:01:41 -0700 (MST)] Received: from [140.101.173.9] by m-il06-r3.mot.com with ESMTP for mobile-ip@sunroof.eng.sun.com; Mon, 6 Aug 2001 10:01:33 -0500 Received: (from root@localhost) by zorglub.crm.mot.com (8.8.8/8.8.8/crm-1.6) id RAA06868 for mobile-ip@sunroof.eng.sun.com.DELIVER; Mon, 6 Aug 2001 17:01:34 +0200 (METDST) Received: from test9.crm.mot.com.crm.mot.com (zfr24-sr2-09.corp.mot.com [140.101.145.9]) by zorglub.crm.mot.com (8.8.8/8.8.8/crm-1.6) with ESMTP id RAA06833 for ; Mon, 6 Aug 2001 17:01:32 +0200 (METDST) To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Concerns about draft-mipv6-14 section 4.8 References: <200108060842.f768g7a19627@hygro.adsl.duke.edu> <3B6E7B0D.AF296993@era.ericsson.se> From: Alexandru Petrescu Date: 06 Aug 2001 17:00:18 +0200 In-Reply-To: <3B6E7B0D.AF296993@era.ericsson.se> 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: 17 Sender: owner-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 Mattias, Mattias Pettersson writes: > Is there such a big need for sending BUs covering an entire prefix > rather than /128? If a MH behind the MR needs to update a CN, there is > pretty low probability that another MH behind the MR would be talking to > the same CN The scenario you present is only one of so many. PC's on the seats in a plane will probably do mostly browsing to various servers. But brake sensors in a train will send data to one fixed surveillance PC at the closest station. This comes down to sending many BU's to the same CN. An MR would be useful. Alex From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 6 11:33:05 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25773 for ; Mon, 6 Aug 2001 11:33: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 IAA28469; Mon, 6 Aug 2001 08:33: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 IAA16126; Mon, 6 Aug 2001 08:31:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f76FUiN03581 for mobile-ip-dist; Mon, 6 Aug 2001 08:30:44 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f76FUfD03574 for ; Mon, 6 Aug 2001 08:30: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 IAA22036 for ; Mon, 6 Aug 2001 08:30:46 -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 JAA05926 for ; Mon, 6 Aug 2001 09:30:46 -0600 (MDT) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f76FUdN23091 for ; Mon, 6 Aug 2001 17:30:39 +0200 (MEST) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id RAA17978; Mon, 6 Aug 2001 17:30:39 +0200 Message-ID: <3B6EB7BA.2A766673@era.ericsson.se> Date: Mon, 06 Aug 2001 17:28:58 +0200 From: Mattias Pettersson Organization: Ericsson Research X-Mailer: Mozilla 4.77 [en] (Win95; 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: <200108060842.f768g7a19627@hygro.adsl.duke.edu> <3B6E7B0D.AF296993@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 Alexandru Petrescu wrote: > > Hi Mattias, > > Mattias Pettersson writes: > > Is there such a big need for sending BUs covering an entire prefix > > rather than /128? If a MH behind the MR needs to update a CN, there is > > pretty low probability that another MH behind the MR would be talking to > > the same CN > > The scenario you present is only one of so many. PC's on the seats in > a plane will probably do mostly browsing to various servers. But > brake sensors in a train will send data to one fixed surveillance PC > at the closest station. This comes down to sending many BU's to the > same CN. An MR would be useful. I don't question an MR would be useful. The question is what functions we put in it. For me, what it boils down to is that I prefer not to have some nodes perform operations on behalf of other nodes. It's needed at times, but hopefully in static configurations (a home agent is rather static). I don't see a mobile network as (always) a static entity, so I would look for other solutions. Also, the trust model for a mobile network with an MR doing registration on behalf of MNs is more complex than one where each MN is out on its own. /Mattias > > Alex From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 6 12:11:17 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26638 for ; Mon, 6 Aug 2001 12:11: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 KAA10278; Mon, 6 Aug 2001 10:11: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 JAA08484; Mon, 6 Aug 2001 09:11:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f76GARV03743 for mobile-ip-dist; Mon, 6 Aug 2001 09:10:27 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f76GAOD03736 for ; Mon, 6 Aug 2001 09:10: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 JAA18506 for ; Mon, 6 Aug 2001 09:10:30 -0700 (PDT) Received: from web3507.mail.yahoo.com (web3507.mail.yahoo.com [216.115.111.74]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id KAA08713 for ; Mon, 6 Aug 2001 10:10:27 -0600 (MDT) Message-ID: <20010806160929.4094.qmail@web3507.mail.yahoo.com> Received: from [217.33.146.67] by web3507.mail.yahoo.com via HTTP; Mon, 06 Aug 2001 09:09:29 PDT Date: Mon, 6 Aug 2001 09:09:29 -0700 (PDT) From: Thierry Ernst Subject: Re: [mobile-ip] Concerns about draft-mipv6-14 section 4.8 To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --- Michael Thomas wrote: > Considering that routing table update at a > distance > is a fundamental shift in the current security > practices of the internet, I'd say that this is > pretty important problem to be considered, and > may > very well be the lynch pin. Indeed, it's quite > possible > that if the requirements are significantly > different than what is > currently being proposed with the varoius return > routability test, it's not solvable at all within > the > current MIP design. It would probably be nice to > know that > sooner rather than later. As far as Mobile IPv6 is concerned toghether with the process of sending BUs to HA and CNs, yes there is an AUTHORIZATION issue as previously debated on this mailing list about one year ago. The authorization problem is exactly the reason why our draft "Prefix Scope Binding Updates" (draft-ernst-mobileip-v6-network-02.txt - sorry that I keep pointing to my drafts but I don't want the people to be confused about which draft I am talking about - there are 2 of them)was not widely accepted, and also the reason why I advocate any MIPv6 extensions about network mobility support to be kept away from the MIPv6 specification. Anyway, t6here is a section in our draft that is tackling with the AUTHORIZATION issue. Our view is that what we need a certificate that says that a router is AUTHORIZED to send a BU for a particular prefix. The section is rather short, but it is here to open the discussion. I would therefore be more than happy to have comments on this; that would avoid everyone to keep repeating and arguying the same things. Having feedback on a draft is the reason to write a draft, If we wanted to keep the discussion for ourselves we wouldn't have written it. Then, all you interested people, please comment on the draft. If there is something wrong, please speak up. Thierry. Motorola Labs and INRIA Rhone-Alpes __________________________________________________ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 6 12:15:48 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26782 for ; Mon, 6 Aug 2001 12:15: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 JAA19687; Mon, 6 Aug 2001 09:16: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 JAA09084; Mon, 6 Aug 2001 09:14:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f76GD9903784 for mobile-ip-dist; Mon, 6 Aug 2001 09:13:09 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f76GD5D03776 for ; Mon, 6 Aug 2001 09:13: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 JAA18983 for ; Mon, 6 Aug 2001 09:13:12 -0700 (PDT) Received: from web3507.mail.yahoo.com (web3507.mail.yahoo.com [216.115.111.74]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id KAA11623 for ; Mon, 6 Aug 2001 10:13:09 -0600 (MDT) Message-ID: <20010806161311.4276.qmail@web3507.mail.yahoo.com> Received: from [217.33.146.67] by web3507.mail.yahoo.com via HTTP; Mon, 06 Aug 2001 09:13:11 PDT Date: Mon, 6 Aug 2001 09:13:11 -0700 (PDT) From: Thierry Ernst Subject: Re: [mobile-ip] Concerns about draft-mipv6-14 section 4.8 To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --- Mattias Pettersson wrote: > I don't question an MR would be useful. The question > is what functions > we put in it. > For me, what it boils down to is that I prefer not > to have some nodes > perform operations on behalf of other nodes. It's > needed at times, but > hopefully in static configurations (a home agent is > rather static). I > don't see a mobile network as (always) a static > entity, so I would look > for other solutions. > > Also, the trust model for a mobile network with an > MR doing registration > on behalf of MNs is more complex than one where each > MN is out on its > own. MN is quite a confusing term to me. I used to speak about MNNs in general, MNN being one of MR - LFN - VMN - LMN. See my requirement draft. The distinction is useful to avoid confusion - I have noticed we don't always speak about the same thing. Then, do you want all MNNs in the network to register a 128-128 binding with the MR's HA ? Sounds odd to me. > Is there such a big need for sending BUs covering an > entire prefix > rather than /128? If a MH behind the MR needs to > update a CN, there is > pretty low probability that another MH behind the MR > would be talking to > the same CN and thus send a BU to that. So each MH > should take care of > sending BUs to CNs, and the MR should not aggregate > them. So, we don't > need to allow more than /128. Yes there is a big need if you want: - the MR's Home Agent to redirect all packets intended to nodes behind the MR - to limit the number of BUs in the network - to keep mobility management relative to MR's mobility away from the nodes behind the MR - other ... Thierry __________________________________________________ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 6 13:13:41 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27797 for ; Mon, 6 Aug 2001 13:13: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 KAA20642; Mon, 6 Aug 2001 10:14:22 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA21944; Mon, 6 Aug 2001 10:10:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f76H9Z904053 for mobile-ip-dist; Mon, 6 Aug 2001 10:09:35 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f76H9VD04046 for ; Mon, 6 Aug 2001 10:09: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 KAA01379 for ; Mon, 6 Aug 2001 10:09:38 -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 LAA17294 for ; Mon, 6 Aug 2001 11:09:40 -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 f76H4bY19816 for ; Mon, 6 Aug 2001 10:04:37 -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 ABT04088; Mon, 6 Aug 2001 10:03:53 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA14741; Mon, 6 Aug 2001 10:03:52 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15214.52728.830605.138701@thomasm-u1.cisco.com> Date: Mon, 6 Aug 2001 10:03:52 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Concerns about draft-mipv6-14 section 4.8 In-Reply-To: <20010806160929.4094.qmail@web3507.mail.yahoo.com> References: <20010806160929.4094.qmail@web3507.mail.yahoo.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 Ok, here's the problem I see. What gives me the right to assert a routing table modification for a prefix larger than I'm authorized to route? The current crop of proposals expect that if I can route back to where the BU came from (either to the MN or HA), that is sufficient check to accept the BU. However, that only guarantees that I can currently protect one address: the source address of the BU. Thus if I am a resident on x/8, but am only authorized for x.y.z/24, I better not be able to send a BU for x/8. With the current return routability proposals, I don't believe this is possible. Nor does having a home agent *necessarily* help: the home agent may be in collusion with the MN and not trustable (think of some script kiddie with their home linux box acting as a home agent with their hacked up mobile router). As far as I can tell, the only thing that knows about whether the scope is too broad is some router, potentially serveral hops upstream, of the home agent. This is a problem. I'll go on record here as voicing some scalability concerns with the prospect of large server banks with potentially large binding caches. These are essentially unaggregated host routes across the Internet with is sort of unsettling. This is a general concern with regular BU's, I'll admit, but it sort of points out that the CN is not necessarily the best place to send a BU from a scaling or messaging standpoint. Indeed, it seems that the optimal place to send a BU is with the joining router in the path between the HA and MN's current CoA. Mike Thierry Ernst writes: > As far as Mobile IPv6 is concerned toghether with the > process of sending BUs to HA and CNs, yes there is an > AUTHORIZATION issue as previously debated on this > mailing list about one year ago. The authorization > problem is exactly the reason why our draft "Prefix > Scope Binding Updates" > (draft-ernst-mobileip-v6-network-02.txt - sorry that I > keep pointing to my drafts but I don't want the people > to be confused about which draft I am talking about - > there are 2 of them)was not widely accepted, and also > the reason why I advocate any MIPv6 extensions about > network mobility support to be kept away from the > MIPv6 specification. > > Anyway, t6here is a section in our draft that is > tackling with the AUTHORIZATION issue. Our view is > that what we need a certificate that says that a > router is AUTHORIZED to send a BU for a particular > prefix. The section is rather short, but it is here to > open the discussion. I would therefore be more than > happy to have comments on this; that would avoid > everyone to keep repeating and arguying the same > things. Having feedback on a draft is the reason to > write a draft, If we wanted to keep the discussion for > ourselves we wouldn't have written it. Then, all you > interested people, please comment on the draft. If > there is something wrong, please speak up. > > > Thierry. > Motorola Labs and INRIA Rhone-Alpes > > > > __________________________________________________ > Do You Yahoo!? > Make international calls for as low as $.04/minute with Yahoo! Messenger > http://phonecard.yahoo.com/ From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 6 14:20:42 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28953 for ; Mon, 6 Aug 2001 14:20: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 LAA26567; Mon, 6 Aug 2001 11:21: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 LAA09371; Mon, 6 Aug 2001 11:19:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f76IHvC04245 for mobile-ip-dist; Mon, 6 Aug 2001 11:17:57 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f76IHrD04238 for ; Mon, 6 Aug 2001 11:17:53 -0700 (PDT) Received: from heliopolis.Eng.Sun.COM (euroapp.Holland.Sun.COM [129.159.197.58]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA25371; Mon, 6 Aug 2001 11:17:43 -0700 (PDT) From: James Kempf Message-Id: <200108061817.LAA25371@heliopolis.eng.sun.com> Date: Mon, 6 Aug 2001 19:16:21 +0-100 To: "alper" , , Subject: RE: [mobile-ip] BETH comments and questions 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 Alper, The AR can also send a RtAdv to the MN, rather than the MN waiting. This would probably be quicker. jak > >Hi Jim, > >Please see my responses below with prefix "aey >". > >---- > >Hi Alper, > > >>- During a real-time communication, if your MN detects that it has attached >>to a >>new L2, what does it do? It'd hope that oldAR and newAR are doing BETH and >>MN >>would do nothing, as I understand. But, what if the newAR is not BETH >>capable, >>or BETH has failed for some reason. The only way to figure this out is to >>wait, >>I think. There seems to be no other way, because there's no L3 signalling >>between MN and newAR. And this wait will effect the handoff time, if newAR >>is >>not doing BETH. >> > >As Ajoy pointed out, if the real time packet stream fails, the MN can >simply go ahead and establish its CoA. The point of BETH is to eliminate > >aey > I think the key here is, how soon can the MN detect "real time >packet stream failed"? If BETH is not available, and until this detection >takes place, MN is not reachable. Only after this is detected, stock-MIPv6 >can kick in. And this is even slower than doing stock-MIPv6 as soon as MN >attaches to new link. This is my main concern. > > >L3 signalling so the radio link is free for real time traffic. If >there is no real time traffic, then the MN can go ahead and get a new >CoA. > >But the issue you bring up about a router not being BETH capable obviously >holds for FMIPv6 too. In that case, the MN learns that it can't do >FMIPv6 because it doesn't get a reply for RqstPrxyRtAdv, but by that >time it could already be on the new AR. Though I dislike adding knobs > >aey > Therefore by the time MN attaches to new link, it knows FMIPv6 didn't >work, and start stock-MIPv6 handoff immediately. In BETH case, MN needs to >wait until it detects BETH didn't work. So, FMIPv6, and even stock MIPv6, >works >faster than BETH in this case. And I think this is not a rare case, as not >all >the routers will support BETH. > > > >where they might not be needed (because they add complexity) perhaps >the admission control procedure needs to inform the MN about what >handover options it has. Better would be to simply make fast handover >a required part of MIPv6, to avoid having the situation where a >router doesn't support it (in the long run). > > >aey > I'm not sure if we can expect all routers to support a specific >handoff mechanism, but having a L2 capability than can convey the >"L3 handoff mechanism" in the link-up trigger could be useful. > >>- BU/Back are destination options. Therefore they are only processed by the >>destinations, MN/CN/HA. If routers want to take a peek on them, they can do >>so. >>But, designing the protocol based on sniffing packets on the wire makes me >>worried. One thing, it's not guaranteed that this packet will go through >>this >>router, as there can be more than one on the link. Secondly, if one day >this >>packet is encrypted, or a new flavor of BU/BAck is used, this won't work. >> > >OK. Perhaps an explicit BU to the new AR when the new CoA is totally in >place is the right way to go. > > >>We should clarify the use of L2 triggers in FMIPv6. >> > >Yes, while I agree with trying to make it general, if there are abstract >L2 triggers, it should be possible to write the draft such that there >is no dependence on a specific L2. As it now is, there are implicit >assumptions about L3 obtaining handover sequencing information that >I think might make it difficult to implement by someone who was >not part of the initial design group. > >aey > Now we have the L2 requirements draft, I think we can re-work >the L2 wording in the FMIPv6 draft (Gopal, are you reading this? :) > > jak > > From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 6 14:25:07 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29076 for ; Mon, 6 Aug 2001 14:25:06 -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 LAA29247; Mon, 6 Aug 2001 11:25: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 LAA10148; Mon, 6 Aug 2001 11:22:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f76ILw304282 for mobile-ip-dist; Mon, 6 Aug 2001 11:21: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+Sun/8.11.5) with ESMTP id f76ILsD04275 for ; Mon, 6 Aug 2001 11:21:54 -0700 (PDT) Received: from heliopolis.Eng.Sun.COM (euroapp.Holland.Sun.COM [129.159.197.58]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA25565; Mon, 6 Aug 2001 11:21:47 -0700 (PDT) From: James Kempf Message-Id: <200108061821.LAA25565@heliopolis.eng.sun.com> Date: Mon, 6 Aug 2001 19:20:23 +0-100 To: , "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] BETH comments and questions 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 George, I think it would probably be better to have the network tell the MN during admission rather than on each handover. More information == more radio bandwidth to transmit it, regardless if its at L2 or L3. When the MN falls off the edge of a trust domain and has to redo admission, then it probably is facing a lengthy transaction anyway so there is no harm in delaying it do obtain a CoA. jak >I think Alper makes a good point. We have a number of different handoff >mechanisms by now and the mobile node needs to know what is going on. IP >Layer handoffs, like MIPv6 do provide information about the network's >capabilities in the Router Advertisement and MIPv4 is using Foreign Agent >Adverts to do the same. > >In the case of BETH where L2 triggers are used instead of IP messages the >information about what the network supports could also be part of the L2 >triggers. e.g.: a BETH capable network could announce its capability in an >L2 trigger to the MN...This way during a handoff the IP layer in the MN will >know that it should not do anything since BETH is working...lack of such a >trigger would make the MN use traditional MIP mechanisms to handoff. > >Thoughts? > >George > >-----Original Message----- >From: Sebastian Thalanany [mailto:sebastn@attglobal.net] >Sent: Monday, August 06, 2001 2:01 PM >To: mobile-ip@sunroof.eng.sun.com >Cc: sebastn@attglobal.net >Subject: Re: [mobile-ip] BETH comments and questions > > >Hello Alper, > To achieve the BETH support for real-time traffic >streams, >the assumption is that the neighboring ARs are BETH capable. BETH capability >is >required to be installed via system engineering to support the handoff of >real-time traffic streams. > In the absence of BETH, the stock MIPv6 procedures are >applicable. In the case that BETH was only partially deployed, the impact on >the >handoff of real-time traffic streams would be less severe than if only the >stock >MIPv6 procedures were available. In the specific cases, where a handoff >occurred >from a BETH capable AR to a non-BETH capable AR, the additional latency >incurred >in the detection and switching to the stock MIPv6 procedures could be used >as a >trigger for network management to re-engineer the system for BETH >deployment. > >Regards, > Sebastian > >alper wrote: > >> [my mail server was down. I dont seem to receive these e-mails. following >> them from the mobile-ip archieve..] >> >> Hi Ajoy, >> >> I understand that the BETH should be deployed in a domain, therefore >> neighbor >> ARs in this domain will be BETH capable. But we cannot claim "all" the >> neighbor >> routers will be BETH capable, as the whole Internet is not a single >domain, >> and >> we don't expect every ARs to support BETH. >> >> Therefore, I cannot speculate how often but, MN will attach to >> BETH-incapable >> ARs. >> >> It's perfectly fine if handoff performance is better when BETH kicks in, >and >> the performance is as good as stock-MIPv6 whenever BETH is not available. >> >> But, I think performance of handoff is worse than stock-MIPv6 when MN does >a >> BETH-to-nonBETH handoff. First it has to wait and detect that BETH didn't >> work. >> Only after than it can start stock-MIPv6 handoff. I don't know how much >> delay >> this introduces as the draft doesn't outline the process in this case. So, >> how >> soon can we detect a real-time flow is cut? >> >> Also once the MN enters a non-BETH domain, it better "learn" that this is >a >> non-BETH domain, so it doesn't get hit at every handoff in this domain. >> >> alper >> >> Hello Alper: >> >> Sorry for jumping in the middle of discussion. >> Please find my inline response. >> >> regards, >> ajoy >> >> During a real-time communication, if your MN detects that it has attached >to >> a new L2, what does it do? It'd hope that oldAR and newAR are doing BETH >and >> MN would do nothing, as I understand. But, what if the newAR is not BETH >> capable, or BETH has failed for some reason. The only way to figure this >out >> is to wait, I think. There seems to be no other way, because there's no L3 >> signaling between MN and newAR. And this wait will effect the handoff >time, >> if newAR is not doing BETH. >> >> ajoy: If BETH is deployed in particular access technology, it is assumed >> that >> neighboring routers will be BETH capable. Neighboring routers have to >> understand same protocol to support fast handover. For example, if >> neighboring routers do not support same protocol, we cannot support >context >> transfer, the MN has to negotiate context. This is true for any protocol >in >> general. If BETH fails due to any reason, MN will detect service >disruption >> because real time traffic flow will stop. MN can use this information as a >> trigger to acquire new COA. If you do not support BETH in low data rate >> channel, the service of user will be affected every time MN moves from one >> AR >> to other. Which one you will choose ? From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 6 15:42:10 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00242 for ; Mon, 6 Aug 2001 15:42:09 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA22208; Mon, 6 Aug 2001 13:42: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 MAA13709; Mon, 6 Aug 2001 12:42:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f76JaFO04557 for mobile-ip-dist; Mon, 6 Aug 2001 12:36:15 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f76JaBD04550 for ; Mon, 6 Aug 2001 12:36: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 MAA04937 for ; Mon, 6 Aug 2001 12:36:14 -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 MAA17274 for ; Mon, 6 Aug 2001 12:36:14 -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 f76JZi926534 for ; Mon, 6 Aug 2001 15:35:50 -0400 (EDT) Received: from zrchb200.us.nortel.com by smtprch1.nortel.com; Mon, 6 Aug 2001 14:35:53 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 6 Aug 2001 14:35:30 -0500 Message-ID: <85AA7486A2C1D411BCA20000F8073E430308A38B@crchy271.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Concerns about draft-mipv6-14 section 4.8 Date: Mon, 6 Aug 2001 14:35:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C11EAE.F1FB3700" Sender: owner-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_01C11EAE.F1FB3700 Content-Type: text/plain; charset="iso-8859-1" Some very good points. -----Original Message----- From: Michael Thomas [mailto:mat@cisco.com] Sent: Monday, August 06, 2001 12:04 PM To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Concerns about draft-mipv6-14 section 4.8 Ok, here's the problem I see. What gives me the right to assert a routing table modification for a prefix larger than I'm authorized to route? The current crop of proposals expect that if I can route back to where the BU came from (either to the MN or HA), that is sufficient check to accept the BU. However, that only guarantees that I can currently protect one address: the source address of the BU. Thus if I am a resident on x/8, but am only authorized for x.y.z/24, I better not be able to send a BU for x/8. With the current return routability proposals, I don't believe this is possible. Nor does having a home agent *necessarily* help: the home agent may be in collusion with the MN and not trustable (think of some script kiddie with their home linux box acting as a home agent with their hacked up mobile router). As far as I can tell, the only thing that knows about whether the scope is too broad is some router, potentially serveral hops upstream, of the home agent. This is a problem. I'll go on record here as voicing some scalability concerns with the prospect of large server banks with potentially large binding caches. These are essentially unaggregated host routes across the Internet with is sort of unsettling. This is a general concern with regular BU's, I'll admit, but it sort of points out that the CN is not necessarily the best place to send a BU from a scaling or messaging standpoint. Indeed, it seems that the optimal place to send a BU is with the joining router in the path between the HA and MN's current CoA. Mike Thierry Ernst writes: > As far as Mobile IPv6 is concerned toghether with the > process of sending BUs to HA and CNs, yes there is an > AUTHORIZATION issue as previously debated on this > mailing list about one year ago. The authorization > problem is exactly the reason why our draft "Prefix > Scope Binding Updates" > (draft-ernst-mobileip-v6-network-02.txt - sorry that I > keep pointing to my drafts but I don't want the people > to be confused about which draft I am talking about - > there are 2 of them)was not widely accepted, and also > the reason why I advocate any MIPv6 extensions about > network mobility support to be kept away from the > MIPv6 specification. > > Anyway, t6here is a section in our draft that is > tackling with the AUTHORIZATION issue. Our view is > that what we need a certificate that says that a > router is AUTHORIZED to send a BU for a particular > prefix. The section is rather short, but it is here to > open the discussion. I would therefore be more than > happy to have comments on this; that would avoid > everyone to keep repeating and arguying the same > things. Having feedback on a draft is the reason to > write a draft, If we wanted to keep the discussion for > ourselves we wouldn't have written it. Then, all you > interested people, please comment on the draft. If > there is something wrong, please speak up. > > > Thierry. > Motorola Labs and INRIA Rhone-Alpes > > > > __________________________________________________ > Do You Yahoo!? > Make international calls for as low as $.04/minute with Yahoo! Messenger > http://phonecard.yahoo.com/ ------_=_NextPart_001_01C11EAE.F1FB3700 Content-Type: text/html; charset="iso-8859-1" RE: [mobile-ip] Concerns about draft-mipv6-14 section 4.8

Some very good points.

-----Original Message-----
From: Michael Thomas [mailto:mat@cisco.com]
Sent: Monday, August 06, 2001 12:04 PM
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Concerns about draft-mipv6-14 section 4.8


Ok, here's the problem I see. What gives me the
right to assert a routing table modification for a
prefix larger than I'm authorized to route? The
current crop of proposals expect that if I can
route back to where the BU came from (either to
the MN or HA), that is sufficient check to accept
the BU. However, that only guarantees that I can
currently protect one address: the source address
of the BU. Thus if I am a resident on x/8, but am
only authorized for x.y.z/24, I better not be able
to send a BU for x/8. With the current return
routability proposals, I don't believe this is
possible. Nor does having a home agent
*necessarily* help: the home agent may be in
collusion with the MN and not trustable (think
of some script kiddie with their home linux box
acting as a home agent with their hacked up
mobile router).

As far as I can tell, the only thing that
knows about whether the scope is too broad
is some router, potentially serveral hops
upstream, of the home agent. This is a problem.

I'll go on record here as voicing some scalability
concerns with the prospect of large server banks
with potentially large binding caches. These are
essentially unaggregated host routes across the
Internet with is sort of unsettling. This is a
general concern with regular BU's, I'll admit, but
it sort of points out that the CN is not
necessarily the best place to send a BU from a
scaling or messaging standpoint. Indeed, it seems
that the optimal place to send a BU is with the
joining router in the path between the HA and MN's
current CoA.

            Mike


Thierry Ernst writes:
 > As far as Mobile IPv6 is concerned toghether with the
 > process of sending BUs to HA and CNs, yes there is an
 > AUTHORIZATION issue as previously debated on this
 > mailing list about one year ago. The authorization
 > problem is exactly the reason why our draft "Prefix
 > Scope Binding Updates"
 > (draft-ernst-mobileip-v6-network-02.txt - sorry that I
 > keep pointing to my drafts but I don't want the people
 > to be confused about which draft I am talking about -
 > there are 2 of them)was not widely accepted, and also
 > the reason why I advocate any MIPv6 extensions about
 > network mobility support to be kept away from the
 > MIPv6 specification.
 >
 > Anyway, t6here is a section in our draft that is
 > tackling with the AUTHORIZATION issue.  Our view is
 > that what we need a certificate that says that a
 > router is AUTHORIZED to send a BU for a particular
 > prefix. The section is rather short, but it is here to
 > open the discussion. I would therefore be more than
 > happy to have comments on this; that would avoid
 > everyone to keep repeating and arguying the same
 > things.  Having feedback on a draft is the reason to
 > write a draft, If we wanted to keep the discussion for
 > ourselves we wouldn't have written it.  Then, all you
 > interested people, please comment on the draft. If
 > there is something wrong, please speak up.
 >
 >
 > Thierry.
 > Motorola Labs and INRIA Rhone-Alpes
 >
 >
 >
 > __________________________________________________
 > Do You Yahoo!?
 > Make international calls for as low as $.04/minute with Yahoo! Messenger
 > http://phonecard.yahoo.com/

------_=_NextPart_001_01C11EAE.F1FB3700-- From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 6 16:17:16 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00798 for ; Mon, 6 Aug 2001 16:17: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 OAA21361; Mon, 6 Aug 2001 14:17: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 NAA03876; Mon, 6 Aug 2001 13:17:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f76KFNC04797 for mobile-ip-dist; Mon, 6 Aug 2001 13:15:23 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f76KFJD04790 for ; Mon, 6 Aug 2001 13:15:19 -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 NAA24760 for ; Mon, 6 Aug 2001 13:15:25 -0700 (PDT) Received: from ertpg15e1.nortelnetworks.com ([47.234.0.36]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA18812 for ; Mon, 6 Aug 2001 14:14:52 -0600 (MDT) Received: from smtprch2.nortel.com (erchg0k [47.113.64.104]) by ertpg15e1.nortelnetworks.com (8.11.0/8.11.0) with ESMTP id f76KEk409447 for ; Mon, 6 Aug 2001 16:14:49 -0400 (EDT) Received: from zrchb200.us.nortel.com by smtprch2.nortel.com; Mon, 6 Aug 2001 15:07:52 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 6 Aug 2001 15:13:55 -0500 Message-ID: <85AA7486A2C1D411BCA20000F8073E430308A42B@crchy271.us.nortel.com> From: "Glenn Morrow" To: Alper Yegin , 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: Mon, 6 Aug 2001 15:13:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C11EB4.3BA8A860" 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_01C11EB4.3BA8A860 Content-Type: text/plain; charset="iso-8859-1" Alper, I thought your argument was that it was too complicated to do the bundling for several reasons (PMTU, etc.). My counter-argument was that there are many things that one could position as complex and I named a few indicating that one might withdraw support for these functions using the same reasoning. Specially let us consider the PMTU issue. If you consider this PMTU issue to be that complex, then I deduce that you consider any other functionality such as: ESP, AH, Tunneling etc.. that has to deal with a similar situation, as complex. Another point of misunderstand seems to be that you believe I was saying that the BU should wait until there is another packet to send to that address before sending the BU. What I was saying is that there are many implementation choices where it would be quite useful: For instance, it would be efficient to bundle a binding update with the first application, reservation or transport datagram destined to a specific destination. Also, if a host did implement some sort of egress queue and packets to destinations were on it when a mobility event occured, perhaps the queue should be processed in a smart fashion such that the BUs are bundled. I agree that not all hosts will be/are this complex. I believe you should see now that depending on the particular case of implementation, the complexity is varied. I hope you see that the first case is not that complex at all. Clearly the protocol documention should not have to discuss such implementation realms but perhaps the documentation should have some verbage about what processing is mandatory and what is optional. For instance there might be a statement somewhere that says if a CN supports the BU then it MUST also support the de-bundling of it. Thanks, Glenn -----Original Message----- From: Alper Yegin [mailto:Alper.Yegin@eng.sun.com] Sent: Thursday, August 02, 2001 2:27 PM To: Morrow, Glenn [RICH2:C330:EXCH]; 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 Hi Glenn, > Ya know alper, route optimization, in general, certainly complicates things. > In fact mobility complicates things. Perhaps we just shouldn't do any of > it. This is all just too complicated. Let's just keep building stagnated > stupid routers and hosts - not to mention access specific single point of > failure anchored systems. Of course not :) You seem to be picking on my "implementation complexity" point. By the way, I'm talking about piggybacking binding messages, not talking about route optimization. Implementation complexity by itself is not the only issue. The other points I have raised was the performance hit due to handling "binding message should wait until we have a packet to send to the same destination, or a timer goes off"... It's hard to say which one is more important: saving bandwidth or processing power. And the PMTU issue... You haven't addressed my last two issues.. All I'm saying is that there are also downsides to piggybacking. It's not all that great. alper > > My point is that it isn't that complicated. > > -----Original Message----- > From: Alper Yegin [mailto:Alper.Yegin@eng.sun.com] > Sent: Tuesday, July 31, 2001 6:38 PM > 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 > > > 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 > alper ------_=_NextPart_001_01C11EB4.3BA8A860 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

Alper,

I thought your argument was that it was too = complicated to do the bundling for several reasons (PMTU, etc.). My = counter-argument was that there are many things that one could position = as complex and I named a few indicating that one might withdraw support = for these functions using the same reasoning.

Specially let us consider the PMTU issue. If you = consider this PMTU issue to be that complex, then I deduce that you = consider any other functionality such as: ESP, AH, Tunneling etc.. that = has to deal with a similar situation, as complex.

Another point of misunderstand seems to be that you = believe I was saying that the BU should wait until there is another = packet to send to that address before sending the BU.

What I was saying is that there are many = implementation choices where it would be quite useful:

For instance, it would be efficient to bundle a = binding update with the first application, reservation or transport = datagram destined to a specific destination.

Also, if a host did implement some sort of egress = queue and packets to destinations were on it when a mobility event = occured, perhaps the queue should be processed in a smart fashion such = that the BUs are bundled. I agree that not all hosts will be/are this = complex.

I believe you should see now that depending on the = particular case of implementation, the complexity is varied. I hope you = see that the first case is not that complex at all.

Clearly the protocol documention should not have to = discuss such implementation realms but perhaps the documentation should = have some verbage about what processing is mandatory and what is = optional. For instance there might be a statement somewhere that says = if a CN supports the BU then it MUST also support the de-bundling of = it.

Thanks,

Glenn


-----Original Message-----
From: Alper Yegin [mailto:Alper.Yegin@eng.sun.com]
Sent: Thursday, August 02, 2001 2:27 PM
To: Morrow, Glenn [RICH2:C330:EXCH]; = 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



Hi Glenn,

> Ya know alper, route optimization, in general, = certainly complicates things.
> In fact mobility  complicates things. = Perhaps we just shouldn't do any of
> it. This is all just too complicated. Let's = just keep building stagnated
> stupid routers and hosts - not to mention = access specific single point of
> failure anchored systems.

Of course not :) You seem to be picking on my = "implementation complexity" point.
By the way, I'm talking about piggybacking binding = messages, not talking about
route optimization.

Implementation complexity by itself is not the only = issue. The other points I
have raised was the performance hit due to = handling  "binding message should
wait until we have a packet to send to the same = destination, or a timer goes
off"... It's hard to say which one is more = important: saving bandwidth or
processing power.

And the PMTU issue...

You haven't addressed my last two issues..

All I'm saying is that there are also downsides to = piggybacking. It's not all
that great.


alper




>
> My point is that it isn't that complicated. =
>
> -----Original Message-----
> From: Alper Yegin [mailto:Alper.Yegin@eng.sun.com]
> Sent: Tuesday, July 31, 2001 6:38 PM
> 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
>
>
> 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
>

alper

------_=_NextPart_001_01C11EB4.3BA8A860-- From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 6 16: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 ESMTP id QAA00878 for ; Mon, 6 Aug 2001 16:18: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 NAA20917; Mon, 6 Aug 2001 13:19: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 NAA04179; Mon, 6 Aug 2001 13:19:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f76KIFm04821 for mobile-ip-dist; Mon, 6 Aug 2001 13:18:15 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f76KIBD04812 for ; Mon, 6 Aug 2001 13:18: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 NAA12861 for ; Mon, 6 Aug 2001 13:18:06 -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 OAA21478 for ; Mon, 6 Aug 2001 14:18:04 -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 f76KHd903004 for ; Mon, 6 Aug 2001 16:17:39 -0400 (EDT) Received: from zrchb200.us.nortel.com by smtprch1.nortel.com; Mon, 6 Aug 2001 15:18:02 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 6 Aug 2001 15:17:39 -0500 Message-ID: <85AA7486A2C1D411BCA20000F8073E430308A43D@crchy271.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Concerns about draft-mipv6-14 section 4.8 Date: Mon, 6 Aug 2001 15:17:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C11EB4.D5D92950" Sender: owner-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_01C11EB4.D5D92950 Content-Type: text/plain; charset="iso-8859-1" I don't really see these issues and points as solely being related to mobile networks, however. -----Original Message----- From: Michael Thomas [mailto:mat@cisco.com] Sent: Monday, August 06, 2001 12:04 PM To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Concerns about draft-mipv6-14 section 4.8 Ok, here's the problem I see. What gives me the right to assert a routing table modification for a prefix larger than I'm authorized to route? The current crop of proposals expect that if I can route back to where the BU came from (either to the MN or HA), that is sufficient check to accept the BU. However, that only guarantees that I can currently protect one address: the source address of the BU. Thus if I am a resident on x/8, but am only authorized for x.y.z/24, I better not be able to send a BU for x/8. With the current return routability proposals, I don't believe this is possible. Nor does having a home agent *necessarily* help: the home agent may be in collusion with the MN and not trustable (think of some script kiddie with their home linux box acting as a home agent with their hacked up mobile router). As far as I can tell, the only thing that knows about whether the scope is too broad is some router, potentially serveral hops upstream, of the home agent. This is a problem. I'll go on record here as voicing some scalability concerns with the prospect of large server banks with potentially large binding caches. These are essentially unaggregated host routes across the Internet with is sort of unsettling. This is a general concern with regular BU's, I'll admit, but it sort of points out that the CN is not necessarily the best place to send a BU from a scaling or messaging standpoint. Indeed, it seems that the optimal place to send a BU is with the joining router in the path between the HA and MN's current CoA. Mike Thierry Ernst writes: > As far as Mobile IPv6 is concerned toghether with the > process of sending BUs to HA and CNs, yes there is an > AUTHORIZATION issue as previously debated on this > mailing list about one year ago. The authorization > problem is exactly the reason why our draft "Prefix > Scope Binding Updates" > (draft-ernst-mobileip-v6-network-02.txt - sorry that I > keep pointing to my drafts but I don't want the people > to be confused about which draft I am talking about - > there are 2 of them)was not widely accepted, and also > the reason why I advocate any MIPv6 extensions about > network mobility support to be kept away from the > MIPv6 specification. > > Anyway, t6here is a section in our draft that is > tackling with the AUTHORIZATION issue. Our view is > that what we need a certificate that says that a > router is AUTHORIZED to send a BU for a particular > prefix. The section is rather short, but it is here to > open the discussion. I would therefore be more than > happy to have comments on this; that would avoid > everyone to keep repeating and arguying the same > things. Having feedback on a draft is the reason to > write a draft, If we wanted to keep the discussion for > ourselves we wouldn't have written it. Then, all you > interested people, please comment on the draft. If > there is something wrong, please speak up. > > > Thierry. > Motorola Labs and INRIA Rhone-Alpes > > > > __________________________________________________ > Do You Yahoo!? > Make international calls for as low as $.04/minute with Yahoo! Messenger > http://phonecard.yahoo.com/ ------_=_NextPart_001_01C11EB4.D5D92950 Content-Type: text/html; charset="iso-8859-1" RE: [mobile-ip] Concerns about draft-mipv6-14 section 4.8

I don't really see these issues and points as solely being related to mobile networks, however.  

-----Original Message-----
From: Michael Thomas [mailto:mat@cisco.com]
Sent: Monday, August 06, 2001 12:04 PM
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Concerns about draft-mipv6-14 section 4.8


Ok, here's the problem I see. What gives me the
right to assert a routing table modification for a
prefix larger than I'm authorized to route? The
current crop of proposals expect that if I can
route back to where the BU came from (either to
the MN or HA), that is sufficient check to accept
the BU. However, that only guarantees that I can
currently protect one address: the source address
of the BU. Thus if I am a resident on x/8, but am
only authorized for x.y.z/24, I better not be able
to send a BU for x/8. With the current return
routability proposals, I don't believe this is
possible. Nor does having a home agent
*necessarily* help: the home agent may be in
collusion with the MN and not trustable (think
of some script kiddie with their home linux box
acting as a home agent with their hacked up
mobile router).

As far as I can tell, the only thing that
knows about whether the scope is too broad
is some router, potentially serveral hops
upstream, of the home agent. This is a problem.

I'll go on record here as voicing some scalability
concerns with the prospect of large server banks
with potentially large binding caches. These are
essentially unaggregated host routes across the
Internet with is sort of unsettling. This is a
general concern with regular BU's, I'll admit, but
it sort of points out that the CN is not
necessarily the best place to send a BU from a
scaling or messaging standpoint. Indeed, it seems
that the optimal place to send a BU is with the
joining router in the path between the HA and MN's
current CoA.

            Mike


Thierry Ernst writes:
 > As far as Mobile IPv6 is concerned toghether with the
 > process of sending BUs to HA and CNs, yes there is an
 > AUTHORIZATION issue as previously debated on this
 > mailing list about one year ago. The authorization
 > problem is exactly the reason why our draft "Prefix
 > Scope Binding Updates"
 > (draft-ernst-mobileip-v6-network-02.txt - sorry that I
 > keep pointing to my drafts but I don't want the people
 > to be confused about which draft I am talking about -
 > there are 2 of them)was not widely accepted, and also
 > the reason why I advocate any MIPv6 extensions about
 > network mobility support to be kept away from the
 > MIPv6 specification.
 >
 > Anyway, t6here is a section in our draft that is
 > tackling with the AUTHORIZATION issue.  Our view is
 > that what we need a certificate that says that a
 > router is AUTHORIZED to send a BU for a particular
 > prefix. The section is rather short, but it is here to
 > open the discussion. I would therefore be more than
 > happy to have comments on this; that would avoid
 > everyone to keep repeating and arguying the same
 > things.  Having feedback on a draft is the reason to
 > write a draft, If we wanted to keep the discussion for
 > ourselves we wouldn't have written it.  Then, all you
 > interested people, please comment on the draft. If
 > there is something wrong, please speak up.
 >
 >
 > Thierry.
 > Motorola Labs and INRIA Rhone-Alpes
 >
 >
 >
 > __________________________________________________
 > Do You Yahoo!?
 > Make international calls for as low as $.04/minute with Yahoo! Messenger
 > http://phonecard.yahoo.com/

------_=_NextPart_001_01C11EB4.D5D92950-- From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 6 16:43:03 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01404 for ; Mon, 6 Aug 2001 16:43: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 NAA02491; Mon, 6 Aug 2001 13:43: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 NAA09311; Mon, 6 Aug 2001 13:43:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f76KgR505051 for mobile-ip-dist; Mon, 6 Aug 2001 13:42:27 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f76KgND05044 for ; Mon, 6 Aug 2001 13:42:23 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA25739 for ; Mon, 6 Aug 2001 13:42:29 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA29218 for ; Mon, 6 Aug 2001 14:42:30 -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 f76KgP827608; Mon, 6 Aug 2001 22:42:25 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id WAA07926; Mon, 6 Aug 2001 22:42:25 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id f76KgOu66251; Mon, 6 Aug 2001 22:42:24 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200108062042.f76KgOu66251@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com cc: Jari.Arkko@lmf.ericsson.se, 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: Your message of Tue, 31 Jul 2001 16:38:25 PDT. <200107312338.f6VNcKS630426@jurassic.eng.sun.com> Date: Mon, 06 Aug 2001 22:42:24 +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'm afraid other than killing birds, piggybacking has some other issues associated as well :) => I support Alper: pigybacking is a bad idea IMHO. Francis.Dupont@enst-bretagne.fr PS; about selectors, the cleanest solution is to use a new (i.e. to be allocated by IANA) payload type, aka final next header value. Expensive (8 bit space) but nobody should be able to find a technical objection. PPS: I'd like to be able to use IKE, KINK, AAA, ... if I want: there is a difference between "cannot use" and "should not rely on". From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 6 16:58:14 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01630 for ; Mon, 6 Aug 2001 16:58: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 NAA09427; Mon, 6 Aug 2001 13:59:05 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA22626; Mon, 6 Aug 2001 13:58:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f76KvYx05271 for mobile-ip-dist; Mon, 6 Aug 2001 13:57:34 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f76KvSD05264 for ; Mon, 6 Aug 2001 13:57:28 -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 NAA03840; Mon, 6 Aug 2001 13:57:27 -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 OAA25164; Mon, 6 Aug 2001 14:57:24 -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 f76KvN828749; Mon, 6 Aug 2001 22:57:24 +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 WAA08008; Mon, 6 Aug 2001 22:57:23 +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 f76KvNu66304; Mon, 6 Aug 2001 22:57:23 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200108062057.f76KvNu66304@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com cc: "'Michael Thomas '" , "'Erik Nordmark '" , "Jari Arkko (LMF)" , "Hesham Soliman (ERA)" , "'charliep@iprg.nokia.com '" Subject: Re: [mobile-ip] Concern over draft-team-mobileip-mipv6-sec-reqts- 00.txt In-reply-to: Your message of Wed, 01 Aug 2001 19:41:27 +0200. <034BEFD03799D411A59F00508BDF754603008B9D@esealnt448.al.sw.ericsson.se> Date: Mon, 06 Aug 2001 22:57:23 +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: Let's get an agreement on this: the MN can use AH without needing a new nxt header value and without using AH on every packet with a Home address option if : - No piggybacking was allowed => yes! - The IPsec selectors granularity was refined to see the BU option not the Home address option. => this is not so simple because the destination option header is not a final one (i.e. the next header value is not a valid protocol). So you have to do more than to convert the port field in a profile field as we 'll have to do for ICMPv6 (to get a profile for all ICMPv6 packets but not the neighbor discovery for instance). This seems to be far easier to implement than to make it acceptable (:-)! Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 6 20:05:05 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04517 for ; Mon, 6 Aug 2001 20:05:05 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA09066; Mon, 6 Aug 2001 18:05:51 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA04052; Mon, 6 Aug 2001 17:05:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7704dN06396 for mobile-ip-dist; Mon, 6 Aug 2001 17:04:39 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.84.31] (may be forged)) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7704ZD06389 for ; Mon, 6 Aug 2001 17:04:36 -0700 (PDT) Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.11.4+Sun/8.11.5) with SMTP id f7704gs272927; Mon, 6 Aug 2001 17:04:42 -0700 (PDT) Message-Id: <200108070004.f7704gs272927@jurassic.eng.sun.com> Date: Mon, 6 Aug 2001 17:06:07 -0700 (PDT) From: Samita Chakrabarti Subject: Re: [mobile-ip] Comments on draft-ietf-mobileip-qos-requirements-00.txt To: mobile-ip@sunroof.eng.sun.com, hchaskar@hotmail.com Cc: samita@jurassic.Eng.Sun.COM MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: YesaX2bbyWExuTaldSKWJA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.9 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Hemant, Thanks for your reply. Some comments below. > > then it may need to have some dynamic service level agreements between > > the nodes where the handover is taking place. > > [Hemant] We can put DiffServ in there as well and also quote the point that > you are mentioning about dynamic service level agreements. Anyway, that work > has already started in Seamoby in the form of moving diffserv context in the > context transfer protocol. > Ok. > > > > > >2. section 3.1, bullet item 2, it states: > > "Of course, if > > the end-to-end path changes at large after handover, the QoS > > mechanism MUST be able to address that in a manner that is > > consistent with the QoS scheme(s) used along the new > > end-to-end packet path." > > > > By "new end-to-end" path it means the path between two communicating > >nodes. > > Should not it say that Qos mechanism should be established in the > >'changed > > or new end-to-end' path depending on the Qos mechanism ? > > [Hemant] There was a concern raised on the language that you are proposing. > Somebody said that such a language implies that new end-to-end QoS must be > established. The message that we are sending is that "handovers may change > end-to-end path", so solution may not only focus only on the local path > changes. Now if the QoS mechanism cares about end-to-end path it will have > to be reinitiated, if not it may ignore the end-to-end change. > I see, "should be" may be restrictive. I understood after I read your explanation. Do you think, if you put your explanation there, it might avoid any future confusion ? > > > >3. The scalabality is a mobileip specific qos issue that this requirement > > draft needs to clarify. As JC Martin and I requested the following item > >in > > our earlier comments to mip-qos alias: > > > > A salability requirement could be that no per MN state should be kept > > in the inner nodes: state should be contained as close as possible to > >the > > MN. Also : if the QoS Mechanism is using signaling, it should be > >aggregated > > as close as possible to the MN. > > [Hemant] This is a general requirement for QoS, even for fixed hosts. Could > you please explain why it is relevant "only for mobile IP." This draft does > not want to address requirements that are "common" to both fixed and mobile > hosts, rather we should focus on requirements that are "exclusively" for > mobile IP. > Yes, it might be a general issue in IPqos area. But, mobileip will be most affected in large scale deployment. Having a direction, would have helped. > > > > > >4. > > How about adding a section here for 'inter-technology > > handoff'. What's our qos requirement there? > > Do we expect it to be transparent as it's happening in IP layer ? > > [Hemant] The question we should ask is whether inter-technology handover > apparent at IP layer. Also what is the requirement as such? I think such a > handover is transparent to IP layer, but I can put that requirement (what is > it first?) in if WG agrees on it. > > Offhand I can see bandwidth capacity ( say between 3G and wireless LAN) variation between two netwroks and also the latency in two different technology. The qos application may be aware of these during inter-technology handover. It may not affect the IP layer and if so, then perhaps we may want to mention that or leave it open ?(WG may help us on that decision, as you suggested). > > > >5. The obvious requirement section is not too obvious to many. Can we > >clarify? > > [Hemant] Could you please be more specific and point out which item there is > not obvious and what the confusion might be. The draft has a section on obvious requirement where it states that qos solution for Mobile IP should satisfy obvious requirements such as scalability, security, conservation of bandwitdth....etc. It's not clear to me whether the above listed requirements are a must requirement. I understand it's quite difficult to quantify them as the answers may be unknown at this point. I'd say, it would be good to list a minimum set of items to consider in the Qos solution as obvious (basic?) requirements. (the language "such as" appears to be for examples only) -Samita From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 6 21:03:03 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05095 for ; Mon, 6 Aug 2001 21:03: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 TAA09825; Mon, 6 Aug 2001 19:03:52 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA13327; Mon, 6 Aug 2001 18:03:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7712sG06551 for mobile-ip-dist; Mon, 6 Aug 2001 18:02:54 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7712pD06544 for ; Mon, 6 Aug 2001 18:02: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 SAA13257 for ; Mon, 6 Aug 2001 18:02:58 -0700 (PDT) From: Barani_Subbiah@3com.com Received: from topaz.3com.com (topaz.3com.com [192.156.136.158]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA09250 for ; Mon, 6 Aug 2001 19:02:56 -0600 (MDT) Received: from opal.3com.com (opal.3com.com [139.87.50.117]) by topaz.3com.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f7710bA18256 for ; Mon, 6 Aug 2001 18:00:37 -0700 (PDT) Received: from hqoutbound.ops.3com.com (hqoutbound.ops.3com.com [139.87.48.104]) by opal.3com.com (Switch-2.1.3/Switch-2.1.0) with SMTP id f7712ul13822 for ; Mon, 6 Aug 2001 18:02:56 -0700 (PDT) Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 88256AA1.0005BFCB ; Mon, 6 Aug 2001 18:02:47 -0700 X-Lotus-FromDomain: 3COM To: mobile-ip@sunroof.eng.sun.com Message-ID: <88256AA1.0005BE01.00@hqoutbound.ops.3com.com> Date: Mon, 6 Aug 2001 18:02:55 -0700 Subject: Re: [mobile-ip] Re: Analysis of Latency Propagation with Buffering Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-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 James, Along your theory of reducing signalling over air interface, how does the BUs sent out from MN after a new CoA. Does MN send individual BUs to all CNs that it is talking during hand off? I mean, if the MN has "m" CNs, then there will be "m" BUs per CN. Is there a way, a HA can act as splitter and relay for BUs. Barani. From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 7 02: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 ESMTP id CAA26365 for ; Tue, 7 Aug 2001 02: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 SAA09326; Mon, 6 Aug 2001 18:12: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 RAA12159; Mon, 6 Aug 2001 17:56:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f770tbl06501 for mobile-ip-dist; Mon, 6 Aug 2001 17:55:37 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f770tYD06494 for ; Mon, 6 Aug 2001 17:55: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 RAA16139 for ; Mon, 6 Aug 2001 17:55:40 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA04848 for ; Mon, 6 Aug 2001 18:55: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 RAA24196 for ; Mon, 6 Aug 2001 17:55:38 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f770tba27280 for ; Mon, 6 Aug 2001 17:55:37 -0700 X-mProtect: Mon, 6 Aug 2001 17:55:37 -0700 Nokia Silicon Valley Messaging Protection Received: from maxdialin29.iprg.nokia.com (205.226.20.223, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdMhDd87; Mon, 06 Aug 2001 17:55:34 PDT Message-ID: <3B6F3CA1.A1ACE4C8@iprg.nokia.com> Date: Mon, 06 Aug 2001 17:56:01 -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: [mobile-ip] Piggybacking References: <200108062057.f76KvNu66304@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello folks, One important thing to arrange is that mobile nodes should be allowed to deliver Binding Updates "on-demand", and not upon every change of care-of address, and not immediately after acquisition of a care-of address. This would in many case allow better a reduction in signalling. There are reasonable ways to implement this, and I believe that the ways to do this are also friendly to implementing piggybacking. I think there is also value to allowing a mobile node to send fewer packets, but of course this depends on traffic patterns and the mobility factor. Increasing the burden on bandwidth imposed by sending Binding Updates effectively reduces their applicability, perhaps only by some percentage, but percentage would be significant for some bandwidths and traffic patterns. Piggybacking has not been implemented much, but I think it has enough advantages that it should be retained for improving the future performance of the protocol. Furthermore, according to recent comments, the current state of implementation for Mobile IPv6 is not the prime motivator for retaining or deleting protocol features. In fact, now it seems that no implementation is required to attain Proposed Standard. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 7 02:43:52 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26719 for ; Tue, 7 Aug 2001 02:43: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 XAA05998; Mon, 6 Aug 2001 23:44: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 XAA17331; Mon, 6 Aug 2001 23:44:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f776hQK06949 for mobile-ip-dist; Mon, 6 Aug 2001 23:43: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+Sun/8.11.5) with ESMTP id f776hND06942 for ; Mon, 6 Aug 2001 23:43:23 -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 XAA21873 for ; Mon, 6 Aug 2001 23:43:22 -0700 (PDT) From: James Kempf Message-Id: <200108070643.XAA21873@heliopolis.eng.sun.com> Date: Mon, 6 Aug 2001 23:42:55 -0700 To: Subject: Re: [mobile-ip] Re: Analysis of Latency Propagation with Buffering 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 Barani, > >Along your theory of reducing signalling over air interface, how does the BUs >sent out from MN after a new CoA. Does MN send individual BUs to all CNs that >it >is talking during hand off? > The MN has to send out BUs only if it changes its CoA so it can reduce signalling by not changing its CoA unless it has time. Once it decides to change its CoA, the number of BUs will depend on whether or not there are any outstanding CNs. The MN may wait until there are no outstanding CNs, in which case it must only send a BU to the HA. If there are CNs, the presence or absence of LMM will determine how many BUs need to be sent. >I mean, if the MN has "m" CNs, then there will be "m" BUs per CN. Is there a >way, a HA can act as splitter and relay for BUs. > I don't follow. Unless it piggybacks, the MN must send one BU per CN/CoA, or? Assuming it has one CoA, then it must send one BU per CN, plus one to the HA. jak From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 7 02:55:59 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26831 for ; Tue, 7 Aug 2001 02:55: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 AAA13415; Tue, 7 Aug 2001 00:56:41 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA24089; Mon, 6 Aug 2001 23:56:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f776t9S07050 for mobile-ip-dist; Mon, 6 Aug 2001 23:55: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+Sun/8.11.5) with ESMTP id f776t5D07043 for ; Mon, 6 Aug 2001 23:55:06 -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 XAA22152 for ; Mon, 6 Aug 2001 23:55:06 -0700 (PDT) From: James Kempf Message-Id: <200108070655.XAA22152@heliopolis.eng.sun.com> Date: Mon, 6 Aug 2001 23:54:39 -0700 To: Subject: [mobile-ip] Heterogeneous Handover - How Would it Work? 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 There has been alot of talk about handover between two different technology interfaces over the last year, and it has been used as a justification for alot of work in both Seamoby and MIP WGs. However, it is entirely unclear to me exactly how this would work. For example, it seems to me that to handover between an interface running on one radio link configured with the global home address and an active CoA to another interface which is unconfigured, the MN would have to effectively transfer the global home address from the active interface to the unconfigured interface, then obtain a new CoA on the new interface. But, presumably the home address was registered in the home network associated with a particular radio link technology. Does this imply that there must also be a heterogeneous technology network back in the home network? Are there any security implications of this? If the MN is authenticated through one interface, perhaps including L2 authentication, what would be needed to transfer that to the second interface? And would that matter to the binding between the L2 address and global home address back in the home network? There are probably alot of other details involved in doing heterogenous technology handover. Maybe I'm just being too paranoid, but I think it would be prudent to actually figure out how it would work from a systems perspective before we go further in using heterogeneous handover as a justification for adding various features or removing them. Otherwise, we may end up with lots of features that basically don't reflect reality. A simple, clear description of how heterogeneous handover would work is needed, IMHO. jak From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 7 03:14:11 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27028 for ; Tue, 7 Aug 2001 03:14: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 AAA12375; Tue, 7 Aug 2001 00:15: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 AAA25884; Tue, 7 Aug 2001 00:14:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f777DJj07138 for mobile-ip-dist; Tue, 7 Aug 2001 00:13: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+Sun/8.11.5) with ESMTP id f777DGD07131 for ; Tue, 7 Aug 2001 00:13:16 -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 AAA22548; Tue, 7 Aug 2001 00:13:13 -0700 (PDT) From: James Kempf Message-Id: <200108070713.AAA22548@heliopolis.eng.sun.com> Date: Tue, 7 Aug 2001 00:12:50 -0700 To: , , Subject: Re: [mobile-ip] BETH comments and questions 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 Alper, As mentioned yesterday in the WG meeting, if the AR is not BETH-capable, then it has a responsibility to inform the MN via a RtAdv that the MN has moved, as soon as the L2 trigger is received. This is actually better than the standard MIPv6 algorithm. If the router doesn't support an L2 trigger, then either it uses the standard MIPv6 algorithm and periodically sends out a RtAdv, or, as Ajoy mentioned, the MN detects that its real time stream is interrupted and requests the RtAdv. In general, if the network operator wants to have high performance, they must have equipment to support it, and must arrange for interoperation with neighboring administrative domains so high performance handover can happen. This is not any different from other areas, such as Diffsrv. A mobile node that runs off the edge of a network of Diffsrv routers is going to end up having its real time traffic slow down to best effort. There is no way, in protocol design, to make poor network engineering impossible. jak >them from the mobile-ip archieve..] > >Hi Ajoy, > >I understand that the BETH should be deployed in a domain, therefore >neighbor >ARs in this domain will be BETH capable. But we cannot claim "all" the >neighbor >routers will be BETH capable, as the whole Internet is not a single domain, >and >we don't expect every ARs to support BETH. > >Therefore, I cannot speculate how often but, MN will attach to >BETH-incapable >ARs. > >It's perfectly fine if handoff performance is better when BETH kicks in, and >the performance is as good as stock-MIPv6 whenever BETH is not available. > >But, I think performance of handoff is worse than stock-MIPv6 when MN does a >BETH-to-nonBETH handoff. First it has to wait and detect that BETH didn't >work. >Only after than it can start stock-MIPv6 handoff. I don't know how much >delay >this introduces as the draft doesn't outline the process in this case. So, >how >soon can we detect a real-time flow is cut? > >Also once the MN enters a non-BETH domain, it better "learn" that this is a >non-BETH domain, so it doesn't get hit at every handoff in this domain. > >alper > > > > >Hello Alper: > >Sorry for jumping in the middle of discussion. >Please find my inline response. > >regards, >ajoy > >During a real-time communication, if your MN detects that it has attached to >a new L2, what does it do? It'd hope that oldAR and newAR are doing BETH and >MN would do nothing, as I understand. But, what if the newAR is not BETH >capable, or BETH has failed for some reason. The only way to figure this out >is to wait, I think. There seems to be no other way, because there's no L3 >signaling between MN and newAR. And this wait will effect the handoff time, >if newAR is not doing BETH. > >ajoy: If BETH is deployed in particular access technology, it is assumed >that >neighboring routers will be BETH capable. Neighboring routers have to >understand same protocol to support fast handover. For example, if >neighboring routers do not support same protocol, we cannot support context >transfer, the MN has to negotiate context. This is true for any protocol in >general. If BETH fails due to any reason, MN will detect service disruption >because real time traffic flow will stop. MN can use this information as a >trigger to acquire new COA. If you do not support BETH in low data rate >channel, the service of user will be affected every time MN moves from one >AR >to other. Which one you will choose ? > From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 7 03:55:06 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27264 for ; Tue, 7 Aug 2001 03:55:05 -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 AAA21914; Tue, 7 Aug 2001 00:55:57 -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 AAA18227; Tue, 7 Aug 2001 00:55:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f777rAi07251 for mobile-ip-dist; Tue, 7 Aug 2001 00:53:10 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f777r7D07244 for ; Tue, 7 Aug 2001 00:53:07 -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 AAA04767 for ; Tue, 7 Aug 2001 00:53:13 -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 BAA24824 for ; Tue, 7 Aug 2001 01:53:14 -0600 (MDT) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f777r9N13554 for ; Tue, 7 Aug 2001 09:53:09 +0200 (MEST) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id JAA09030; Tue, 7 Aug 2001 09:53:09 +0200 Message-ID: <3B6F9E00.BB306E2E@era.ericsson.se> Date: Tue, 07 Aug 2001 09:51:28 +0200 From: Mattias Pettersson Organization: Ericsson Research X-Mailer: Mozilla 4.77 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Heterogeneous Handover - How Would it Work? References: <200108070655.XAA22152@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: > > There has been alot of talk about handover between two different technology > interfaces over the last year, and it has been used as a justification > for alot of work in both Seamoby and MIP WGs. However, it is entirely > unclear to me exactly how this would work. For example, it seems to me > that to handover between an interface running on one radio link > configured with the global home address and an active CoA to another > interface which is unconfigured, the MN would have to effectively > transfer the global home address from the active interface to the > unconfigured interface, then obtain a new CoA on the new interface. > But, presumably the home address was registered in the home network > associated with a particular radio link technology. Does this imply that there > must also be a heterogeneous technology network back in the home > network? Are there any security implications of this? If the > MN is authenticated through one interface, perhaps including > L2 authentication, what would be needed to transfer that to > the second interface? And would that matter to the binding between > the L2 address and global home address back in the home network? I can speak from an implementation perspective. In the Ericsson MIPv6 contribution to KAME we used CoAs bound to physical interfaces, while the home address would be bound to a virtual interface (say loopback). The MN would be considered "home" whenever any of the interfaces was at the home subnet. No particular interface was associated with the home subnet. On the other hand, the home address must belong to some ISP/operator. That ISP must provide a home agent and an ip address, and a CoA when the MN is connected to other than the home subnet. Other ISPs that are used are only access providers, and would give the MN its CoA. This of course would cause political problems. Who are the ISPs that are willing to be access providers only, and who will be providing home agent and home address as well? Another approach is to have a home address for every interface that the MN uses. If MN has a cellular interface, it will have a home address from the cellular operator. If the MN also has a WLAN interface, it will have a second home address from the WLAN ISP. But now, which home address will the MN use? The MN will in practice have two identities. Should it register both? Both registrations would use the same CoA if only one access is available. /Mattias > > There are probably alot of other details involved in doing heterogenous > technology handover. Maybe I'm just being too paranoid, but I think it > would be prudent to actually figure out how it would work from a systems > perspective before we go further in using heterogeneous handover as a > justification for adding various features or removing them. Otherwise, we > may end up with lots of features that basically don't reflect reality. A > simple, clear description of how heterogeneous handover would work is needed, > IMHO. > > jak From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 7 05:27:27 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28551 for ; Tue, 7 Aug 2001 05:27: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 CAA16150; Tue, 7 Aug 2001 02:28: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 CAA00787; Tue, 7 Aug 2001 02:27:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f779QQ607432 for mobile-ip-dist; Tue, 7 Aug 2001 02:26:26 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f779QMD07425 for ; Tue, 7 Aug 2001 02:26:23 -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 CAA11444 for ; Tue, 7 Aug 2001 02:26:30 -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 CAA11461 for ; Tue, 7 Aug 2001 02:26:29 -0700 (PDT) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f779QSN19384 for ; Tue, 7 Aug 2001 11:26:28 +0200 (MEST) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id LAA11228; Tue, 7 Aug 2001 11:26:27 +0200 Message-ID: <3B6FB3DE.EE532D69@era.ericsson.se> Date: Tue, 07 Aug 2001 11:24:46 +0200 From: Mattias Pettersson Organization: Ericsson Research X-Mailer: Mozilla 4.77 [en] (Win95; 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: <20010806161311.4276.qmail@web3507.mail.yahoo.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 Thierry, Thierry Ernst wrote: > > --- Mattias Pettersson > wrote: > > I don't question an MR would be useful. The question > > is what functions > > we put in it. > > For me, what it boils down to is that I prefer not > > to have some nodes > > perform operations on behalf of other nodes. It's > > needed at times, but > > hopefully in static configurations (a home agent is > > rather static). I > > don't see a mobile network as (always) a static > > entity, so I would look > > for other solutions. > > > > Also, the trust model for a mobile network with an > > MR doing registration > > on behalf of MNs is more complex than one where each > > MN is out on its > > own. > > MN is quite a confusing term to me. I used to speak > about MNNs in general, MNN being one of MR - LFN - VMN > - LMN. See my requirement draft. The distinction is > useful to avoid confusion - I have noticed we don't > always speak about the same thing. Sorry, I didn't have your draft at hand. I admit that I was using weak definitions. I should really stick to your definitions. > > Then, do you want all MNNs in the network to register > a 128-128 binding with the MR's HA ? Sounds odd to > me. The MNNs in the mobile network doesn't have the same HA as the MR. They can have, but in general they could be VMNs with some arbitrary HA, or be LMN and use some router on the mobile network itself (MR for instance) as HA. The latter sounds like introducing a nesting problem. Back to your question: I haven't studied the problem in detail, so I can't say that all nodes in the mobile network (all MMNs) should use the same HA. However, if they do, as you suggest, then I don't see a problem doing prefix registrations. The HA at least should know what prefixes are delegated to certain MRs. Or, each MNN could register to that HA on its own, but that would be a waste of signalling. > > > Is there such a big need for sending BUs covering an > > entire prefix > > rather than /128? If a MH behind the MR needs to > > update a CN, there is > > pretty low probability that another MH behind the MR > > would be talking to > > the same CN and thus send a BU to that. So each MH > > should take care of > > sending BUs to CNs, and the MR should not aggregate > > them. So, we don't > > need to allow more than /128. > > Yes there is a big need if you want: > - the MR's Home Agent to redirect all packets intended > to nodes behind the MR I agree, if you can convince me that all nodes behind the MR should use that HA. > - to limit the number of BUs in the network Depending on the mobile-awareness the MNNs have, you can do different things here. Mobile-aware MNNs could send /128 to CNs, mobile-unaware MNNs could let MR send entire mobile network prefix to CNs. > - to keep mobility management relative to MR's > mobility away from the nodes behind the MR If so, yes... > - other ... > > Thierry /Mattias PS. I know v6-network-01.txt doesn't deal with MNNs that are moving with regards to the MR. The monetv6-00.txt does addresses it though. I just don't want to rule out these possibilities at this stage. From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 7 06: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 ESMTP id GAA29030 for ; Tue, 7 Aug 2001 06:01: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 EAA16716; Tue, 7 Aug 2001 04:02:05 -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 DAA03216; Tue, 7 Aug 2001 03:00:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f779xQt07835 for mobile-ip-dist; Tue, 7 Aug 2001 02:59:27 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f779xMD07817 for ; Tue, 7 Aug 2001 02:59: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 CAA27517 for ; Tue, 7 Aug 2001 02:59:30 -0700 (PDT) From: Yolanda.Benito-Prieto@t-systems.de Received: from fw11.telekom.de ([62.225.183.250]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA22348 for ; Tue, 7 Aug 2001 02:59:29 -0700 (PDT) Received: by fw11.telekom.de; (8.8.8/1.3/10May95) id LAA32235; Tue, 7 Aug 2001 11:59:11 +0200 (MET DST) Received: from Q9J99.mgb01.telekom.de by U9JWN.mgb01.telekom.de with ESMTP for mobile-ip@sunroof.eng.sun.com; Tue, 7 Aug 2001 11:59:08 +0200 Received: from g9jbq.mgb01.telekom.de by Q9J99.mgb01.telekom.de with ESMTP for mobile-ip@sunroof.eng.sun.com; Tue, 7 Aug 2001 11:58:52 +0200 Received: by G9JBQ.mgb01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Tue, 7 Aug 2001 11:58:51 +0200 Message-Id: <476F91F7CFDBD41182E000D0B7E7E693B9ADA5@U9JM7> To: mobile-ip@sunroof.eng.sun.com Subject: AW: [mobile-ip] A question about 'traceroute' Date: Tue, 7 Aug 2001 11:58:51 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="KS_C_5601-1987" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f779xND07818 Sender: owner-mobile-ip@sunroof.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 So, if you have to give an answer, you would say "Traceroute" works with Mobile IP. Is that right? -----Ursprüngliche Nachricht----- Von: Kim Taeyong [mailto:jeaimetu@lge.com] Gesendet am: Samstag, 28. Juli 2001 04:34 An: mobile-ip@sunroof.eng.sun.com Betreff: Re: [mobile-ip] A question about 'traceroute' 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 Tue Aug 7 08:04:31 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01800 for ; Tue, 7 Aug 2001 08:04: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 FAA25135; Tue, 7 Aug 2001 05:05: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 FAA18194; Tue, 7 Aug 2001 05:04:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f77C3Qt08280 for mobile-ip-dist; Tue, 7 Aug 2001 05:03:26 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f77C3MD08273 for ; Tue, 7 Aug 2001 05: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 FAA23266 for ; Tue, 7 Aug 2001 05:03:28 -0700 (PDT) Received: from web3504.mail.yahoo.com (web3504.mail.yahoo.com [216.115.111.71]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id GAA15913 for ; Tue, 7 Aug 2001 06:03:26 -0600 (MDT) Message-ID: <20010807120327.8097.qmail@web3504.mail.yahoo.com> Received: from [217.33.146.88] by web3504.mail.yahoo.com via HTTP; Tue, 07 Aug 2001 05:03:27 PDT Date: Tue, 7 Aug 2001 05:03:27 -0700 (PDT) From: Thierry Ernst Subject: Re: [mobile-ip] Concerns about draft-mipv6-14 section 4.8 To: mobile-ip@sunroof.eng.sun.com In-Reply-To: <3B6FB3DE.EE532D69@era.ericsson.se> 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 Mattias, --- Mattias Pettersson > > > The MNNs in the mobile network doesn't have the same > HA as the MR. They > can have, but in general they could be VMNs with > some arbitrary HA, or > be LMN and use some router on the mobile network > itself (MR for > instance) as HA. The latter sounds like introducing > a nesting problem. What I advocate is that fixed nodes within the mobile network (LMNs) are not changing their own attachment point as a result of the MR's mobility. Then, they should be mobility-un-aware (if you want me to argue whether they should be mobility aware or not, I can). Then, they don't have a HA, and shouldn't themselves register the careof address of the MR to the MR's HA. Then, here is the need for a prefix registration. Of course, you may allow visiting mobile nodes that enters the mobile network (e.g. a train), what I call VMNs. This is a nested mobility instance. These nodes have their own HA, and it's not MR's HA. VMNs need to register with their HA, but what address ? If they operate Mobile IPv6, they would register a careof address that belongs to the mobile network, i.e. an address that is only topologically correct when the MR is attached on its home link. Packet would transit through the MR's HA, i.e. not optimal routing unless you provide VMN's CN with the MR's careof address too. Alternatively, you may want to use HMIPv6 Extended Mode where VMN obtains a more topologically correct address. > Back to your question: I haven't studied the problem > in detail, so I > can't say that all nodes in the mobile network (all > MMNs) should use the > same HA. However, if they do, as you suggest, then I > don't see a problem > doing prefix registrations. The HA at least should > know what prefixes > are delegated to certain MRs. Or, each MNN could > register to that HA on > its own, but that would be a waste of signalling. > > I agree, if you can convince me that all nodes > behind the MR should use > that HA. I don't say all, I'm just saying that the most general case is where MNNs are only fixed nodes. To me, I can see more instances where MNNs are fixed (LFNs) than mobile (VMNs). In any case, there will always be LFNs in a mobile network, not necessarily VMNs. Even in a train. May be you generalize the "VMN" case too much > Depending on the mobile-awareness the MNNs have, you > can do different > things here. Mobile-aware MNNs could send /128 to > CNs, mobile-unaware > MNNs could let MR send entire mobile network prefix > to CNs. You are not wrong, but I would be happy to hear from you what address you put in the BU if MNNs send the BU itself. > > - to keep mobility management relative to MR's > > mobility away from the nodes behind the MR > > If so, yes... > PS. I know v6-network-01.txt doesn't deal with MNNs > that are moving with > regards to the MR. The monetv6-00.txt does addresses > it though. I just > don't want to rule out these possibilities at this stage. I do not want to rule these possibilities out either, but I want to point out that this is a bit more complicated in face of nested mobility. v6-network-02.txt keeps things simpler, and does not pretend to rule anything out. Draft monetv6-00 is more important and aims to address all possibilities. Thierry Motorola Labs and INRIA Rhone-Alpes. __________________________________________________ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 7 08:48:41 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02549 for ; Tue, 7 Aug 2001 08:48: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 FAA08503; Tue, 7 Aug 2001 05:49: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 FAA22036; Tue, 7 Aug 2001 05:47:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f77CkbH08433 for mobile-ip-dist; Tue, 7 Aug 2001 05:46:37 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f77CkYD08426 for ; Tue, 7 Aug 2001 05:46: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 FAA21842 for ; Tue, 7 Aug 2001 05:46:40 -0700 (PDT) Received: from meshpdc.meshnetworks.com ([205.245.27.196]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA11660 for ; Tue, 7 Aug 2001 06:46:37 -0600 (MDT) Received: by meshpdc.meshnetworks.com with Internet Mail Service (5.5.2653.19) id ; Tue, 7 Aug 2001 08:46:37 -0400 Message-ID: <0DF9FBC42474A24CA50F7A27FB08E04844562B@meshpdc.meshnetworks.com> From: Phillip Neumiller To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Heterogeneous Handover - How Would it Work? Date: Tue, 7 Aug 2001 08:46:31 -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, The handover should be done in two phases (at least). The downstairs handover between access networks is down first and allowed temporarily by the foreign hosting network, i.e. the mobile is given a grace period to do its SeaMoby CT, BETH, FMIPv6 stuff, and only after this occurs "smoothly/softly/seamlessly/gently" does the upstairs handover between administrative domains occur. -pdn > -----Original Message----- > From: James Kempf [mailto:James.Kempf@Sun.COM] > Sent: Tuesday, August 07, 2001 2:55 AM > To: mobile-ip@sunroof.eng.sun.com > Subject: [mobile-ip] Heterogeneous Handover - How Would it Work? > > > There has been alot of talk about handover between two > different technology > interfaces over the last year, and it has been used as a > justification > for alot of work in both Seamoby and MIP WGs. However, it is entirely > unclear to me exactly how this would work. For example, it seems to me > that to handover between an interface running on one radio link > configured with the global home address and an active CoA to another > interface which is unconfigured, the MN would have to effectively > transfer the global home address from the active interface to the > unconfigured interface, then obtain a new CoA on the new interface. > But, presumably the home address was registered in the home network > associated with a particular radio link technology. Does this > imply that there > must also be a heterogeneous technology network back in the home > network? Are there any security implications of this? If the > MN is authenticated through one interface, perhaps including > L2 authentication, what would be needed to transfer that to > the second interface? And would that matter to the binding between > the L2 address and global home address back in the home network? > > There are probably alot of other details involved in doing > heterogenous > technology handover. Maybe I'm just being too paranoid, but I > think it > would be prudent to actually figure out how it would work > from a systems > perspective before we go further in using heterogeneous handover as a > justification for adding various features or removing them. > Otherwise, we > may end up with lots of features that basically don't reflect > reality. A > simple, clear description of how heterogeneous handover would > work is needed, > IMHO. > > jak > From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 7 08:52:22 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02621 for ; Tue, 7 Aug 2001 08:52: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 GAA15773; Tue, 7 Aug 2001 06:52: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 FAA22378; Tue, 7 Aug 2001 05:52:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f77CpmB08483 for mobile-ip-dist; Tue, 7 Aug 2001 05:51:48 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.82.166] (may be forged)) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f77CpiD08476 for ; Tue, 7 Aug 2001 05:51:44 -0700 (PDT) Received: from emirgan (vpn-129-150-4-51.EBay.Sun.COM [129.150.4.51]) by jurassic.eng.sun.com (8.11.4+Sun/8.11.5) with SMTP id f77Cpos413882 for ; Tue, 7 Aug 2001 05:51:50 -0700 (PDT) From: "alper" To: Subject: RE: [mobile-ip] Heterogeneous Handover - How Would it Work? Date: Tue, 7 Aug 2001 05:52:03 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: <3B6F9E00.BB306E2E@era.ericsson.se> 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: 8bit Jim, This is a good subject to discuss. Although I don't see any issues with this, it'd be good to see if everybody agrees, and if there are any issues we are missing. comments start with "aey >"... -----Original Message----- From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile-ip@sunroof.eng.sun.com]On Behalf Of Mattias Pettersson Sent: 07 Aðustos 2001 Salý 00:51 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Heterogeneous Handover - How Would it Work? James Kempf wrote: > > There has been alot of talk about handover between two different technology > interfaces over the last year, and it has been used as a justification > for alot of work in both Seamoby and MIP WGs. However, it is entirely > unclear to me exactly how this would work. For example, it seems to me > that to handover between an interface running on one radio link > configured with the global home address and an active CoA to another > interface which is unconfigured, the MN would have to effectively > transfer the global home address from the active interface to the > unconfigured interface, then obtain a new CoA on the new interface. > But, presumably the home address was registered in the home network > associated with a particular radio link technology. Does this imply that there > must also be a heterogeneous technology network back in the home > network? Are there any security implications of this? If the > MN is authenticated through one interface, perhaps including > L2 authentication, what would be needed to transfer that to > the second interface? And would that matter to the binding between > the L2 address and global home address back in the home network? I can speak from an implementation perspective. In the Ericsson MIPv6 contribution to KAME we used CoAs bound to physical interfaces, while the home address would be bound to a virtual interface (say loopback). aey > yes, that makes sense to me as well. as soon as an interface is attached to a radio link, it can configure a CoA. And after this point, MN can send a BU mapping its home address to this newCoA. aey > from home agent point of view, all it sees is that MN has moved. Hoem agent doesn't have to even know that mn is multihomed, or what L2 technoologies it's using. The MN would be considered "home" whenever any of the interfaces was at the home subnet. No particular interface was associated with the home subnet. aey > right. at this point, mobile node can configure the home address on this interface. On the other hand, the home address must belong to some ISP/operator. That ISP must provide a home agent and an ip address, and a CoA when the MN is connected to other than the home subnet. Other ISPs that are used are only access providers, and would give the MN its CoA. This of course would cause political problems. Who are the ISPs that are willing to be access providers only, and who will be providing home agent and home address as well? aey > it seems like there are two kind of services here. one is providing a home address and home agent service. the other is providing a topological correct address, (coA), service. I think an ISP should be able to provide any or both. Another approach is to have a home address for every interface that the MN uses. If MN has a cellular interface, it will have a home address from the cellular operator. If the MN also has a WLAN interface, it will have a second home address from the WLAN ISP. But now, which home address will the MN use? The MN will in practice have two identities. Should it register both? Both registrations would use the same CoA if only one access is available. aey > distinguishing two services (as above) makes more sense to me. /Mattias alper > > There are probably alot of other details involved in doing heterogenous > technology handover. Maybe I'm just being too paranoid, but I think it > would be prudent to actually figure out how it would work from a systems > perspective before we go further in using heterogeneous handover as a > justification for adding various features or removing them. Otherwise, we > may end up with lots of features that basically don't reflect reality. A > simple, clear description of how heterogeneous handover would work is needed, > IMHO. > > jak From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 7 09:17:51 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03059 for ; Tue, 7 Aug 2001 09:17: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 GAA17647; Tue, 7 Aug 2001 06:18: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 GAA24621; Tue, 7 Aug 2001 06:18:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f77DEwf08608 for mobile-ip-dist; Tue, 7 Aug 2001 06:14:58 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f77DEsD08601 for ; Tue, 7 Aug 2001 06:14:54 -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 GAA18375 for ; Tue, 7 Aug 2001 06:15:01 -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 HAA29442 for ; Tue, 7 Aug 2001 07:14: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 f77DFFY29195 for ; Tue, 7 Aug 2001 06:15:15 -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 ABU09751; Tue, 7 Aug 2001 06:14:59 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id GAA15170; Tue, 7 Aug 2001 06:14:59 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15215.59859.53873.172199@thomasm-u1.cisco.com> Date: Tue, 7 Aug 2001 06:14:59 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Concerns about draft-mipv6-14 section 4.8 In-Reply-To: <20010807120327.8097.qmail@web3504.mail.yahoo.com> References: <3B6FB3DE.EE532D69@era.ericsson.se> <20010807120327.8097.qmail@web3504.mail.yahoo.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 Thierry Ernst writes: > What I advocate is that fixed nodes within the mobile > network (LMNs) are not changing their own attachment > point as a result of the MR's mobility. Then, they > should be mobility-un-aware (if you want me to argue > whether they should be mobility aware or not, I can). > Then, they don't have a HA, and shouldn't themselves > register the careof address of the MR to the MR's HA. > Then, here is the need for a prefix registration. Agreed. > Of course, you may allow visiting mobile nodes that > enters the mobile network (e.g. a train), what I call > VMNs. This is a nested mobility instance. These > nodes have their own HA, and it's not MR's HA. VMNs > need to register with their HA, but what address ? > If they operate Mobile IPv6, they would register a > careof address that belongs to the mobile network, > i.e. an address that is only topologically correct > when the MR is attached on its home link. Packet > would transit through the MR's HA, i.e. not optimal > routing unless you provide VMN's CN with the MR's > careof address too. Alternatively, you may want to > use HMIPv6 Extended Mode where VMN obtains a more > topologically correct address. I believe that this brings out the problem that I describied a while ago: since there are multiple BU's that would be arriving at the CN from different sources, how does the CN know how to *order* the routing headers? You're not proposing that either one or the other send BU's exclusively, right? Also: when I was thinking about this, I scratched down a diagram and flows to make sense of this; I think that any discussion of this would help greatly if we had such a common reference (half volunteering... :) > I don't say all, I'm just saying that the most general > case is where MNNs are only fixed nodes. To me, I can > see more instances where MNNs are fixed (LFNs) than > mobile (VMNs). In any case, there will always be LFNs > in a mobile network, not necessarily VMNs. Even in a > train. Just a nit, but it there may be more instances of LFN's, but I certainly wouldn't consider the case of a VMN on a MR to be an uncommon case. Your friend's palm pilot gets into your car with its mobile router and voila... > You are not wrong, but I would be happy to hear from > you what address you put in the BU if MNNs send the BU > itself. It would clearly put the CoA of it's local attachment point as always, right? If we hide mobility from LFN's, we would want to hide it from MN's, right (how could MR know)? Mike From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 7 09:20:26 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03130 for ; Tue, 7 Aug 2001 09:20: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 HAA03119; Tue, 7 Aug 2001 07:20: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 GAA24861; Tue, 7 Aug 2001 06:20:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f77DJYc08642 for mobile-ip-dist; Tue, 7 Aug 2001 06:19:34 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f77DJVD08635 for ; Tue, 7 Aug 2001 06:19: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 GAA13831 for ; Tue, 7 Aug 2001 06:19:38 -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 HAA01858 for ; Tue, 7 Aug 2001 07:19:35 -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 f77DJZg16881 for ; Tue, 7 Aug 2001 06:19:35 -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 ABU09779; Tue, 7 Aug 2001 06:19:30 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id GAA15173; Tue, 7 Aug 2001 06:19:30 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15215.60130.682736.714917@thomasm-u1.cisco.com> Date: Tue, 7 Aug 2001 06:19:30 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Concerns about draft-mipv6-14 section 4.8 In-Reply-To: <85AA7486A2C1D411BCA20000F8073E430308A43D@crchy271.us.nortel.com> References: <85AA7486A2C1D411BCA20000F8073E430308A43D@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 don't really see these issues and points as solely being related to mobile > networks, however. In what way? As a general issue with tunnel establishment? Mike > > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Monday, August 06, 2001 12:04 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Concerns about draft-mipv6-14 section 4.8 > > > Ok, here's the problem I see. What gives me the > right to assert a routing table modification for a > prefix larger than I'm authorized to route? The > current crop of proposals expect that if I can > route back to where the BU came from (either to > the MN or HA), that is sufficient check to accept > the BU. However, that only guarantees that I can > currently protect one address: the source address > of the BU. Thus if I am a resident on x/8, but am > only authorized for x.y.z/24, I better not be able > to send a BU for x/8. With the current return > routability proposals, I don't believe this is > possible. Nor does having a home agent > *necessarily* help: the home agent may be in > collusion with the MN and not trustable (think > of some script kiddie with their home linux box > acting as a home agent with their hacked up > mobile router). > > As far as I can tell, the only thing that > knows about whether the scope is too broad > is some router, potentially serveral hops > upstream, of the home agent. This is a problem. > > I'll go on record here as voicing some scalability > concerns with the prospect of large server banks > with potentially large binding caches. These are > essentially unaggregated host routes across the > Internet with is sort of unsettling. This is a > general concern with regular BU's, I'll admit, but > it sort of points out that the CN is not > necessarily the best place to send a BU from a > scaling or messaging standpoint. Indeed, it seems > that the optimal place to send a BU is with the > joining router in the path between the HA and MN's > current CoA. > > Mike > > > Thierry Ernst writes: > > As far as Mobile IPv6 is concerned toghether with the > > process of sending BUs to HA and CNs, yes there is an > > AUTHORIZATION issue as previously debated on this > > mailing list about one year ago. The authorization > > problem is exactly the reason why our draft "Prefix > > Scope Binding Updates" > > (draft-ernst-mobileip-v6-network-02.txt - sorry that I > > keep pointing to my drafts but I don't want the people > > to be confused about which draft I am talking about - > > there are 2 of them)was not widely accepted, and also > > the reason why I advocate any MIPv6 extensions about > > network mobility support to be kept away from the > > MIPv6 specification. > > > > Anyway, t6here is a section in our draft that is > > tackling with the AUTHORIZATION issue. Our view is > > that what we need a certificate that says that a > > router is AUTHORIZED to send a BU for a particular > > prefix. The section is rather short, but it is here to > > open the discussion. I would therefore be more than > > happy to have comments on this; that would avoid > > everyone to keep repeating and arguying the same > > things. Having feedback on a draft is the reason to > > write a draft, If we wanted to keep the discussion for > > ourselves we wouldn't have written it. Then, all you > > interested people, please comment on the draft. If > > there is something wrong, please speak up. > > > > > > Thierry. > > Motorola Labs and INRIA Rhone-Alpes > > > > > > > > __________________________________________________ > > Do You Yahoo!? > > Make international calls for as low as $.04/minute with Yahoo! Messenger > > http://phonecard.yahoo.com/ > > > > > > RE: [mobile-ip] Concerns about draft-mipv6-14 section 4.8 > > > >

I don't really see these issues and points as solely being related to mobile networks, however.   >

> >

-----Original Message----- >
From: Michael Thomas [mailto:mat@cisco.com] >
Sent: Monday, August 06, 2001 12:04 PM >
To: mobile-ip@sunroof.eng.sun.com >
Subject: Re: [mobile-ip] Concerns about draft-mipv6-14 section 4.8 >

>
> >

Ok, here's the problem I see. What gives me the >
right to assert a routing table modification for a >
prefix larger than I'm authorized to route? The >
current crop of proposals expect that if I can >
route back to where the BU came from (either to >
the MN or HA), that is sufficient check to accept >
the BU. However, that only guarantees that I can >
currently protect one address: the source address >
of the BU. Thus if I am a resident on x/8, but am >
only authorized for x.y.z/24, I better not be able >
to send a BU for x/8. With the current return >
routability proposals, I don't believe this is >
possible. Nor does having a home agent >
*necessarily* help: the home agent may be in >
collusion with the MN and not trustable (think >
of some script kiddie with their home linux box >
acting as a home agent with their hacked up >
mobile router). >

> >

As far as I can tell, the only thing that >
knows about whether the scope is too broad >
is some router, potentially serveral hops >
upstream, of the home agent. This is a problem. >

> >

I'll go on record here as voicing some scalability >
concerns with the prospect of large server banks >
with potentially large binding caches. These are >
essentially unaggregated host routes across the >
Internet with is sort of unsettling. This is a >
general concern with regular BU's, I'll admit, but >
it sort of points out that the CN is not >
necessarily the best place to send a BU from a >
scaling or messaging standpoint. Indeed, it seems >
that the optimal place to send a BU is with the >
joining router in the path between the HA and MN's >
current CoA. >

> >

            Mike >

>
> >

Thierry Ernst writes: >
 > As far as Mobile IPv6 is concerned toghether with the >
 > process of sending BUs to HA and CNs, yes there is an >
 > AUTHORIZATION issue as previously debated on this >
 > mailing list about one year ago. The authorization >
 > problem is exactly the reason why our draft "Prefix >
 > Scope Binding Updates" >
 > (draft-ernst-mobileip-v6-network-02.txt - sorry that I >
 > keep pointing to my drafts but I don't want the people >
 > to be confused about which draft I am talking about - >
 > there are 2 of them)was not widely accepted, and also >
 > the reason why I advocate any MIPv6 extensions about >
 > network mobility support to be kept away from the >
 > MIPv6 specification. >
 > >
 > Anyway, t6here is a section in our draft that is >
 > tackling with the AUTHORIZATION issue.  Our view is >
 > that what we need a certificate that says that a >
 > router is AUTHORIZED to send a BU for a particular >
 > prefix. The section is rather short, but it is here to >
 > open the discussion. I would therefore be more than >
 > happy to have comments on this; that would avoid >
 > everyone to keep repeating and arguying the same >
 > things.  Having feedback on a draft is the reason to >
 > write a draft, If we wanted to keep the discussion for >
 > ourselves we wouldn't have written it.  Then, all you >
 > interested people, please comment on the draft. If >
 > there is something wrong, please speak up. >
 > >
 > >
 > Thierry. >
 > Motorola Labs and INRIA Rhone-Alpes >
 > >
 > >
 > >
 > __________________________________________________ >
 > Do You Yahoo!? >
 > Make international calls for as low as $.04/minute with Yahoo! Messenger >
 > http://phonecard.yahoo.com/ >

> > > From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 7 09:31:23 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03357 for ; Tue, 7 Aug 2001 09:31: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 HAA11053; Tue, 7 Aug 2001 07:32:04 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA01918; Tue, 7 Aug 2001 06:31:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f77DTED08763 for mobile-ip-dist; Tue, 7 Aug 2001 06:29:14 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f77DTAD08756 for ; Tue, 7 Aug 2001 06:29: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 GAA14762 for ; Tue, 7 Aug 2001 06:29:17 -0700 (PDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA07891 for ; Tue, 7 Aug 2001 07:28:23 -0600 (MDT) 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 f77DQUJ19857 for ; Tue, 7 Aug 2001 06:26:30 -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 ABU09854; Tue, 7 Aug 2001 06:28:17 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id GAA15176; Tue, 7 Aug 2001 06:28:17 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15215.60657.479571.636386@thomasm-u1.cisco.com> Date: Tue, 7 Aug 2001 06:28:17 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Piggybacking In-Reply-To: <3B6F3CA1.A1ACE4C8@iprg.nokia.com> References: <200108062057.f76KvNu66304@givry.rennes.enst-bretagne.fr> <3B6F3CA1.A1ACE4C8@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 It isn't clear that there is in fact any clear win with piggybacking. Indeed, piggybacking is almost certainly going to be lossage with CRTP/ROHC. If you consider layer two's which allow multiple IP packets/frame (which is generally a Good Idea for any slow/contentious upstream), then *not* piggybacking would probably perform better. Also: Alper already outlined many technical deployment issues in IP stacks. Mike Charlie Perkins writes: > Hello folks, > > One important thing to arrange is that mobile nodes should be allowed > to deliver Binding Updates "on-demand", and not upon every change > of care-of address, and not immediately after acquisition of a care-of > address. This would in many case allow better a reduction in signalling. > There are reasonable ways to implement this, and I believe that the > ways to do this are also friendly to implementing piggybacking. > > I think there is also value to allowing a mobile node to send fewer > packets, but of course this depends on traffic patterns and the mobility > factor. Increasing the burden on bandwidth imposed by sending > Binding Updates effectively reduces their applicability, perhaps only > by some percentage, but percentage would be significant for some > bandwidths and traffic patterns. > > Piggybacking has not been implemented much, but I think it has > enough advantages that it should be retained for improving the > future performance of the protocol. Furthermore, according to > recent comments, the current state of implementation for Mobile > IPv6 is not the prime motivator for retaining or deleting protocol > features. In fact, now it seems that no implementation is required > to attain Proposed Standard. > > Regards, > Charlie P. > > > > From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 7 10:14:47 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04506 for ; Tue, 7 Aug 2001 10:14:46 -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 IAA16320; Tue, 7 Aug 2001 08:15: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 HAA25512; Tue, 7 Aug 2001 07:14:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f77EDo108975 for mobile-ip-dist; Tue, 7 Aug 2001 07:13:50 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f77EDlD08968 for ; Tue, 7 Aug 2001 07:13:47 -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 HAA25420 for ; Tue, 7 Aug 2001 07:13:52 -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 IAA14807 for ; Tue, 7 Aug 2001 08:13:48 -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 f77EDnO21355 for ; Tue, 7 Aug 2001 16:13:49 +0200 (MEST) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id QAA18313; Tue, 7 Aug 2001 16:13:48 +0200 Message-ID: <3B6FF725.E08FD1F6@era.ericsson.se> Date: Tue, 07 Aug 2001 16:11:49 +0200 From: Mattias Pettersson Organization: Ericsson Research X-Mailer: Mozilla 4.77 [en] (Win95; 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: <20010807120327.8097.qmail@web3504.mail.yahoo.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 Thierry Ernst wrote: > > Hi Mattias, > > --- Mattias Pettersson > > > > > > > The MNNs in the mobile network doesn't have the same > > HA as the MR. They > > can have, but in general they could be VMNs with > > some arbitrary HA, or > > be LMN and use some router on the mobile network > > itself (MR for > > instance) as HA. The latter sounds like introducing > > a nesting problem. > > What I advocate is that fixed nodes within the mobile > network (LMNs) are not changing their own attachment > point as a result of the MR's mobility. Then, they > should be mobility-un-aware (if you want me to argue > whether they should be mobility aware or not, I can). > Then, they don't have a HA, and shouldn't themselves > register the careof address of the MR to the MR's HA. > Then, here is the need for a prefix registration. I agree that this is one case. Maybe we should start with this simple case and try to make it work. However, I fear that users will require more things from their mobile networks than fixed subnets and one MR. > > Of course, you may allow visiting mobile nodes that > enters the mobile network (e.g. a train), what I call > VMNs. This is a nested mobility instance. These > nodes have their own HA, and it's not MR's HA. VMNs > need to register with their HA, but what address ? > If they operate Mobile IPv6, they would register a > careof address that belongs to the mobile network, > i.e. an address that is only topologically correct > when the MR is attached on its home link. Packet > would transit through the MR's HA, i.e. not optimal > routing unless you provide VMN's CN with the MR's > careof address too. Alternatively, you may want to > use HMIPv6 Extended Mode where VMN obtains a more > topologically correct address. Yes. > > > Back to your question: I haven't studied the problem > > in detail, so I > > can't say that all nodes in the mobile network (all > > MMNs) should use the > > same HA. However, if they do, as you suggest, then I > > don't see a problem > > doing prefix registrations. The HA at least should > > know what prefixes > > are delegated to certain MRs. Or, each MNN could > > register to that HA on > > its own, but that would be a waste of signalling. > > > > I agree, if you can convince me that all nodes > > behind the MR should use > > that HA. > > I don't say all, I'm just saying that the most general > case is where MNNs are only fixed nodes. To me, I can > see more instances where MNNs are fixed (LFNs) than > mobile (VMNs). In any case, there will always be LFNs > in a mobile network, not necessarily VMNs. Even in a > train. > > May be you generalize the "VMN" case too much I just don't want to spend a lot of WG effort on standardising a solution for mobile networks with support for only LFNs, unless this solution can be extended later (if needed) to support mobile-aware MNNs too, and also more complex versions of the structure of the mobile network. If a solution for only LFNs and one for arbitrary MNNs differ a lot, then I think we should go for the latter one immediately. > > > Depending on the mobile-awareness the MNNs have, you > > can do different > > things here. Mobile-aware MNNs could send /128 to > > CNs, mobile-unaware > > MNNs could let MR send entire mobile network prefix > > to CNs. > > You are not wrong, but I would be happy to hear from > you what address you put in the BU if MNNs send the BU > itself. You would need a topologically correct prefix to form CoAs from. The MR could either request one for delegation from the AR (prefix delegation I-D), or use something like multilink subnetting to extend the subnet currently between AR and MR to also cover the mobile network. > > > > - to keep mobility management relative to MR's > > > mobility away from the nodes behind the MR > > > > If so, yes... > > > PS. I know v6-network-01.txt doesn't deal with MNNs > > that are moving with > > regards to the MR. The monetv6-00.txt does addresses > > it though. I just > > don't want to rule out these possibilities at this > stage. > > I do not want to rule these possibilities out either, > but I want to point out that this is a bit more > complicated in face of nested mobility. > v6-network-02.txt keeps things simpler, and does not > pretend to rule anything out. Draft monetv6-00 is > more important and aims to address all possibilities. Yes, nested mobility could show to be so complex that it will in fact be impossible. /Mattias From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 7 10:21:21 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04646 for ; Tue, 7 Aug 2001 10:21:21 -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 IAA22033; Tue, 7 Aug 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 HAA26755; Tue, 7 Aug 2001 07:21:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f77EKHw09037 for mobile-ip-dist; Tue, 7 Aug 2001 07:20:17 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f77EKED09030 for ; Tue, 7 Aug 2001 07:20: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 HAA26497 for ; Tue, 7 Aug 2001 07:20:19 -0700 (PDT) Received: from ertpg15e1.nortelnetworks.com ([47.234.0.36]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA14792 for ; Tue, 7 Aug 2001 08:20:22 -0600 (MDT) Received: from smtprch2.nortel.com (erchg0k [47.113.64.104]) by ertpg15e1.nortelnetworks.com (8.11.0/8.11.0) with ESMTP id f77EJv415393 for ; Tue, 7 Aug 2001 10:20:15 -0400 (EDT) Received: from zrchb200.us.nortel.com by smtprch2.nortel.com; Wed, 1 Aug 2001 16:19:39 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 1 Aug 2001 16:25:41 -0500 Message-ID: <85AA7486A2C1D411BCA20000F8073E4302FDAFF4@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: Wed, 1 Aug 2001 16:25:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C11AD0.8303AB20" 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_01C11AD0.8303AB20 Content-Type: text/plain; charset="iso-8859-1" I'm just glad that I'm not the only one that sees value in it. Thanks for the detail. -----Original Message----- From: Alper Yegin [mailto:Alper.Yegin@eng.sun.com] Sent: Tuesday, July 31, 2001 6:38 PM 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 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 ------_=_NextPart_001_01C11AD0.8303AB20 Content-Type: text/html; charset="iso-8859-1" RE: [mobile-ip] Concern over draft-team-mobileip-mipv6-sec-reqts- 00.txt

I'm just glad that I'm not the only one that sees value in it. Thanks for the detail.

-----Original Message-----
From: Alper Yegin [mailto:Alper.Yegin@eng.sun.com]
Sent: Tuesday, July 31, 2001 6:38 PM
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


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

------_=_NextPart_001_01C11AD0.8303AB20-- From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 7 10:50:17 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05410 for ; Tue, 7 Aug 2001 10:50: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 HAA26669; Tue, 7 Aug 2001 07:50: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 HAA03309; Tue, 7 Aug 2001 07:49:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f77EmQr09233 for mobile-ip-dist; Tue, 7 Aug 2001 07:48:26 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f77EmMD09226 for ; Tue, 7 Aug 2001 07:48: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 HAA10976 for ; Tue, 7 Aug 2001 07:48:28 -0700 (PDT) Received: from tiku.hut.fi (tiku.hut.fi [130.233.228.86]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA23771 for ; Tue, 7 Aug 2001 07:48:27 -0700 (PDT) Received: from gamma.hut.fi (tweckstr@gamma.hut.fi [130.233.224.52]) by tiku.hut.fi (8.9.3/8.9.3) with ESMTP id RAA29388 for ; Tue, 7 Aug 2001 17:48:25 +0300 (EET DST) Date: Tue, 7 Aug 2001 17:48:23 +0300 (EET DST) From: =?ISO-8859-1?Q?Tom_Weckstr=F6m?= To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Heterogeneous Handover - How Would it Work? In-Reply-To: <3B6F9E00.BB306E2E@era.ericsson.se> Message-ID: 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 On Tue, 7 Aug 2001, Mattias Pettersson wrote: mattia >Another approach is to have a home address for every interface that the mattia >MN uses. If MN has a cellular interface, it will have a home address mattia >from the cellular operator. If the MN also has a WLAN interface, it will mattia >have a second home address from the WLAN ISP. But now, which home mattia >address will the MN use? The MN will in practice have two identities. mattia >Should it register both? Both registrations would use the same CoA if mattia >only one access is available. mattia > mattia >/Mattias mattia > Hello Mattias. One of the strengths of MIP is that it preserves the sessions while the mobile terminal moves, because the home IP adress remains the same. Taking this another approach would result in broken sessions while making heterogenous technology handovers, because the home IP address of the MN would be different in each technology. So, I would not implement the second approach at all. The first one (not quoted above, but available in the original email) looks better. Regards, -- Tom Weckström Dynamics group Helsinki University of Technology dynamics@cs.hut.fi http://www.cs.hut.fi/Research/Dynamics/ From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 7 10:51:30 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05478 for ; Tue, 7 Aug 2001 10:51:29 -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 HAA27069; Tue, 7 Aug 2001 07:51: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 HAA03657; Tue, 7 Aug 2001 07:50:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f77Enx809251 for mobile-ip-dist; Tue, 7 Aug 2001 07:49:59 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f77EntD09244 for ; Tue, 7 Aug 2001 07:49: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 HAA27655 for ; Tue, 7 Aug 2001 07:50:01 -0700 (PDT) Received: from web3504.mail.yahoo.com (web3504.mail.yahoo.com [216.115.111.71]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id IAA05447 for ; Tue, 7 Aug 2001 08:49:40 -0600 (MDT) Message-ID: <20010807144744.13623.qmail@web3504.mail.yahoo.com> Received: from [217.33.146.80] by web3504.mail.yahoo.com via HTTP; Tue, 07 Aug 2001 07:47:44 PDT Date: Tue, 7 Aug 2001 07:47:44 -0700 (PDT) From: Thierry Ernst Subject: Re: [mobile-ip] Concerns about draft-mipv6-14 section 4.8 To: mobile-ip@sunroof.eng.sun.com In-Reply-To: <3B6FF725.E08FD1F6@era.ericsson.se> 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: --- Mattias Pettersson > I agree that this is one case. Maybe we should start > with this simple > case and try to make it work. However, I fear that > users will require > more things from their mobile networks than fixed > subnets and one MR. I definitely agree. This is the reason why I have written the requirements draft. > > I just don't want to spend a lot of WG effort on > standardising a > solution for mobile networks with support for only > LFNs, unless this > solution can be extended later (if needed) to > support mobile-aware MNNs > too, and also more complex versions of the structure > of the mobile > network. > If a solution for only LFNs and one for arbitrary > MNNs differ a lot, > then I think we should go for the latter one > immediately. We can based solution on my 'Prefix Scope BU' proposals and extend to the VMN case. My proposal works as is for VMNs, but packet would transit via the MR's HA. At least, that works. > You would need a topologically correct prefix to > form CoAs from. The MR > could either request one for delegation from the AR > (prefix delegation > I-D), or use something like multilink subnetting to > extend the subnet > currently between AR and MR to also cover the mobile > network. Exactly. Then, we agree that something else is needed than simply masking use of Mobile IPv6. Thierry Motorola Labs and INRIA Rhone-Alpes __________________________________________________ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 7 10:58:29 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05603 for ; Tue, 7 Aug 2001 10:58:29 -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 HAA00250; Tue, 7 Aug 2001 07:57:37 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA05450; Tue, 7 Aug 2001 07:57:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f77EuLb09379 for mobile-ip-dist; Tue, 7 Aug 2001 07:56:21 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f77EuHD09372 for ; Tue, 7 Aug 2001 07:56:17 -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 HAA05262 for ; Tue, 7 Aug 2001 07:56:23 -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 IAA22148 for ; Tue, 7 Aug 2001 08:56:19 -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 f77EuEO14285 for ; Tue, 7 Aug 2001 16:56:20 +0200 (MEST) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id QAA19577; Tue, 7 Aug 2001 16:56:14 +0200 Message-ID: <3B700115.37782CEF@era.ericsson.se> Date: Tue, 07 Aug 2001 16:54:13 +0200 From: Mattias Pettersson Organization: Ericsson Research X-Mailer: Mozilla 4.77 [en] (Win95; 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: <3B6FB3DE.EE532D69@era.ericsson.se> <20010807120327.8097.qmail@web3504.mail.yahoo.com> <15215.59859.53873.172199@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 Hi Mike, Michael Thomas wrote: > > Thierry Ernst writes: > > Of course, you may allow visiting mobile nodes that > > enters the mobile network (e.g. a train), what I call > > VMNs. This is a nested mobility instance. These > > nodes have their own HA, and it's not MR's HA. VMNs > > need to register with their HA, but what address ? > > If they operate Mobile IPv6, they would register a > > careof address that belongs to the mobile network, > > i.e. an address that is only topologically correct > > when the MR is attached on its home link. Packet > > would transit through the MR's HA, i.e. not optimal > > routing unless you provide VMN's CN with the MR's > > careof address too. Alternatively, you may want to > > use HMIPv6 Extended Mode where VMN obtains a more > > topologically correct address. > > I believe that this brings out the problem that > I describied a while ago: since there are multiple > BU's that would be arriving at the CN from different > sources, how does the CN know how to *order* the > routing headers? You're not proposing that > either one or the other send BU's exclusively, > right? > The CN would end up with two entries in its binding cache: 1. VMN HoA -> VMN CoA at mobile network 2. mobile network prefix -> MR's CoA So CN would first match VMN HoA to entry 1. Next, it would need to know that it should check the binding cache again, until it gets no more hits. Second run it would match "VMN CoA at mobile network" to entry 2. It would build a routing header (only one) and insert addresses in reverse order, i.e. last hit first. Not very standard, but hopefully works. > Also: when I was thinking about this, I scratched > down a diagram and flows to make sense of this; > I think that any discussion of this would help > greatly if we had such a common reference (half > volunteering... :) I had to draw something myself because this is just impossible to keep in order... :) > Just a nit, but it there may be more instances > of LFN's, but I certainly wouldn't consider the > case of a VMN on a MR to be an uncommon case. > Your friend's palm pilot gets into your car > with its mobile router and voila... Well, you wouldn't want to route traffic for anyone that are in range of the MR. I'd be quite restrictive on how to pick my friends... :) I also see that the mobile network could be partitioned and other things. /Mattias From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 7 11:05:23 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05788 for ; Tue, 7 Aug 2001 11:05: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 JAA02176; Tue, 7 Aug 2001 09:06: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 IAA08211; Tue, 7 Aug 2001 08:05:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f77F4nm09464 for mobile-ip-dist; Tue, 7 Aug 2001 08:04:49 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f77F4jD09457 for ; Tue, 7 Aug 2001 08:04:46 -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 IAA07702 for ; Tue, 7 Aug 2001 08:04:51 -0700 (PDT) Received: from web3503.mail.yahoo.com (web3503.mail.yahoo.com [216.115.111.70]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id JAA00671 for ; Tue, 7 Aug 2001 09:04:48 -0600 (MDT) Message-ID: <20010807150450.24943.qmail@web3503.mail.yahoo.com> Received: from [217.33.146.80] by web3503.mail.yahoo.com via HTTP; Tue, 07 Aug 2001 08:04:50 PDT Date: Tue, 7 Aug 2001 08:04:50 -0700 (PDT) From: Thierry Ernst Subject: Re: [mobile-ip] Concerns about draft-mipv6-14 section 4.8 To: mobile-ip@sunroof.eng.sun.com In-Reply-To: <15215.59859.53873.172199@thomasm-u1.cisco.com> 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: --- Michael Thomas > I believe that this brings out the problem that > I describied a while ago: since there are > multiple > BU's that would be arriving at the CN from > different > sources, how does the CN know how to *order* the > routing headers? You're not proposing that > either one or the other send BU's exclusively, > right? Michael, You are right in the sense that 'this problem would exist if ...'. Everyone knows that you could bottle Paris with 'if's (French expression, attempt to translate ...). However, notice that the 'Prefix Scope BUs' draft specifies that the solution is limited to 'FIXED NODES' within the mobile network. This 'double BUs' problem is not in the right context as there is no actual solution that proposes to send a BU for a VMN, and another one for the MR. I have noticed the problem you are speaking about straight from the beginning and I voluntary excluded the VMN case from the 'Prefix Scope BUs' draft to avoid to enter into details and to propose an easy to implement solution. This problem is only based on assumptions that no one has ever been made. The first target I have is to make people in this WG aware that there are problems to solve, and I focused on the trivial and most obvisous ones. This target is reached. Then, let's make today this subject a working group item, let's discuss pbs and requirements and we can propose solution that address a specific scope of the problem. > Also: when I was thinking about this, I scratched > down a diagram and flows to make sense of this; > I think that any discussion of this would help > greatly if we had such a common reference (half > volunteering... :) > > Just a nit, but it there may be more instances > of LFN's, but I certainly wouldn't consider the > case of a VMN on a MR to be an uncommon case. > Your friend's palm pilot gets into your car > with its mobile router and voila... VMNs are in the requirement draft. > It would clearly put the CoA of it's local > attachment point as always, right? If we Wrong: the Coa is not topologically correct, unless the mobile network renumbers, which brings loads of other issues ... > hide mobility from LFN's, we would want > to hide it from MN's, right (how could MR > know)? > Thierry Motorola Labs and INRIA Rhone-Alpes __________________________________________________ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 7 11:59:55 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06891 for ; Tue, 7 Aug 2001 11:59:54 -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 KAA28385; Tue, 7 Aug 2001 10:00:28 -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 JAA17783; Tue, 7 Aug 2001 09:00:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f77Fwn209635 for mobile-ip-dist; Tue, 7 Aug 2001 08:58: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+Sun/8.11.5) with ESMTP id f77FwkD09628 for ; Tue, 7 Aug 2001 08:58:46 -0700 (PDT) Received: from heliopolis.Eng.Sun.COM (euroapp.Holland.Sun.COM [129.159.197.58]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA06533; Tue, 7 Aug 2001 08:58:48 -0700 (PDT) From: James Kempf Message-Id: <200108071558.IAA06533@heliopolis.eng.sun.com> Date: Tue, 7 Aug 2001 08:58:16 -0700 To: , Subject: Re: [mobile-ip] Heterogeneous Handover - How Would it Work? 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 >On the other hand, the home address must belong to some ISP/operator. >That ISP must provide a home agent and an ip address, and a CoA when the >MN is connected to other than the home subnet. Other ISPs that are used >are only access providers, and would give the MN its CoA. This of course >would cause political problems. Who are the ISPs that are willing to be >access providers only, and who will be providing home agent and home >address as well? > This is an issue. What happens if you have one access provider on one interface, say the wCDMA interface, and another on another, say 802.11? There are now in the US a growing number of 802.11 access providers, and I can imagine someone with a laptop having a wCDMA modem and an 802.11 card. Maybe something like the "roaming consortia" that have sprung up around ISP access might evolve, but the protocol design/engineering issue is whether there is any additional work (such as the NAI in the roaming consortia example) needed to enable sharing of a home address among interfaces for which different ISPs are responsible. Something like SUCV, that would allow an ISP to cryptographically identify to what other ISP an address belonged, might be useful in this context. jak From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 7 12:21:04 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07519 for ; Tue, 7 Aug 2001 12:21: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 KAA21333; Tue, 7 Aug 2001 10:21: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 JAA22549; Tue, 7 Aug 2001 09:21:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f77GJwP09834 for mobile-ip-dist; Tue, 7 Aug 2001 09:19:58 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f77GJtD09827 for ; Tue, 7 Aug 2001 09:19:55 -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 JAA27081 for ; Tue, 7 Aug 2001 09:20:01 -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 JAA03434 for ; Tue, 7 Aug 2001 09:19:56 -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 f77GK6305565 for ; Tue, 7 Aug 2001 09:20:06 -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 ABV01101; Tue, 7 Aug 2001 09:19:54 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA15247; Tue, 7 Aug 2001 09:19:54 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15216.5418.207250.738609@thomasm-u1.cisco.com> Date: Tue, 7 Aug 2001 09:19:54 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Concerns about draft-mipv6-14 section 4.8 In-Reply-To: <20010807150450.24943.qmail@web3503.mail.yahoo.com> References: <15215.59859.53873.172199@thomasm-u1.cisco.com> <20010807150450.24943.qmail@web3503.mail.yahoo.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 Thierry Ernst writes: > You are right in the sense that 'this problem would > exist if ...'. Everyone knows that you could bottle > Paris with 'if's (French expression, attempt to > translate ...). However, notice that the 'Prefix > Scope BUs' draft specifies that the solution is > limited to 'FIXED NODES' within the mobile network. > This 'double BUs' problem is not in the right context > as there is no actual solution that proposes to send a > BU for a VMN, and another one for the MR. I have > noticed the problem you are speaking about straight > from the beginning and I voluntary excluded the VMN > case from the 'Prefix Scope BUs' draft to avoid to > enter into details and to propose an easy to implement > solution. This problem is only based on assumptions > that no one has ever been made. Well, I guess that I'm preceding from the assumption that if we do MR's, that we not limit them to stationary nodes behind a MR. The argument, such as it is, may just be requirements if the WG decides only to consider what you targeted, but until then, I think it's worthwhile to explore the problem space to see whether there's a technical reason to push back on creating a general solution. Part of my motivation here is that we not blindly add features to MIP that ultimately lead to engineering dead ends. This hypothetical network seems both plausible and should nicely demonstrate what a lot of the global implications of mobile networks are. Even though I generally support your general method of hinding mobility, the reason I hedge is because the larger issues may inform us that that was short sighted. > The first target I have is to make people in this WG > aware that there are problems to solve, and I focused > on the trivial and most obvisous ones. This target is > reached. Then, let's make today this subject a working > group item, let's discuss pbs and requirements and we > can propose solution that address a specific scope of > the problem. Sure. > > It would clearly put the CoA of it's local > > attachment point as always, right? If we > > Wrong: the Coa is not topologically correct, unless > the mobile network renumbers, which brings loads of > other issues ... How does an access router which farther downstream from the MR find out which prefix it should hand out? Unrelated: there seems to be an assumption that there is only one uplink on the MR. To my mind, that doesn't seem like an especially good assumption for a generalized MR solution. It's not hard to imagine that an aircrash carrier would want to be multihomed, for example. Mike From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 7 12:37:35 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07939 for ; Tue, 7 Aug 2001 12:37:35 -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 JAA24742; Tue, 7 Aug 2001 09:38: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 JAA26238; Tue, 7 Aug 2001 09:37:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f77GaSN10052 for mobile-ip-dist; Tue, 7 Aug 2001 09:36:28 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f77GaOD10045 for ; Tue, 7 Aug 2001 09:36: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 JAA23269 for ; Tue, 7 Aug 2001 09:36:26 -0700 (PDT) Received: from mail.verizonwireless.com ([199.74.158.61]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA16885 for ; Tue, 7 Aug 2001 09:36:25 -0700 (PDT) Received: from mail.verizonwireless.com by mail.verizonwireless.com (414/1100) with ESMTP id f77GPDh22877 for ; Tue, 7 Aug 2001 12:25:13 -0400 (EDT) Received: by cairvexsmtp01.idc.vzwcorp.com with Internet Mail Service (5.5.2653.19) id ; Tue, 7 Aug 2001 09:35:45 -0700 Message-ID: From: "Dahl, Peter" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Heterogeneous Handover - How Would it Work? Date: Tue, 7 Aug 2001 09:32:58 -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: FYI, the Wireless ISPs (WISPs) are already talking about such roaming issues. There appear to be 2 emerging forums for these discussions, one under the auspices of WECA (http://www.weca.net) known as the WISPr group ('r' being for roaming), the other a yet to be finalized 'WISP Forum' the prime mover for which is a company in Luxembourg (www.excilan.com). Regards -----Original Message----- From: James Kempf [mailto:James.Kempf@Sun.COM] Sent: Tuesday, August 07, 2001 8:58 AM To: mobile-ip@sunroof.eng.sun.com; mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Heterogeneous Handover - How Would it Work? >On the other hand, the home address must belong to some ISP/operator. >That ISP must provide a home agent and an ip address, and a CoA when the >MN is connected to other than the home subnet. Other ISPs that are used >are only access providers, and would give the MN its CoA. This of course >would cause political problems. Who are the ISPs that are willing to be >access providers only, and who will be providing home agent and home >address as well? > This is an issue. What happens if you have one access provider on one interface, say the wCDMA interface, and another on another, say 802.11? There are now in the US a growing number of 802.11 access providers, and I can imagine someone with a laptop having a wCDMA modem and an 802.11 card. Maybe something like the "roaming consortia" that have sprung up around ISP access might evolve, but the protocol design/engineering issue is whether there is any additional work (such as the NAI in the roaming consortia example) needed to enable sharing of a home address among interfaces for which different ISPs are responsible. Something like SUCV, that would allow an ISP to cryptographically identify to what other ISP an address belonged, might be useful in this context. jak From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 7 12:52:27 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08222 for ; Tue, 7 Aug 2001 12:52: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 JAA02064; Tue, 7 Aug 2001 09:51:24 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA03639; Tue, 7 Aug 2001 09:49:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f77Gm7U10188 for mobile-ip-dist; Tue, 7 Aug 2001 09:48:07 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f77Gm3D10179 for ; Tue, 7 Aug 2001 09:48: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 JAA26361 for ; Tue, 7 Aug 2001 09:48:09 -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 KAA24862 for ; Tue, 7 Aug 2001 10:43:58 -0600 (MDT) Received: (qmail 14270 invoked by uid 500); 7 Aug 2001 16:30:01 -0000 Date: Tue, 7 Aug 2001 09:30:01 -0700 From: Pat Calhoun To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Heterogeneous Handover - How Would it Work? Message-ID: <20010807093001.A14253@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 Peter.Dahl@VerizonWireless.com on Tue, Aug 07, 2001 at 09:32:58AM -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: Also, I believe that ETSI is working on a standard called GRX for GSM<->802.11 roaming. PatC On Tue, Aug 07, 2001 at 09:32:58AM -0700, Dahl, Peter wrote: > FYI, the Wireless ISPs (WISPs) are already talking about such roaming > issues. > > There appear to be 2 emerging forums for these discussions, one under the > auspices of WECA (http://www.weca.net) known as the WISPr group ('r' being > for roaming), the other a yet to be finalized 'WISP Forum' the prime mover > for which is a company in Luxembourg (www.excilan.com). > > Regards > > -----Original Message----- > From: James Kempf [mailto:James.Kempf@Sun.COM] > Sent: Tuesday, August 07, 2001 8:58 AM > To: mobile-ip@sunroof.eng.sun.com; mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Heterogeneous Handover - How Would it Work? > > > >On the other hand, the home address must belong to some ISP/operator. > >That ISP must provide a home agent and an ip address, and a CoA when the > >MN is connected to other than the home subnet. Other ISPs that are used > >are only access providers, and would give the MN its CoA. This of course > >would cause political problems. Who are the ISPs that are willing to be > >access providers only, and who will be providing home agent and home > >address as well? > > > > This is an issue. What happens if you have one access provider on > one interface, say the wCDMA interface, and another on another, say 802.11? > There are now in the US a growing number of 802.11 access providers, > and I can imagine someone with a laptop having a wCDMA modem and > an 802.11 card. > > Maybe something like the "roaming consortia" that have sprung up > around ISP access might evolve, but the protocol design/engineering > issue is whether there is any additional work (such as the NAI in > the roaming consortia example) needed to enable sharing of a home > address among interfaces for which different ISPs are responsible. > > Something like SUCV, that would allow an ISP to cryptographically identify > to what other ISP an address belonged, might be useful in this context. > > jak From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 7 13:11:12 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08518 for ; Tue, 7 Aug 2001 13:11: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 LAA02613; Tue, 7 Aug 2001 11:02:33 -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 KAA06750; Tue, 7 Aug 2001 10:01:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f77H0Os10308 for mobile-ip-dist; Tue, 7 Aug 2001 10:00:24 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f77H0LD10301 for ; Tue, 7 Aug 2001 10:00:21 -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 KAA01717 for ; Tue, 7 Aug 2001 10:00: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 KAA03464 for ; Tue, 7 Aug 2001 10:00:27 -0700 (PDT) Received: by megisto-sql1.megisto.com with Internet Mail Service (5.5.2650.21) id ; Tue, 7 Aug 2001 13:00:02 -0400 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Heterogeneous Handover - How Would it Work? Date: Tue, 7 Aug 2001 13:00: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: > > > Also, I believe that ETSI is working on a standard called GRX > for GSM<->802.11 > roaming. > > PatC Do you have more info on this? GRX is a term for the GPRS roaming exchange to allow GPRS roaming between different PLMNs. Phil From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 7 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 ESMTP id OAA10807 for ; Tue, 7 Aug 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 MAA21985; Tue, 7 Aug 2001 12:43: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 LAA27254; Tue, 7 Aug 2001 11:42:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f77IAn310928 for mobile-ip-dist; Tue, 7 Aug 2001 11:10:49 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f77IAjD10921 for ; Tue, 7 Aug 2001 11:10: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 LAA24104 for ; Tue, 7 Aug 2001 11:10:50 -0700 (PDT) Received: from femail39.sdc1.sfba.home.com (femail39.sdc1.sfba.home.com [24.254.60.33]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA22063 for ; Tue, 7 Aug 2001 12:10:43 -0600 (MDT) Received: from CR52378A ([24.112.164.19]) by femail39.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP id <20010807170452.YTJI2644.femail39.sdc1.sfba.home.com@CR52378A> for ; Tue, 7 Aug 2001 10:04:52 -0700 From: "Brad Casemore" To: Subject: RE: [mobile-ip] Heterogeneous Handover - How Would it Work? Date: Tue, 7 Aug 2001 13:05:05 -0400 Message-ID: <000701c11f63$1af39940$13a47018@CR52378A> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2479.0006 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 Aside from the relatively expensive proposition of joining WECA, could anybody point me to a source that could provide an update on WISPr progress? An article appeared in Network World at the end of May, but I haven't seen or heard anything since. > -----Original Message----- > From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile- > ip@sunroof.eng.sun.com] On Behalf Of Dahl, Peter > Sent: Tuesday, August 07, 2001 12:33 PM > To: 'mobile-ip@sunroof.eng.sun.com' > Subject: RE: [mobile-ip] Heterogeneous Handover - How Would it Work? > > FYI, the Wireless ISPs (WISPs) are already talking about such roaming > issues. > > There appear to be 2 emerging forums for these discussions, one under the > auspices of WECA (http://www.weca.net) known as the WISPr group ('r' being > for roaming), the other a yet to be finalized 'WISP Forum' the prime mover > for which is a company in Luxembourg (www.excilan.com). > > Regards > > -----Original Message----- > From: James Kempf [mailto:James.Kempf@Sun.COM] > Sent: Tuesday, August 07, 2001 8:58 AM > To: mobile-ip@sunroof.eng.sun.com; mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Heterogeneous Handover - How Would it Work? > > > >On the other hand, the home address must belong to some ISP/operator. > >That ISP must provide a home agent and an ip address, and a CoA when the > >MN is connected to other than the home subnet. Other ISPs that are used > >are only access providers, and would give the MN its CoA. This of course > >would cause political problems. Who are the ISPs that are willing to be > >access providers only, and who will be providing home agent and home > >address as well? > > > > This is an issue. What happens if you have one access provider on > one interface, say the wCDMA interface, and another on another, say > 802.11? > There are now in the US a growing number of 802.11 access providers, > and I can imagine someone with a laptop having a wCDMA modem and > an 802.11 card. > > Maybe something like the "roaming consortia" that have sprung up > around ISP access might evolve, but the protocol design/engineering > issue is whether there is any additional work (such as the NAI in > the roaming consortia example) needed to enable sharing of a home > address among interfaces for which different ISPs are responsible. > > Something like SUCV, that would allow an ISP to cryptographically identify > to what other ISP an address belonged, might be useful in this context. > > jak From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 7 14:43:51 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10833 for ; Tue, 7 Aug 2001 14:43:50 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA22626; Tue, 7 Aug 2001 12:44: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 LAA27630; Tue, 7 Aug 2001 11:44:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f77If7L10977 for mobile-ip-dist; Tue, 7 Aug 2001 11:41:07 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f77If1D10967 for ; Tue, 7 Aug 2001 11:41: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 LAA00679 for ; Tue, 7 Aug 2001 11:40:40 -0700 (PDT) Received: from dumburken.it.kth.se (dumburken.it.kth.se [130.237.214.122]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA17614 for ; Tue, 7 Aug 2001 12:40:37 -0600 (MDT) Received: (from maguire@localhost) by dumburken.it.kth.se (8.9.3/8.9.3) id UAA04448; Tue, 7 Aug 2001 20:40:22 +0200 (MET DST) Date: Tue, 7 Aug 2001 20:40:22 +0200 (MET DST) Message-Id: <200108071840.UAA04448@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: (Sharif.Shahrier@InterDigital.com) Subject: Re: [mobile-ip] slides fror IETF ad-hoc on NATs References: Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Sharif, You slides present essentially the same ideas as the other proposal for supporting mobility using remapping at routers (using VM ideas) -- "A Network Architecture Providing Host Migration Transparency", by Fumio Teraoka, Yasuhiko Yokore, Mario Tokoro, presented at Sigcomm'91 (Sept. 1991), pp. 209-220. The only difference is that you do the (re)mapping at the NAT boxes, rather than at each of the routers on the path. Chip From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 7 15:07:05 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11190 for ; Tue, 7 Aug 2001 15:07: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 NAA24311; Tue, 7 Aug 2001 13:07:53 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA03496; Tue, 7 Aug 2001 12:07:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f77J5wC11199 for mobile-ip-dist; Tue, 7 Aug 2001 12:05:58 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f77J5sD11192 for ; Tue, 7 Aug 2001 12:05:54 -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 MAA28464 for ; Tue, 7 Aug 2001 12:06: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 NAA21678 for ; Tue, 7 Aug 2001 13:05: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 MAA06932 for ; Tue, 7 Aug 2001 12:05:58 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f77J5vv32551 for ; Tue, 7 Aug 2001 12:05:57 -0700 X-mProtect: Tue, 7 Aug 2001 12:05:57 -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 smtpdWrIV6e; Tue, 07 Aug 2001 12:05:54 PDT Message-ID: <3B703C13.34D5AD2D@iprg.nokia.com> Date: Tue, 07 Aug 2001 12:05: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: [mobile-ip] NAACK option in the fast handoffs 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, in section 4.4.3, Neighbor Advertisement Acknowledgement (NAACK) option, 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 | Sub-Type | Status | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length 8-bit unsigned integer. Length of the option, in octets, excluding the Option Type and Option Length fields. This field MUST be set to 4. The length field. shouldnt it be in terms of 8 octets becase it goes as an option in the router advertisement. and the value 4 is wrong. it MUST set to 1. am i missing something? vijay From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 7 15:11:06 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11285 for ; Tue, 7 Aug 2001 15:11: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 NAA00051; Tue, 7 Aug 2001 13:11: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 MAA04383; Tue, 7 Aug 2001 12:11:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f77JABS11252 for mobile-ip-dist; Tue, 7 Aug 2001 12:10:11 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f77JA7D11245 for ; Tue, 7 Aug 2001 12:10: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 MAA29553 for ; Tue, 7 Aug 2001 12:10:13 -0700 (PDT) Received: from ertpg15e1.nortelnetworks.com ([47.234.0.36]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA27502 for ; Tue, 7 Aug 2001 13:10:11 -0600 (MDT) Received: from smtprch2.nortel.com (erchg0k [47.113.64.104]) by ertpg15e1.nortelnetworks.com (8.11.0/8.11.0) with ESMTP id f77J6G411019 for ; Tue, 7 Aug 2001 15:06:47 -0400 (EDT) Received: from zrchb200.us.nortel.com by smtprch2.nortel.com; Tue, 7 Aug 2001 13:59:35 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 7 Aug 2001 14:05:39 -0500 Message-ID: <85AA7486A2C1D411BCA20000F8073E430308AC97@crchy271.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Piggybacking Date: Tue, 7 Aug 2001 14:05:36 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C11F73.F08F0750" 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_01C11F73.F08F0750 Content-Type: text/plain; charset="iso-8859-1" Michael, Please explain in more detail why you believe the performance would be better without piggybacking. I would suspect the performance to be better with piggybacking. I would also have some severe reservations about having a snooping ROHC compression strategy drive the more pure IP standard. -----Original Message----- From: Michael Thomas [mailto:mat@cisco.com] Sent: Tuesday, August 07, 2001 8:28 AM To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Piggybacking It isn't clear that there is in fact any clear win with piggybacking. Indeed, piggybacking is almost certainly going to be lossage with CRTP/ROHC. If you consider layer two's which allow multiple IP packets/frame (which is generally a Good Idea for any slow/contentious upstream), then *not* piggybacking would probably perform better. Also: Alper already outlined many technical deployment issues in IP stacks. Mike Charlie Perkins writes: > Hello folks, > > One important thing to arrange is that mobile nodes should be allowed > to deliver Binding Updates "on-demand", and not upon every change > of care-of address, and not immediately after acquisition of a care-of > address. This would in many case allow better a reduction in signalling. > There are reasonable ways to implement this, and I believe that the > ways to do this are also friendly to implementing piggybacking. > > I think there is also value to allowing a mobile node to send fewer > packets, but of course this depends on traffic patterns and the mobility > factor. Increasing the burden on bandwidth imposed by sending > Binding Updates effectively reduces their applicability, perhaps only > by some percentage, but percentage would be significant for some > bandwidths and traffic patterns. > > Piggybacking has not been implemented much, but I think it has > enough advantages that it should be retained for improving the > future performance of the protocol. Furthermore, according to > recent comments, the current state of implementation for Mobile > IPv6 is not the prime motivator for retaining or deleting protocol > features. In fact, now it seems that no implementation is required > to attain Proposed Standard. > > Regards, > Charlie P. > > > > ------_=_NextPart_001_01C11F73.F08F0750 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Piggybacking

Michael,

Please explain in more detail why you believe the = performance would be better without piggybacking. I would suspect the = performance to be better with piggybacking.

I would also have some severe reservations about = having a snooping ROHC compression strategy drive the more pure IP = standard.

-----Original Message-----
From: Michael Thomas [mailto:mat@cisco.com]
Sent: Tuesday, August 07, 2001 8:28 AM
To: mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] Piggybacking


It isn't clear that there is in fact any clear = win
with piggybacking. Indeed, piggybacking is = almost
certainly going to be lossage with CRTP/ROHC. = If
you consider layer two's which allow multiple
IP packets/frame (which is generally a Good = Idea
for any slow/contentious upstream), then = *not*
piggybacking would probably perform better.

Also: Alper already outlined many technical
deployment issues in IP stacks.

           Mike

Charlie Perkins writes:
 > Hello folks,
 >
 > One important thing to arrange is that = mobile nodes should be allowed
 > to deliver Binding Updates = "on-demand", and not upon every change
 > of care-of address, and not immediately = after acquisition of a care-of
 > address.  This would in many case = allow better a reduction in signalling.
 > There are reasonable ways to implement = this, and I believe that the
 > ways to do this are also friendly to = implementing piggybacking.
 >
 > I think there is also value to allowing a = mobile node to send fewer
 > packets, but of course this depends on = traffic patterns and the mobility
 > factor.  Increasing the burden on = bandwidth imposed by sending
 > Binding Updates effectively reduces their = applicability, perhaps only
 > by some percentage, but percentage would = be significant for some
 > bandwidths and traffic patterns.
 >
 > Piggybacking has not been implemented = much, but I think it has
 > enough advantages that it should be = retained for improving the
 > future performance of the protocol.  = Furthermore, according to
 > recent comments, the current state of = implementation for Mobile
 > IPv6 is not the prime motivator for = retaining or deleting protocol
 > features.  In fact, now it seems = that no implementation is required
 > to attain Proposed Standard.
 >
 > Regards,
 > Charlie P.
 >
 >
 >
 >

------_=_NextPart_001_01C11F73.F08F0750-- From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 7 15:22:59 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11437 for ; Tue, 7 Aug 2001 15:22: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 NAA15696; Tue, 7 Aug 2001 13:22:49 -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 MAA06690; Tue, 7 Aug 2001 12:21:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f77JKcY11452 for mobile-ip-dist; Tue, 7 Aug 2001 12:20:38 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f77JKZD11445 for ; Tue, 7 Aug 2001 12:20: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 MAA04669 for ; Tue, 7 Aug 2001 12:20:41 -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 NAA11504 for ; Tue, 7 Aug 2001 13:19:57 -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 f77JJT910193 for ; Tue, 7 Aug 2001 15:19:29 -0400 (EDT) Received: from zrchb200.us.nortel.com by smtprch1.nortel.com; Tue, 7 Aug 2001 14:19:50 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 7 Aug 2001 14:19:26 -0500 Message-ID: <85AA7486A2C1D411BCA20000F8073E430308ACCA@crchy271.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Concerns about draft-mipv6-14 section 4.8 Date: Tue, 7 Aug 2001 14:19:22 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C11F75.DD143BD0" Sender: owner-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_01C11F75.DD143BD0 Content-Type: text/plain; charset="iso-8859-1" I see that there are 5 parties involved in route optimized mobility: mobile node correspondent node visited ISP correspodent ISP home ISP of mobile node The issues you raise bring out the ownership issues of addresses and who should be involved in the authentication and authorization of each's use. I believe it should work the same way irrespective of if the MN is a router or just a host /128. They would each have a home prefix and each have a correspondent address or prefix if you will. -----Original Message----- From: Michael Thomas [mailto:mat@cisco.com] Sent: Tuesday, August 07, 2001 8:20 AM To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Concerns about draft-mipv6-14 section 4.8 Glenn Morrow writes: > I don't really see these issues and points as solely being related to mobile > networks, however. In what way? As a general issue with tunnel establishment? Mike > > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Monday, August 06, 2001 12:04 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Concerns about draft-mipv6-14 section 4.8 > > > Ok, here's the problem I see. What gives me the > right to assert a routing table modification for a > prefix larger than I'm authorized to route? The > current crop of proposals expect that if I can > route back to where the BU came from (either to > the MN or HA), that is sufficient check to accept > the BU. However, that only guarantees that I can > currently protect one address: the source address > of the BU. Thus if I am a resident on x/8, but am > only authorized for x.y.z/24, I better not be able > to send a BU for x/8. With the current return > routability proposals, I don't believe this is > possible. Nor does having a home agent > *necessarily* help: the home agent may be in > collusion with the MN and not trustable (think > of some script kiddie with their home linux box > acting as a home agent with their hacked up > mobile router). > > As far as I can tell, the only thing that > knows about whether the scope is too broad > is some router, potentially serveral hops > upstream, of the home agent. This is a problem. > > I'll go on record here as voicing some scalability > concerns with the prospect of large server banks > with potentially large binding caches. These are > essentially unaggregated host routes across the > Internet with is sort of unsettling. This is a > general concern with regular BU's, I'll admit, but > it sort of points out that the CN is not > necessarily the best place to send a BU from a > scaling or messaging standpoint. Indeed, it seems > that the optimal place to send a BU is with the > joining router in the path between the HA and MN's > current CoA. > > Mike > > > Thierry Ernst writes: > > As far as Mobile IPv6 is concerned toghether with the > > process of sending BUs to HA and CNs, yes there is an > > AUTHORIZATION issue as previously debated on this > > mailing list about one year ago. The authorization > > problem is exactly the reason why our draft "Prefix > > Scope Binding Updates" > > (draft-ernst-mobileip-v6-network-02.txt - sorry that I > > keep pointing to my drafts but I don't want the people > > to be confused about which draft I am talking about - > > there are 2 of them)was not widely accepted, and also > > the reason why I advocate any MIPv6 extensions about > > network mobility support to be kept away from the > > MIPv6 specification. > > > > Anyway, t6here is a section in our draft that is > > tackling with the AUTHORIZATION issue. Our view is > > that what we need a certificate that says that a > > router is AUTHORIZED to send a BU for a particular > > prefix. The section is rather short, but it is here to > > open the discussion. I would therefore be more than > > happy to have comments on this; that would avoid > > everyone to keep repeating and arguying the same > > things. Having feedback on a draft is the reason to > > write a draft, If we wanted to keep the discussion for > > ourselves we wouldn't have written it. Then, all you > > interested people, please comment on the draft. If > > there is something wrong, please speak up. > > > > > > Thierry. > > Motorola Labs and INRIA Rhone-Alpes > > > > > > > > __________________________________________________ > > Do You Yahoo!? > > Make international calls for as low as $.04/minute with Yahoo! Messenger > > http://phonecard.yahoo.com/ > > > > > > RE: [mobile-ip] Concerns about draft-mipv6-14 section 4.8 > > > >

I don't really see these issues and points as solely being related to mobile networks, however.   >

> >

-----Original Message----- >
From: Michael Thomas [mailto:mat@cisco.com] >
Sent: Monday, August 06, 2001 12:04 PM >
To: mobile-ip@sunroof.eng.sun.com >
Subject: Re: [mobile-ip] Concerns about draft-mipv6-14 section 4.8 >

>
> >

Ok, here's the problem I see. What gives me the >
right to assert a routing table modification for a >
prefix larger than I'm authorized to route? The >
current crop of proposals expect that if I can >
route back to where the BU came from (either to >
the MN or HA), that is sufficient check to accept >
the BU. However, that only guarantees that I can >
currently protect one address: the source address >
of the BU. Thus if I am a resident on x/8, but am >
only authorized for x.y.z/24, I better not be able >
to send a BU for x/8. With the current return >
routability proposals, I don't believe this is >
possible. Nor does having a home agent >
*necessarily* help: the home agent may be in >
collusion with the MN and not trustable (think >
of some script kiddie with their home linux box >
acting as a home agent with their hacked up >
mobile router). >

> >

As far as I can tell, the only thing that >
knows about whether the scope is too broad >
is some router, potentially serveral hops >
upstream, of the home agent. This is a problem. >

> >

I'll go on record here as voicing some scalability >
concerns with the prospect of large server banks >
with potentially large binding caches. These are >
essentially unaggregated host routes across the >
Internet with is sort of unsettling. This is a >
general concern with regular BU's, I'll admit, but >
it sort of points out that the CN is not >
necessarily the best place to send a BU from a >
scaling or messaging standpoint. Indeed, it seems >
that the optimal place to send a BU is with the >
joining router in the path between the HA and MN's >
current CoA. >

> >

            Mike >

>
> >

Thierry Ernst writes: >
 > As far as Mobile IPv6 is concerned toghether with the >
 > process of sending BUs to HA and CNs, yes there is an >
 > AUTHORIZATION issue as previously debated on this >
 > mailing list about one year ago. The authorization >
 > problem is exactly the reason why our draft "Prefix >
 > Scope Binding Updates" >
 > (draft-ernst-mobileip-v6-network-02.txt - sorry that I >
 > keep pointing to my drafts but I don't want the people >
 > to be confused about which draft I am talking about - >
 > there are 2 of them)was not widely accepted, and also >
 > the reason why I advocate any MIPv6 extensions about >
 > network mobility support to be kept away from the >
 > MIPv6 specification. >
 > >
 > Anyway, t6here is a section in our draft that is >
 > tackling with the AUTHORIZATION issue.  Our view is >
 > that what we need a certificate that says that a >
 > router is AUTHORIZED to send a BU for a particular >
 > prefix. The section is rather short, but it is here to >
 > open the discussion. I would therefore be more than >
 > happy to have comments on this; that would avoid >
 > everyone to keep repeating and arguying the same >
 > things.  Having feedback on a draft is the reason to >
 > write a draft, If we wanted to keep the discussion for >
 > ourselves we wouldn't have written it.  Then, all you >
 > interested people, please comment on the draft. If >
 > there is something wrong, please speak up. >
 > >
 > >
 > Thierry. >
 > Motorola Labs and INRIA Rhone-Alpes >
 > >
 > >
 > >
 > __________________________________________________ >
 > Do You Yahoo!? >
 > Make international calls for as low as $.04/minute with Yahoo! Messenger >
 > http://phonecard.yahoo.com/ >

> > > ------_=_NextPart_001_01C11F75.DD143BD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Concerns about draft-mipv6-14 section = 4.8

I see that there are 5 parties involved in route = optimized mobility:

mobile node
correspondent node
visited ISP
correspodent ISP
home ISP of mobile node

The issues you raise bring out the ownership issues = of addresses and who should be involved in the authentication and = authorization of each's use.

I believe it should work the same way irrespective of = if the MN is a router or just a host /128. They would each have a home = prefix and each have a correspondent address or prefix if you will. =

 

-----Original Message-----
From: Michael Thomas [mailto:mat@cisco.com]
Sent: Tuesday, August 07, 2001 8:20 AM
To: mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] Concerns about = draft-mipv6-14 section 4.8


Glenn Morrow writes:
 > I don't really see these issues and = points as solely being related to mobile
 > networks, however.  

   In what way? As a general issue with = tunnel establishment?

      Mike

 >
 > -----Original Message-----
 > From: Michael Thomas [mailto:mat@cisco.com]
 > Sent: Monday, August 06, 2001 12:04 = PM
 > To: mobile-ip@sunroof.eng.sun.com
 > Subject: Re: [mobile-ip] Concerns about = draft-mipv6-14 section 4.8
 >
 >
 > Ok, here's the problem I see. What gives = me the
 > right to assert a routing table = modification for a
 > prefix larger than I'm authorized to = route? The
 > current crop of proposals expect that if = I can
 > route back to where the BU came from = (either to
 > the MN or HA), that is sufficient check = to accept
 > the BU. However, that only guarantees = that I can
 > currently protect one address: the source = address
 > of the BU. Thus if I am a resident on = x/8, but am
 > only authorized for x.y.z/24, I better = not be able
 > to send a BU for x/8. With the current = return
 > routability proposals, I don't believe = this is
 > possible. Nor does having a home = agent
 > *necessarily* help: the home agent may be = in
 > collusion with the MN and not trustable = (think
 > of some script kiddie with their home = linux box
 > acting as a home agent with their hacked = up
 > mobile router).
 >
 > As far as I can tell, the only thing = that
 > knows about whether the scope is too = broad
 > is some router, potentially serveral = hops
 > upstream, of the home agent. This is a = problem.
 >
 > I'll go on record here as voicing some = scalability
 > concerns with the prospect of large = server banks
 > with potentially large binding caches. = These are
 > essentially unaggregated host routes = across the
 > Internet with is sort of unsettling. This = is a
 > general concern with regular BU's, I'll = admit, but
 > it sort of points out that the CN is = not
 > necessarily the best place to send a BU = from a
 > scaling or messaging standpoint. Indeed, = it seems
 > that the optimal place to send a BU is = with the
 > joining router in the path between the HA = and MN's
 > current CoA.
 >
 >      =     Mike
 >
 >
 > Thierry Ernst writes:
 >  > As far as Mobile IPv6 is = concerned toghether with the
 >  > process of sending BUs to HA = and CNs, yes there is an
 >  > AUTHORIZATION issue as = previously debated on this
 >  > mailing list about one year = ago. The authorization
 >  > problem is exactly the reason = why our draft "Prefix
 >  > Scope Binding = Updates"
 >  > = (draft-ernst-mobileip-v6-network-02.txt - sorry that I
 >  > keep pointing to my drafts but = I don't want the people
 >  > to be confused about which = draft I am talking about -
 >  > there are 2 of them)was not = widely accepted, and also
 >  > the reason why I advocate any = MIPv6 extensions about
 >  > network mobility support to be = kept away from the
 >  > MIPv6 specification.
 >  >
 >  > Anyway, t6here is a section in = our draft that is
 >  > tackling with the = AUTHORIZATION issue.  Our view is
 >  > that what we need a = certificate that says that a
 >  > router is AUTHORIZED to send a = BU for a particular
 >  > prefix. The section is rather = short, but it is here to
 >  > open the discussion. I would = therefore be more than
 >  > happy to have comments on = this; that would avoid
 >  > everyone to keep repeating and = arguying the same
 >  > things.  Having feedback = on a draft is the reason to
 >  > write a draft, If we wanted to = keep the discussion for
 >  > ourselves we wouldn't have = written it.  Then, all you
 >  > interested people, please = comment on the draft. If
 >  > there is something wrong, = please speak up.
 >  >
 >  >
 >  > Thierry.
 >  > Motorola Labs and INRIA = Rhone-Alpes
 >  >
 >  >
 >  >
 >  > = __________________________________________________
 >  > Do You Yahoo!?
 >  > Make international calls for = as low as $.04/minute with Yahoo! Messenger
 >  > http://phonecard.yahoo.com/
 > <!DOCTYPE HTML PUBLIC = "-//W3C//DTD HTML 3.2//EN">
 > <HTML>
 > <HEAD>
 > <META = HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Diso-8859-1">
 > <META NAME=3D"Generator" = CONTENT=3D"MS Exchange Server version 5.5.2654.89">
 > <TITLE>RE: [mobile-ip] Concerns = about draft-mipv6-14 section 4.8</TITLE>
 > </HEAD>
 > <BODY>
 >
 > <P><FONT SIZE=3D2>I don't = really see these issues and points as solely being related to mobile = networks, however.&nbsp;&nbsp; </FONT>

 > </P>
 >
 > <P><FONT = SIZE=3D2>-----Original Message-----</FONT>
 > <BR><FONT SIZE=3D2>From: = Michael Thomas [<A HREF=3D"mailto:mat@cisco.com">mailto:mat@cisco.com</A>]</FO= NT>
 > <BR><FONT SIZE=3D2>Sent: = Monday, August 06, 2001 12:04 PM</FONT>
 > <BR><FONT SIZE=3D2>To: = mobile-ip@sunroof.eng.sun.com</FONT>
 > <BR><FONT SIZE=3D2>Subject: = Re: [mobile-ip] Concerns about draft-mipv6-14 section = 4.8</FONT>
 > </P>
 > <BR>
 >
 > <P><FONT SIZE=3D2>Ok, here's = the problem I see. What gives me the</FONT>
 > <BR><FONT SIZE=3D2>right to = assert a routing table modification for a</FONT>
 > <BR><FONT SIZE=3D2>prefix = larger than I'm authorized to route? The</FONT>
 > <BR><FONT SIZE=3D2>current = crop of proposals expect that if I can</FONT>
 > <BR><FONT SIZE=3D2>route back = to where the BU came from (either to</FONT>
 > <BR><FONT SIZE=3D2>the MN or = HA), that is sufficient check to accept</FONT>
 > <BR><FONT SIZE=3D2>the BU. = However, that only guarantees that I can</FONT>
 > <BR><FONT SIZE=3D2>currently = protect one address: the source address</FONT>
 > <BR><FONT SIZE=3D2>of the BU. = Thus if I am a resident on x/8, but am</FONT>
 > <BR><FONT SIZE=3D2>only = authorized for x.y.z/24, I better not be able</FONT>
 > <BR><FONT SIZE=3D2>to send a = BU for x/8. With the current return</FONT>
 > <BR><FONT = SIZE=3D2>routability proposals, I don't believe this = is</FONT>
 > <BR><FONT SIZE=3D2>possible. = Nor does having a home agent</FONT>
 > <BR><FONT = SIZE=3D2>*necessarily* help: the home agent may be = in</FONT>
 > <BR><FONT SIZE=3D2>collusion = with the MN and not trustable (think</FONT>
 > <BR><FONT SIZE=3D2>of some = script kiddie with their home linux box </FONT>
 > <BR><FONT SIZE=3D2>acting as = a home agent with their hacked up </FONT>
 > <BR><FONT SIZE=3D2>mobile = router). </FONT>
 > </P>
 >
 > <P><FONT SIZE=3D2>As far as I = can tell, the only thing that</FONT>
 > <BR><FONT SIZE=3D2>knows = about whether the scope is too broad</FONT>
 > <BR><FONT SIZE=3D2>is some = router, potentially serveral hops</FONT>
 > <BR><FONT SIZE=3D2>upstream, = of the home agent. This is a problem.</FONT>
 > </P>
 >
 > <P><FONT SIZE=3D2>I'll go on = record here as voicing some scalability</FONT>
 > <BR><FONT SIZE=3D2>concerns = with the prospect of large server banks</FONT>
 > <BR><FONT SIZE=3D2>with = potentially large binding caches. These are</FONT>
 > <BR><FONT = SIZE=3D2>essentially unaggregated host routes across = the</FONT>
 > <BR><FONT SIZE=3D2>Internet = with is sort of unsettling. This is a</FONT>
 > <BR><FONT SIZE=3D2>general = concern with regular BU's, I'll admit, but</FONT>
 > <BR><FONT SIZE=3D2>it sort of = points out that the CN is not</FONT>
 > <BR><FONT = SIZE=3D2>necessarily the best place to send a BU from = a</FONT>
 > <BR><FONT SIZE=3D2>scaling or = messaging standpoint. Indeed, it seems</FONT>
 > <BR><FONT SIZE=3D2>that the = optimal place to send a BU is with the</FONT>
 > <BR><FONT SIZE=3D2>joining = router in the path between the HA and MN's</FONT>
 > <BR><FONT SIZE=3D2>current = CoA.</FONT>
 > </P>
 >
 > = <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&am= p;nbsp; <FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; = Mike</FONT>
 > </P>
 > <BR>
 >
 > <P><FONT SIZE=3D2>Thierry = Ernst writes:</FONT>
 > <BR><FONT = SIZE=3D2>&nbsp;&gt; As far as Mobile IPv6 is concerned = toghether with the</FONT>
 > <BR><FONT = SIZE=3D2>&nbsp;&gt; process of sending BUs to HA and CNs, = yes there is an</FONT>
 > <BR><FONT = SIZE=3D2>&nbsp;&gt; AUTHORIZATION issue as previously = debated on this</FONT>
 > <BR><FONT = SIZE=3D2>&nbsp;&gt; mailing list about one year ago. The = authorization</FONT>
 > <BR><FONT = SIZE=3D2>&nbsp;&gt; problem is exactly the reason why our = draft &quot;Prefix</FONT>
 > <BR><FONT = SIZE=3D2>&nbsp;&gt; Scope Binding = Updates&quot;</FONT>
 > <BR><FONT = SIZE=3D2>&nbsp;&gt; (draft-ernst-mobileip-v6-network-02.txt = - sorry that I</FONT>
 > <BR><FONT = SIZE=3D2>&nbsp;&gt; keep pointing to my drafts but I don't = want the people</FONT>
 > <BR><FONT = SIZE=3D2>&nbsp;&gt; to be confused about which draft I am = talking about -</FONT>
 > <BR><FONT = SIZE=3D2>&nbsp;&gt; there are 2 of them)was not widely = accepted, and also</FONT>
 > <BR><FONT = SIZE=3D2>&nbsp;&gt; the reason why I advocate any MIPv6 = extensions about</FONT>
 > <BR><FONT = SIZE=3D2>&nbsp;&gt; network mobility support to be kept away = from the</FONT>
 > <BR><FONT = SIZE=3D2>&nbsp;&gt; MIPv6 specification.</FONT>
 > <BR><FONT = SIZE=3D2>&nbsp;&gt; </FONT>
 > <BR><FONT = SIZE=3D2>&nbsp;&gt; Anyway, t6here is a section in our draft = that is</FONT>
 > <BR><FONT = SIZE=3D2>&nbsp;&gt; tackling with the AUTHORIZATION = issue.&nbsp; Our view is</FONT>
 > <BR><FONT = SIZE=3D2>&nbsp;&gt; that what we need a certificate that = says that a</FONT>
 > <BR><FONT = SIZE=3D2>&nbsp;&gt; router is AUTHORIZED to send a BU for a = particular</FONT>
 > <BR><FONT = SIZE=3D2>&nbsp;&gt; prefix. The section is rather short, but = it is here to</FONT>
 > <BR><FONT = SIZE=3D2>&nbsp;&gt; open the discussion. I would therefore = be more than</FONT>
 > <BR><FONT = SIZE=3D2>&nbsp;&gt; happy to have comments on this; that = would avoid</FONT>
 > <BR><FONT = SIZE=3D2>&nbsp;&gt; everyone to keep repeating and arguying = the same</FONT>
 > <BR><FONT = SIZE=3D2>&nbsp;&gt; things.&nbsp; Having feedback on a = draft is the reason to</FONT>
 > <BR><FONT = SIZE=3D2>&nbsp;&gt; write a draft, If we wanted to keep the = discussion for</FONT>
 > <BR><FONT = SIZE=3D2>&nbsp;&gt; ourselves we wouldn't have written = it.&nbsp; Then, all you</FONT>
 > <BR><FONT = SIZE=3D2>&nbsp;&gt; interested people, please comment on the = draft. If</FONT>
 > <BR><FONT = SIZE=3D2>&nbsp;&gt; there is something wrong, please speak = up.</FONT>
 > <BR><FONT = SIZE=3D2>&nbsp;&gt; </FONT>
 > <BR><FONT = SIZE=3D2>&nbsp;&gt; </FONT>
 > <BR><FONT = SIZE=3D2>&nbsp;&gt; Thierry.</FONT>
 > <BR><FONT = SIZE=3D2>&nbsp;&gt; Motorola Labs and INRIA = Rhone-Alpes</FONT>
 > <BR><FONT = SIZE=3D2>&nbsp;&gt; </FONT>
 > <BR><FONT = SIZE=3D2>&nbsp;&gt; </FONT>
 > <BR><FONT = SIZE=3D2>&nbsp;&gt; </FONT>
 > <BR><FONT = SIZE=3D2>&nbsp;&gt; = __________________________________________________</FONT>
 > <BR><FONT = SIZE=3D2>&nbsp;&gt; Do You Yahoo!?</FONT>
 > <BR><FONT = SIZE=3D2>&nbsp;&gt; Make international calls for as low as = $.04/minute with Yahoo! Messenger</FONT>
 > <BR><FONT = SIZE=3D2>&nbsp;&gt; <A HREF=3D"http://phonecard.yahoo.com/" = TARGET=3D"_blank">http://phonecard.yahoo.com/</A></FONT>=

 > </P>
 >
 > </BODY>
 > </HTML>

------_=_NextPart_001_01C11F75.DD143BD0-- From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 7 18:09:53 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13212 for ; Tue, 7 Aug 2001 18:09: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 QAA09077; Tue, 7 Aug 2001 16:10: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 PAA12963; Tue, 7 Aug 2001 15:10:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f77M8W211989 for mobile-ip-dist; Tue, 7 Aug 2001 15:08:32 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.89.31] (may be forged)) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f77M8SD11982 for ; Tue, 7 Aug 2001 15:08:28 -0700 (PDT) Received: from emirgan (vpn-129-150-4-104.EBay.Sun.COM [129.150.4.104]) by jurassic.eng.sun.com (8.11.4+Sun/8.11.5) with SMTP id f77M8Zs595628 for ; Tue, 7 Aug 2001 15:08:35 -0700 (PDT) From: "alper" To: Subject: RE: [mobile-ip] Heterogeneous Handover - How Would it Work? Date: Tue, 7 Aug 2001 15:08:47 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <200108071558.IAA06533@heliopolis.eng.sun.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 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: 8bit Hello, -----Original Message----- From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile-ip@sunroof.eng.sun.com]On Behalf Of James Kempf Sent: 07 Aðustos 2001 Salý 08:58 To: mobile-ip@sunroof.eng.sun.com; mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Heterogeneous Handover - How Would it Work? >On the other hand, the home address must belong to some ISP/operator. >That ISP must provide a home agent and an ip address, and a CoA when the >MN is connected to other than the home subnet. Other ISPs that are used >are only access providers, and would give the MN its CoA. This of course >would cause political problems. Who are the ISPs that are willing to be >access providers only, and who will be providing home agent and home >address as well? > This is an issue. What happens if you have one access provider on one interface, say the wCDMA interface, and another on another, say 802.11? There are now in the US a growing number of 802.11 access providers, and I can imagine someone with a laptop having a wCDMA modem and an 802.11 card. aey > I think this is a good scenario, very desirable and feasible in near future. Maybe something like the "roaming consortia" that have sprung up around ISP access might evolve, but the protocol design/engineering issue is whether there is any additional work (such as the NAI in the roaming consortia example) needed to enable sharing of a home address among interfaces for which different ISPs are responsible. Something like SUCV, that would allow an ISP to cryptographically identify to what other ISP an address belonged, might be useful in this context. aey > I think there doesn't have to be a roaming agreement. If you want to use both WLAN and 3G on the same device, you need to make sure you subscribe to both services. Wherever they are available, your MN can do an intelligent selection (price, performance, quality, etc..) and make a handoff from one to another. aey > the access technologies in each might be different. Current and possible near future choices are: 802.11b, 802.1x, AAAv6, BURP, free service.. aey > mobile node should be able to execute one of these independent form what other interface it has. and once it obtains a care-of address, the rest is simple mobile ipv6... aey > if the user is only subscribed to one service, then it can attempt roaming with those networks that rely on AAA (802.1x, AAAv6, BURP, ..) aey > speaking of mobile ipv6, access network shouldn't care what your home address is (unless it's your identity. but it's not if we are using AAA). all you need is a careof address. once you have it you can use it in mobile ipv6 way. (home address option, routing headers, tunneling..) jak alper From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 7 19:09:54 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13987 for ; Tue, 7 Aug 2001 19:09: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 RAA12537; Tue, 7 Aug 2001 17:10:39 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA26114; Tue, 7 Aug 2001 16:10:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f77N9L412469 for mobile-ip-dist; Tue, 7 Aug 2001 16:09:21 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f77N9ID12462 for ; Tue, 7 Aug 2001 16:09:18 -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 QAA23752 for ; Tue, 7 Aug 2001 16:09:24 -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 RAA11246 for ; Tue, 7 Aug 2001 17:09:20 -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 f77N9LO05332 for ; Wed, 8 Aug 2001 01:09:21 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Wed Aug 08 01:09:20 2001 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Aug 2001 01:02:58 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008BA5@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Charles E. Perkins'" Cc: Mobile IP Working Group Subject: [mobile-ip] RE: So what is bicasting vs. buffering Date: Wed, 8 Aug 2001 01:09:14 +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 Charie, > > ok, so then the options are: > > > > 1. mobile initiated (mn signalling over the air) > > 2. network initiated (no over the air signalling) > > Isn't it possible for a network initiated handover to > utilize signalling over the air to tell the mobile node > to get moving? > => It depends on which mode of the FMIPv6 you use especially if BETH is incorporated. > > So, it is always bicasting, but some proposals use different mixes > > of the alternatives above. > > > > => Exactly. As for (1) above, I certainly prefer it > > (or strongly propose) that we work within the current > > Fast Handovers draft. Ie. The MN signals before > > moving. Signalling after the movement would imply an > > unnecessary RTT to release the buffers. > > This is great as long as it is possible. However, for some > systems it may not be possible, and I don't see any reason > to _restrict_ the smoothing request so that it could never > be issued from the new AR. > => Can you give an example of these systems or the reason for it not being possible ? Depending on the example above then if the oAR is aware of the MN's mobility it can act accordingly, if not then there is not point is any smoothing and standard MIPv6 can apply. > > In addition I don't think we need a buffer management > > protocol. The calculation of buffer sizes and > > release ...etc should be left to the oAR (or nAR if > > needed). > > Unfortunately, the details about how much to buffer and so > on are application dependent, and not able to be reliably > calculated by the access routers. > => Does that mean the AR's will have to look into packets and determine separate buffers for different applications ? Sounds complex. > There should probably be > a default minimum capability, agreed. Furthermore, buffering > should be done without request only when it isn't being > charged for, and when doing so doesn't affect the ability > to offer buffering for other customers who might really > need it. > => I find it hard to see charging for buffering as a business case. Do you really think operators will sell and additional "buffering" service to subscribers ? Regs, Hesham From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 7 19:28:42 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14196 for ; Tue, 7 Aug 2001 19:28: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 RAA00436; Tue, 7 Aug 2001 17:29: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 QAA03116; Tue, 7 Aug 2001 16:29:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f77NRx312584 for mobile-ip-dist; Tue, 7 Aug 2001 16:27:59 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f77NRtD12577 for ; Tue, 7 Aug 2001 16:27: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 QAA24347 for ; Tue, 7 Aug 2001 16:28:01 -0700 (PDT) Received: from mail.verizonwireless.com ([199.74.158.61]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA24309 for ; Tue, 7 Aug 2001 16:28:01 -0700 (PDT) Received: from mail.verizonwireless.com by mail.verizonwireless.com (414/1100) with ESMTP id f77NGoh18111 for ; Tue, 7 Aug 2001 19:16:50 -0400 (EDT) Received: by cairvexsmtp01.idc.vzwcorp.com with Internet Mail Service (5.5.2653.19) id ; Tue, 7 Aug 2001 16:27:21 -0700 Message-ID: From: "Dahl, Peter" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Heterogeneous Handover - How Would it Work? Date: Tue, 7 Aug 2001 16:27:16 -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 are also balking at the WECA barrier to entry (we have no product to certify), and would also be interested in some insight to the WISPr proceedings if anyone can provide that. I know that some people are feeling excluded from that Forum (even though they are members), which is the motivation for the 'competing' WISP Forum. The WISP Forum are talking about a meeting possibly in September, probably in the US. I believe Excilan are organizing it, so I would suggest contacting their CEO for more info. He assures me that "the membership fee is substantially lower, and you will get something out of it as well." Rgds -----Original Message----- From: Brad Casemore [mailto:bcasemore@home.com] Sent: Tuesday, August 07, 2001 10:05 AM To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Heterogeneous Handover - How Would it Work? Aside from the relatively expensive proposition of joining WECA, could anybody point me to a source that could provide an update on WISPr progress? An article appeared in Network World at the end of May, but I haven't seen or heard anything since. > -----Original Message----- > From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile- > ip@sunroof.eng.sun.com] On Behalf Of Dahl, Peter > Sent: Tuesday, August 07, 2001 12:33 PM > To: 'mobile-ip@sunroof.eng.sun.com' > Subject: RE: [mobile-ip] Heterogeneous Handover - How Would it Work? > > FYI, the Wireless ISPs (WISPs) are already talking about such roaming > issues. > > There appear to be 2 emerging forums for these discussions, one under the > auspices of WECA (http://www.weca.net) known as the WISPr group ('r' being > for roaming), the other a yet to be finalized 'WISP Forum' the prime mover > for which is a company in Luxembourg (www.excilan.com). > > Regards > > -----Original Message----- > From: James Kempf [mailto:James.Kempf@Sun.COM] > Sent: Tuesday, August 07, 2001 8:58 AM > To: mobile-ip@sunroof.eng.sun.com; mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Heterogeneous Handover - How Would it Work? > > > >On the other hand, the home address must belong to some ISP/operator. > >That ISP must provide a home agent and an ip address, and a CoA when the > >MN is connected to other than the home subnet. Other ISPs that are used > >are only access providers, and would give the MN its CoA. This of course > >would cause political problems. Who are the ISPs that are willing to be > >access providers only, and who will be providing home agent and home > >address as well? > > > > This is an issue. What happens if you have one access provider on > one interface, say the wCDMA interface, and another on another, say > 802.11? > There are now in the US a growing number of 802.11 access providers, > and I can imagine someone with a laptop having a wCDMA modem and > an 802.11 card. > > Maybe something like the "roaming consortia" that have sprung up > around ISP access might evolve, but the protocol design/engineering > issue is whether there is any additional work (such as the NAI in > the roaming consortia example) needed to enable sharing of a home > address among interfaces for which different ISPs are responsible. > > Something like SUCV, that would allow an ISP to cryptographically identify > to what other ISP an address belonged, might be useful in this context. > > jak From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 7 19:37:42 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14341 for ; Tue, 7 Aug 2001 19: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 RAA08841; Tue, 7 Aug 2001 17:38: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 QAA05019; Tue, 7 Aug 2001 16:38:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f77NbPg12696 for mobile-ip-dist; Tue, 7 Aug 2001 16:37:25 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f77NbLD12689 for ; Tue, 7 Aug 2001 16:37: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 QAA04849 for ; Tue, 7 Aug 2001 16:37:27 -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 RAA29937 for ; Tue, 7 Aug 2001 17:37:27 -0600 (MDT) 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 IAA11620 for ; Wed, 8 Aug 2001 08:33:30 +0900 (KST) Received: from aeb099w ([150.150.60.99]) by lgekrhqmh01.lge.com (Lotus Domino Release 5.07a) with SMTP id 2001080808374342:1113 ; Wed, 8 Aug 2001 08:37:43 +0900 Message-ID: <002a01c11f99$2b637440$633c9696@aeb099w> From: "Kim Taeyong" To: References: <476F91F7CFDBD41182E000D0B7E7E693B9ADA5@U9JM7> Subject: Re: [mobile-ip] A question about 'traceroute' Date: Wed, 8 Aug 2001 08:32:05 +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 08/08/2001 08:37:43 AM, Serialize by Router on LGEKRHQMH01/LGE/LG Group(Release 5.07a |May 14, 2001) at 08/08/2001 08:37:45 AM, Serialize complete at 08/08/2001 08:37: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 f77NbLD12690 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit I think traceroute program can work with Mobile IP but it can not trace tunneling section. I think. I do not expriments with mobile IP. From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 7 20:07:42 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14721 for ; Tue, 7 Aug 2001 20:07: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 SAA04922; Tue, 7 Aug 2001 18:08: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 RAA10633; Tue, 7 Aug 2001 17:08:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7807I412830 for mobile-ip-dist; Tue, 7 Aug 2001 17:07:18 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.85.105] (may be forged)) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7807ED12823 for ; Tue, 7 Aug 2001 17:07:14 -0700 (PDT) Received: from emirgan (vpn-129-150-4-69.EBay.Sun.COM [129.150.4.69]) by jurassic.eng.sun.com (8.11.4+Sun/8.11.5) with SMTP id f7807Ks634236 for ; Tue, 7 Aug 2001 17:07:20 -0700 (PDT) From: "alper" To: Subject: RE: [mobile-ip] A question about 'traceroute' Date: Tue, 7 Aug 2001 17:07:33 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal In-Reply-To: <002a01c11f99$2b637440$633c9696@aeb099w> Sender: owner-mobile-ip@sunroof.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 run "traceroute mn" this gives you "ha" and "fa_or_colocated_coa." (look at last two hops before mn) now run "traceroute -g ha fa_or_colocated_coa" (-g adds a LSRR to the probing packet that has to go through the specified gateway) now you see what makes up the tunnel. alper -----Original Message----- From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile-ip@sunroof.eng.sun.com]On Behalf Of Kim Taeyong Sent: 07 A©£ustos 2001 Saly 16:32 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] A question about 'traceroute' I think traceroute program can work with Mobile IP but it can not trace tunneling section. I think. I do not expriments with mobile IP. From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 7 20: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 ESMTP id UAA14877 for ; Tue, 7 Aug 2001 20:27: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 SAA21234; Tue, 7 Aug 2001 18:28: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 RAA14380; Tue, 7 Aug 2001 17:28:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f780Qj913003 for mobile-ip-dist; Tue, 7 Aug 2001 17:26:45 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f780QfD12996 for ; Tue, 7 Aug 2001 17:26: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 RAA05446 for ; Tue, 7 Aug 2001 17:26:48 -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 RAA20627 for ; Tue, 7 Aug 2001 17:26:47 -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 JAA26660 for ; Wed, 8 Aug 2001 09:22:53 +0900 (KST) Received: from aeb099w ([150.150.60.99]) by lgekrhqmh01.lge.com (Lotus Domino Release 5.07a) with SMTP id 2001080809270784:7699 ; Wed, 8 Aug 2001 09:27:07 +0900 Message-ID: <004a01c11fa0$126c7250$633c9696@aeb099w> From: "Kim Taeyong" To: References: Subject: Re: [mobile-ip] A question about 'traceroute' Date: Wed, 8 Aug 2001 09:21:30 +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 08/08/2001 09:27:07 AM, Serialize by Router on LGEKRHQMH01/LGE/LG Group(Release 5.07a |May 14, 2001) at 08/08/2001 09:27:08 AM, Serialize complete at 08/08/2001 09:27:08 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 f780QgD12997 Sender: owner-mobile-ip@sunroof.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. But steel there is some problem. result of following execution do not guarantee that MN use that route(s) next time. >now run "traceroute -g ha fa_or_colocated_coa" (-g adds a LSRR to the >probing >packet that has to go through the specified gateway) To guarantee that, there must be atomic operation of "traceroute mn traceroute -g ha fa_or_colocated_coa" regards Tae-yong From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 8 00:52:43 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19463 for ; Wed, 8 Aug 2001 00:52: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 WAA18731; Tue, 7 Aug 2001 22:53: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 VAA16176; Tue, 7 Aug 2001 21:53:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f784pod13524 for mobile-ip-dist; Tue, 7 Aug 2001 21:51:50 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f784pkD13517 for ; Tue, 7 Aug 2001 21:51:46 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA19852 for ; Tue, 7 Aug 2001 21:51:53 -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 WAA17886 for ; Tue, 7 Aug 2001 22:51:50 -0600 (MDT) Received: from cychong (a22416 [165.213.224.16]) by telecom.samsung.co.kr (8.9.3/8.9.3) with SMTP id NAA23275 for ; Wed, 8 Aug 2001 13:54:29 +0900 (KST) Message-ID: <001201c11fc6$60c2f660$10e0d5a5@cychong> From: "Chae-yong Chong" To: References: <476F91F7CFDBD41182E000D0B7E7E693B9ADA5@U9JM7> Subject: Re: [mobile-ip] A question about 'traceroute' Date: Wed, 8 Aug 2001 13:55:41 +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 f784pkD13518 Sender: owner-mobile-ip@sunroof.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 did not test it, however in my understanding I think it will work. However, I did not test it. ----- Original Message ----- From: To: Sent: Tuesday, August 07, 2001 6:58 PM Subject: AW: [mobile-ip] A question about 'traceroute' > So, if you have to give an answer, you would say "Traceroute" works with Mobile IP. Is that right? > > -----Urspr?gliche Nachricht----- > Von: Kim Taeyong [mailto:jeaimetu@lge.com] > Gesendet am: Samstag, 28. Juli 2001 04:34 > An: mobile-ip@sunroof.eng.sun.com > Betreff: Re: [mobile-ip] A question about 'traceroute' > > 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 Wed Aug 8 02:20:27 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06691 for ; Wed, 8 Aug 2001 02:20: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 XAA11065; Tue, 7 Aug 2001 23:21: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 XAA25203; Tue, 7 Aug 2001 23:20:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f786JFk13706 for mobile-ip-dist; Tue, 7 Aug 2001 23:19:15 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f786JBD13699 for ; Tue, 7 Aug 2001 23:19:11 -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 XAA09057; Tue, 7 Aug 2001 23:19:15 -0700 (PDT) From: James Kempf Message-Id: <200108080619.XAA09057@heliopolis.eng.sun.com> Date: Tue, 7 Aug 2001 23:18:43 -0700 To: , Subject: Re: [mobile-ip] Heterogeneous Handover - How Would it Work? 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 Pat, I think they already have such a standard and I believe it only works with GPRS. jak >Also, I believe that ETSI is working on a standard called GRX for GSM<->802.11 >roaming. > >PatC >On Tue, Aug 07, 2001 at 09:32:58AM -0700, Dahl, Peter wrote: >> FYI, the Wireless ISPs (WISPs) are already talking about such roaming >> issues. >> >> There appear to be 2 emerging forums for these discussions, one under the >> auspices of WECA (http://www.weca.net) known as the WISPr group ('r' being >> for roaming), the other a yet to be finalized 'WISP Forum' the prime mover >> for which is a company in Luxembourg (www.excilan.com). >> >> Regards >> >> -----Original Message----- >> From: James Kempf [mailto:James.Kempf@Sun.COM] >> Sent: Tuesday, August 07, 2001 8:58 AM >> To: mobile-ip@sunroof.eng.sun.com; mobile-ip@sunroof.eng.sun.com >> Subject: Re: [mobile-ip] Heterogeneous Handover - How Would it Work? >> >> >> >On the other hand, the home address must belong to some ISP/operator. >> >That ISP must provide a home agent and an ip address, and a CoA when the >> >MN is connected to other than the home subnet. Other ISPs that are used >> >are only access providers, and would give the MN its CoA. This of course >> >would cause political problems. Who are the ISPs that are willing to be >> >access providers only, and who will be providing home agent and home >> >address as well? >> > >> >> This is an issue. What happens if you have one access provider on >> one interface, say the wCDMA interface, and another on another, say 802.11? >> There are now in the US a growing number of 802.11 access providers, >> and I can imagine someone with a laptop having a wCDMA modem and >> an 802.11 card. >> >> Maybe something like the "roaming consortia" that have sprung up >> around ISP access might evolve, but the protocol design/engineering >> issue is whether there is any additional work (such as the NAI in >> the roaming consortia example) needed to enable sharing of a home >> address among interfaces for which different ISPs are responsible. >> >> Something like SUCV, that would allow an ISP to cryptographically identify >> to what other ISP an address belonged, might be useful in this context. >> >> jak From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 8 02:38:03 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06883 for ; Wed, 8 Aug 2001 02:38:02 -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 XAA14927; Tue, 7 Aug 2001 23:38: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 XAA26523; Tue, 7 Aug 2001 23:37:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f786a7b13783 for mobile-ip-dist; Tue, 7 Aug 2001 23:36: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+Sun/8.11.5) with ESMTP id f786a3D13776 for ; Tue, 7 Aug 2001 23:36:04 -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 XAA09433; Tue, 7 Aug 2001 23:36:06 -0700 (PDT) From: James Kempf Message-Id: <200108080636.XAA09433@heliopolis.eng.sun.com> Date: Tue, 7 Aug 2001 23:35:35 -0700 To: , "'Charles E. Perkins'" Cc: "Mobile IP Working Group" Subject: Re: [mobile-ip] RE: So what is bicasting vs. buffering 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 Hesham, >> > So, it is always bicasting, but some proposals use different mixes >> > of the alternatives above. >> > >> > => Exactly. As for (1) above, I certainly prefer it >> > (or strongly propose) that we work within the current >> > Fast Handovers draft. Ie. The MN signals before >> > moving. Signalling after the movement would imply an >> > unnecessary RTT to release the buffers. >> >> This is great as long as it is possible. However, for some >> systems it may not be possible, and I don't see any reason >> to _restrict_ the smoothing request so that it could never >> be issued from the new AR. >> > => Can you give an example of these systems or > the reason for it not being possible ? > Depending on the example above then if the oAR is > aware of the MN's mobility it can act accordingly, > if not then there is not point is any smoothing and > standard MIPv6 can apply. > > > I think Charlie was thinking of 802.11. L3 on the MN only leans of a handover after it has happened. Don't know if the AP L2 does default buffering for a MN that has moved, as is the case for dormant mode MNs, however. jak From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 8 08:23:04 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10996 for ; Wed, 8 Aug 2001 08:23: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 GAA23154; Wed, 8 Aug 2001 06:23: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 FAA22481; Wed, 8 Aug 2001 05:22:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f78CLWt14608 for mobile-ip-dist; Wed, 8 Aug 2001 05:21:32 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f78CLSD14601 for ; Wed, 8 Aug 2001 05:21:28 -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 FAA22901 for ; Wed, 8 Aug 2001 05:21:34 -0700 (PDT) Received: from ws130.nomadiclab.com (ws130.nomadiclab.com [195.165.196.130]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA23164 for ; Wed, 8 Aug 2001 06:21:35 -0600 (MDT) Received: from ws34.nomadiclab.com (ws34.nomadiclab.com [195.165.196.34]) by ws130.nomadiclab.com (Postfix) with ESMTP id A478872504 for ; Wed, 8 Aug 2001 15:21:24 +0300 (EEST) Received: from nomadiclab.com (localhost [127.0.0.1]) by ws34.nomadiclab.com (Postfix) with ESMTP id A1360BA03 for ; Wed, 8 Aug 2001 15:21:23 +0300 (EEST) Message-ID: <3B712FBB.607E428B@nomadiclab.com> Date: Wed, 08 Aug 2001 13:25:31 +0100 From: Pekka Nikander X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en,fi MIME-Version: 1.0 To: MobileIP Mailing List Subject: [mobile-ip] About authorization and security policies 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 If I understood correctly the discussion on Monday at the mobileip WG meeting, people seem to agree that we can and we should separate the problem of authenticating individual BUs and and the problem creating keying material for authenticating BUs. I think considering the problems separately is a good thing. However, based on the discussions I've had with some people, there seems to be some tendency to forget the authorization and security policy issue when we do this separation. In this message I try to (once again) clarify the issue. Now, independent on whether the actual BUs are authenticated and integrity protected with AH (or ESP if you will) or using separate authentication data in the BU itself (a la current -14 draft), care must be taken that the keying material used to create and verify the protection has been _created_ in a suitable way. That is, the SA used to protect the BU must be _authorized_ to protect BUs _for_the_specific_Home_Address_. Please note that I am leaving some implementation details aside (like how to use IPsec SDP to differentiate BUs from other traffic). My point really is try to clarify the need for a proper security policy and for making sure that the key management protocol takes care of checking that the security policy requirements are fulfilled when the SA is created. Let me consider four combinations: a) using IKE and AH/ESP and b) using BAKE and -14 authentication data c) using IKE and -14 authentication data d) using BAKE and AH/ESP Case A. IKE and AH/ESP Let us assume that AH (or ESP with integrity protection) is used to protect the BUs. In that case, there must be an entry in the IPsec SPD specifying at the receiving host (CN) that if the BU is protected with the given SA, then the BU can be accepted and the corresponding Binding Cache entry can be created. Otherwise, if the SDP databased does not allow Binding Cache entry creation, such an entry MUST NOT be created even if the packet integrity and authenticity was correctly verified. In other words, the SPD makes sure that the SA is _authorized_ to protect BUs for that specific Home Address. It is important to note that it is _not_ enough that the BU is protected with _some_ SA, but that the SA used for protection MUST be created in such a way that it is known to be properly authorized. [Side note: Some people have pointed out that if we get a separate next header number for BUs and discontinue piggypacking, current IPsec SPD implementations and key management protocols do have enough of granularity to define and create such a policy. However, that is not the point of this message.] What is important to note here is that even if you use a (local) PKI so that you know who your peer is, you DO have the danger of creating not-properly-authorized SPD entries. That is, when running a key management protocol and checking the certificates, you a) either must know (or at least believe) that all hosts certified by your PKI are fully honest and competent, or b) your PKI must explicitly contain information specifying the home addresses of the hosts. Furthermore, in the latter case, even if the PKI contains the home addresses, you must somehow know that the CAs in the PKI are either fully honest and competent, or that they are otherwise authorized to specify the home addresses given. [Site note: Since X.509 certificates may specify IP addresses as identifiers, you can establish b). However, you still have to trust in the competence of your CAs checking the IP addresses when creating certificates. Note also that if you have a local PKI, you may well essume a). You just need to be aware that you are making such an assumption (if you are), and the dangers created. Again, however, that's not the point.] Case B. BAKE and -14 authentication Let us now assume that -14 authentication is used to protect the authenticity and the integrity of the BUs. Now, the implementation itself implicitly takes care of part of the policy, since the -14 authentication cannot be used for anything else but authenticating BUs. However, care must still be made to make sure that the SA used is authorized for creating Binding Cache Entries for the specific Home Address. Thus, from the policy point of view, the most important thing for BAKE is to make sure that when an SA is created (as a result of running BAKE), there is a reasonable amount of assurance that the peer node (who shares the SA) is really authorized to create Binding Cache entries for its (claimed) Home Address. Basically, BAKE achieves this by checking that the peer node is reachable through the Home Address. Case C. IKE and -14 authentication If we want to use IKE with -14 authentication, we basically need a new DOI (or extension to the Internet DOI), specifying how authentication data for -14 BU authentication is created. That is certainly some amount of work, but doable. On the other hand, however, care must still be made that when the SAs are created, IKE checks that the peer node is indeed authorized to create Binding Cache entries for the given Home Address. Thus, in this sense the situation is similar to Case A. Case D. BAKE and AH/ESP authentication There is no fundamental reason why BAKE could not be used for creating AH or ESP SAs. The only restriction is that such AH or ESP SA __MAY_NOT__ be used for any other purpose but protecting BUs. In this sense, we come back to the Case A SPD discussion, where I noted that the IPsec SPD MUST be able differentiate BUs from other packets. In this case, however, the SA is valid ONLY for BU authentication, i.e., in a way reverse to the Case A situation where a generic IPsec SA is NOT good for BU authentication unless the peer authorization has been positively checked during the IKE negotiation. I hope this helps to clarify the situation. --Pekka Nikander From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 8 14:29:58 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18800 for ; Wed, 8 Aug 2001 14:29: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 LAA09473; Wed, 8 Aug 2001 11:30: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 LAA01520; Wed, 8 Aug 2001 11:29:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f78ISbg16746 for mobile-ip-dist; Wed, 8 Aug 2001 11:28:37 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f78ISXD16739 for ; Wed, 8 Aug 2001 11:28: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 LAA05339 for ; Wed, 8 Aug 2001 11:28:39 -0700 (PDT) Received: from femail31.sdc1.sfba.home.com (femail31.sdc1.sfba.home.com [24.254.60.21]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA22202 for ; Wed, 8 Aug 2001 12:28:42 -0600 (MDT) Received: from CR52378A ([24.112.164.19]) by femail31.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP id <20010808182837.BHGJ25528.femail31.sdc1.sfba.home.com@CR52378A> for ; Wed, 8 Aug 2001 11:28:37 -0700 From: "Brad Casemore" To: Subject: RE: [mobile-ip] Heterogeneous Handover - How Would it Work? Date: Wed, 8 Aug 2001 14:28:42 -0400 Message-ID: <010401c12037$f3d50a80$13a47018@CR52378A> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: <200108080619.XAA09057@heliopolis.eng.sun.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2479.0006 Sender: owner-mobile-ip@sunroof.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 If that is the case, then WECA's WISPr is dedicated to 802.11b roaming, while the ETSI has assigned a group to address GPRS roaming. Is there a group anywhere that is looking into the technical issues associated with heterogeneous network roaming (such as between, theoretically, 802.11b WLANs and GPRS)? Brad > -----Original Message----- > From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile- > ip@sunroof.eng.sun.com] On Behalf Of James Kempf > Sent: Wednesday, August 08, 2001 2:19 AM > To: mobile-ip@sunroof.eng.sun.com; mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Heterogeneous Handover - How Would it Work? > > Pat, > > I think they already have such a standard and I believe it only works > with GPRS. > > jak > > >Also, I believe that ETSI is working on a standard called GRX for GSM<- > >802.11 > >roaming. > > > >PatC > >On Tue, Aug 07, 2001 at 09:32:58AM -0700, Dahl, Peter wrote: > >> FYI, the Wireless ISPs (WISPs) are already talking about such roaming > >> issues. > >> > >> There appear to be 2 emerging forums for these discussions, one under > the > >> auspices of WECA (http://www.weca.net) known as the WISPr group ('r' > being > >> for roaming), the other a yet to be finalized 'WISP Forum' the prime > mover > >> for which is a company in Luxembourg (www.excilan.com). > >> > >> Regards > >> > >> -----Original Message----- > >> From: James Kempf [mailto:James.Kempf@Sun.COM] > >> Sent: Tuesday, August 07, 2001 8:58 AM > >> To: mobile-ip@sunroof.eng.sun.com; mobile-ip@sunroof.eng.sun.com > >> Subject: Re: [mobile-ip] Heterogeneous Handover - How Would it Work? > >> > >> > >> >On the other hand, the home address must belong to some ISP/operator. > >> >That ISP must provide a home agent and an ip address, and a CoA when > the > >> >MN is connected to other than the home subnet. Other ISPs that are > used > >> >are only access providers, and would give the MN its CoA. This of > course > >> >would cause political problems. Who are the ISPs that are willing to > be > >> >access providers only, and who will be providing home agent and home > >> >address as well? > >> > > >> > >> This is an issue. What happens if you have one access provider on > >> one interface, say the wCDMA interface, and another on another, say > 802.11? > >> There are now in the US a growing number of 802.11 access providers, > >> and I can imagine someone with a laptop having a wCDMA modem and > >> an 802.11 card. > >> > >> Maybe something like the "roaming consortia" that have sprung up > >> around ISP access might evolve, but the protocol design/engineering > >> issue is whether there is any additional work (such as the NAI in > >> the roaming consortia example) needed to enable sharing of a home > >> address among interfaces for which different ISPs are responsible. > >> > >> Something like SUCV, that would allow an ISP to cryptographically > identify > >> to what other ISP an address belonged, might be useful in this context. > >> > >> jak From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 8 14:55:12 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19266 for ; Wed, 8 Aug 2001 14:55:11 -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 MAA19855; Wed, 8 Aug 2001 12:55: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 LAA07186; Wed, 8 Aug 2001 11:55:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f78IsBC16919 for mobile-ip-dist; Wed, 8 Aug 2001 11:54:11 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f78Is8D16912 for ; Wed, 8 Aug 2001 11:54:08 -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 LAA07008 for ; Wed, 8 Aug 2001 11:54:14 -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 LAA14746 for ; Wed, 8 Aug 2001 11:54:13 -0700 (PDT) Received: from mail.verizonwireless.com by mail.verizonwireless.com (414/1100) with ESMTP id f78Igwh24279 for ; Wed, 8 Aug 2001 14:42:58 -0400 (EDT) Received: by cairvexsmtp01.idc.vzwcorp.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Aug 2001 11:53:31 -0700 Message-ID: From: "Dahl, Peter" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Heterogeneous Handover - How Would it Work? Date: Wed, 8 Aug 2001 11:53:29 -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: ...not forgetting cdma2000. I am not aware of any work in 3GPP2 or IEEE, perhaps 3GPP ? Pete -----Original Message----- From: Brad Casemore [mailto:bcasemore@home.com] Sent: Wednesday, August 08, 2001 11:29 AM To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Heterogeneous Handover - How Would it Work? If that is the case, then WECA's WISPr is dedicated to 802.11b roaming, while the ETSI has assigned a group to address GPRS roaming. Is there a group anywhere that is looking into the technical issues associated with heterogeneous network roaming (such as between, theoretically, 802.11b WLANs and GPRS)? Brad > -----Original Message----- > From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile- > ip@sunroof.eng.sun.com] On Behalf Of James Kempf > Sent: Wednesday, August 08, 2001 2:19 AM > To: mobile-ip@sunroof.eng.sun.com; mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Heterogeneous Handover - How Would it Work? > > Pat, > > I think they already have such a standard and I believe it only works > with GPRS. > > jak > > >Also, I believe that ETSI is working on a standard called GRX for GSM<- > >802.11 > >roaming. > > > >PatC > >On Tue, Aug 07, 2001 at 09:32:58AM -0700, Dahl, Peter wrote: > >> FYI, the Wireless ISPs (WISPs) are already talking about such roaming > >> issues. > >> > >> There appear to be 2 emerging forums for these discussions, one under > the > >> auspices of WECA (http://www.weca.net) known as the WISPr group ('r' > being > >> for roaming), the other a yet to be finalized 'WISP Forum' the prime > mover > >> for which is a company in Luxembourg (www.excilan.com). > >> > >> Regards > >> > >> -----Original Message----- > >> From: James Kempf [mailto:James.Kempf@Sun.COM] > >> Sent: Tuesday, August 07, 2001 8:58 AM > >> To: mobile-ip@sunroof.eng.sun.com; mobile-ip@sunroof.eng.sun.com > >> Subject: Re: [mobile-ip] Heterogeneous Handover - How Would it Work? > >> > >> > >> >On the other hand, the home address must belong to some ISP/operator. > >> >That ISP must provide a home agent and an ip address, and a CoA when > the > >> >MN is connected to other than the home subnet. Other ISPs that are > used > >> >are only access providers, and would give the MN its CoA. This of > course > >> >would cause political problems. Who are the ISPs that are willing to > be > >> >access providers only, and who will be providing home agent and home > >> >address as well? > >> > > >> > >> This is an issue. What happens if you have one access provider on > >> one interface, say the wCDMA interface, and another on another, say > 802.11? > >> There are now in the US a growing number of 802.11 access providers, > >> and I can imagine someone with a laptop having a wCDMA modem and > >> an 802.11 card. > >> > >> Maybe something like the "roaming consortia" that have sprung up > >> around ISP access might evolve, but the protocol design/engineering > >> issue is whether there is any additional work (such as the NAI in > >> the roaming consortia example) needed to enable sharing of a home > >> address among interfaces for which different ISPs are responsible. > >> > >> Something like SUCV, that would allow an ISP to cryptographically > identify > >> to what other ISP an address belonged, might be useful in this context. > >> > >> jak From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 8 17:51:03 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22203 for ; Wed, 8 Aug 2001 17:51: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 PAA12777; Wed, 8 Aug 2001 15:51: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 OAA20501; Wed, 8 Aug 2001 14:51:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f78Lo4U17491 for mobile-ip-dist; Wed, 8 Aug 2001 14:50:04 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f78Lo0D17484 for ; Wed, 8 Aug 2001 14:50:00 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA18886 for ; Wed, 8 Aug 2001 14:50:07 -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 PAA26757 for ; Wed, 8 Aug 2001 15:50:08 -0600 (MDT) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f78LnxN22473 for ; Wed, 8 Aug 2001 23:50:00 +0200 (MEST) Received: from era-t.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id XAA01071; Wed, 8 Aug 2001 23:49:58 +0200 Message-ID: <3B71B27C.6D349553@era-t.ericsson.se> Date: Wed, 08 Aug 2001 23:43:24 +0200 From: georg chambert X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] A question about 'traceroute' References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hii, would just like to pose a question; in my understanding this means that there are easy means to get knowledge of the visited location (ie the FA / coloc) of the MN, by just anyone interrested. Could that not be regarded a potential security hazard for&by the moving individual, i.e. the carrier of the MN? Rgds georg alper wrote: > run "traceroute mn" > > this gives you "ha" and "fa_or_colocated_coa." (look at last two hops before > mn) > > now run "traceroute -g ha fa_or_colocated_coa" (-g adds a LSRR to the > probing > packet that has to go through the specified gateway) > > now you see what makes up the tunnel. > > alper > > -----Original Message----- > From: owner-mobile-ip@sunroof.eng.sun.com > [mailto:owner-mobile-ip@sunroof.eng.sun.com]On Behalf Of Kim Taeyong > Sent: 07 A©£ustos 2001 Saly 16:32 > To: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] A question about 'traceroute' > > I think traceroute program can work with Mobile IP but it can not trace > tunneling section. > > I think. I do not expriments with mobile IP. From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 8 20:33:23 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24268 for ; Wed, 8 Aug 2001 20:33: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 RAA00387; Wed, 8 Aug 2001 17:34: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 RAA17590; Wed, 8 Aug 2001 17:33:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f790Wa818198 for mobile-ip-dist; Wed, 8 Aug 2001 17:32:36 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f790WXD18191 for ; Wed, 8 Aug 2001 17:32:33 -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 RAA17348 for ; Wed, 8 Aug 2001 17:32:39 -0700 (PDT) Received: from telecom.samsung.co.kr ([165.213.221.4]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA20176 for ; Wed, 8 Aug 2001 17:32:37 -0700 (PDT) Received: from cychong (a22416 [165.213.224.16]) by telecom.samsung.co.kr (8.9.3/8.9.3) with SMTP id JAA27552 for ; Thu, 9 Aug 2001 09:35:15 +0900 (KST) Message-ID: <000801c1206b$564ed140$10e0d5a5@cychong> From: "Chae-yong Chong" To: References: <3B71B27C.6D349553@era-t.ericsson.se> Subject: Re: [mobile-ip] A question about 'traceroute' Date: Thu, 9 Aug 2001 09:36:30 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.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 f790WXD18192 Sender: owner-mobile-ip@sunroof.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 do not know why the location of MN has any security vulnerability. If a location of some node could be that, why not prohibit sending "ICMP TTL exceed" message from FA. I think the location itself does not give any information. Regards Chae-yong ----- Original Message ----- From: "georg chambert" To: Sent: Thursday, August 09, 2001 6:43 AM Subject: Re: [mobile-ip] A question about 'traceroute' > Hii, would just like to pose a question; > in my understanding this means that there are easy means > to get knowledge of the visited location (ie the FA / coloc) > of the MN, by just anyone interrested. > Could that not be regarded a potential security hazard for&by the moving > individual, i.e. the carrier of the MN? > Rgds > georg > > alper wrote: > > > run "traceroute mn" > > > > this gives you "ha" and "fa_or_colocated_coa." (look at last two hops before > > mn) > > > > now run "traceroute -g ha fa_or_colocated_coa" (-g adds a LSRR to the > > probing > > packet that has to go through the specified gateway) > > > > now you see what makes up the tunnel. > > > > alper > > > > -----Original Message----- > > From: owner-mobile-ip@sunroof.eng.sun.com > > [mailto:owner-mobile-ip@sunroof.eng.sun.com]On Behalf Of Kim Taeyong > > Sent: 07 A©£ustos 2001 Saly 16:32 > > To: mobile-ip@sunroof.eng.sun.com > > Subject: Re: [mobile-ip] A question about 'traceroute' > > > > I think traceroute program can work with Mobile IP but it can not trace > > tunneling section. > > > > I think. I do not expriments with mobile IP. > > From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 8 20:50:42 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24521 for ; Wed, 8 Aug 2001 20:50: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 RAA05162; Wed, 8 Aug 2001 17:51: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 RAA20237; Wed, 8 Aug 2001 17:51:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f790nv218305 for mobile-ip-dist; Wed, 8 Aug 2001 17:49:57 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.83.130] (may be forged)) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f790nrD18298 for ; Wed, 8 Aug 2001 17:49:53 -0700 (PDT) Received: from emirgan (vpn-129-150-4-124.EBay.Sun.COM [129.150.4.124]) by jurassic.eng.sun.com (8.11.5+Sun/8.11.5) with SMTP id f790nfB397860 for ; Wed, 8 Aug 2001 17:49:42 -0700 (PDT) From: "alper" To: Subject: RE: [mobile-ip] A question about 'traceroute' Date: Wed, 8 Aug 2001 17:49:54 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: <000801c1206b$564ed140$10e0d5a5@cychong> Sender: owner-mobile-ip@sunroof.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 problem is at least "privacy". If they know your care-of address, and if they know which care-of address maps to which geographical area (they can at least figure this out by going around in town), they can know where you are.... and people don't want that. And losing privacy can be exploited for security attacks. Yes, you can configure your router (FA) not to respond with time exceeded, and your host (mn) with port unreachable, echo reply... alper -----Original Message----- From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile-ip@sunroof.eng.sun.com]On Behalf Of Chae-yong Chong Sent: 08 Aðustos 2001 Çarþamba 17:37 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] A question about 'traceroute' Hi.. I do not know why the location of MN has any security vulnerability. If a location of some node could be that, why not prohibit sending "ICMP TTL exceed" message from FA. I think the location itself does not give any information. Regards Chae-yong ----- Original Message ----- From: "georg chambert" To: Sent: Thursday, August 09, 2001 6:43 AM Subject: Re: [mobile-ip] A question about 'traceroute' > Hii, would just like to pose a question; > in my understanding this means that there are easy means > to get knowledge of the visited location (ie the FA / coloc) > of the MN, by just anyone interrested. > Could that not be regarded a potential security hazard for&by the moving > individual, i.e. the carrier of the MN? > Rgds > georg > > alper wrote: > > > run "traceroute mn" > > > > this gives you "ha" and "fa_or_colocated_coa." (look at last two hops before > > mn) > > > > now run "traceroute -g ha fa_or_colocated_coa" (-g adds a LSRR to the > > probing > > packet that has to go through the specified gateway) > > > > now you see what makes up the tunnel. > > > > alper > > > > -----Original Message----- > > From: owner-mobile-ip@sunroof.eng.sun.com > > [mailto:owner-mobile-ip@sunroof.eng.sun.com]On Behalf Of Kim Taeyong > > Sent: 07 A©£ustos 2001 Saly 16:32 > > To: mobile-ip@sunroof.eng.sun.com > > Subject: Re: [mobile-ip] A question about 'traceroute' > > > > I think traceroute program can work with Mobile IP but it can not trace > > tunneling section. > > > > I think. I do not expriments with mobile IP. > > From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 8 21:07:54 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24732 for ; Wed, 8 Aug 2001 21:07: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 TAA02645; Wed, 8 Aug 2001 19:08: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 SAA22622; Wed, 8 Aug 2001 18:08:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f79177h18413 for mobile-ip-dist; Wed, 8 Aug 2001 18:07:07 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f79174D18406 for ; Wed, 8 Aug 2001 18:07: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 SAA29221 for ; Wed, 8 Aug 2001 18:07:11 -0700 (PDT) Received: from telecom.samsung.co.kr ([165.213.221.4]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA06861 for ; Wed, 8 Aug 2001 18:07:09 -0700 (PDT) Received: from cychong (a22416 [165.213.224.16]) by telecom.samsung.co.kr (8.9.3/8.9.3) with SMTP id KAA30462 for ; Thu, 9 Aug 2001 10:09:47 +0900 (KST) Message-ID: <000401c12070$29346490$10e0d5a5@cychong> From: "Chae-yong Chong" To: References: Subject: Re: [mobile-ip] A question about 'traceroute' Date: Thu, 9 Aug 2001 10:11:03 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.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 f79174D18407 Sender: owner-mobile-ip@sunroof.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 Does that geographic area information is applied to any IP network? Why geographic are information should be considered for Mobile Node specially? If MN want to have some "privacy", it should use Private Address with Mobile IP. ----- Original Message ----- From: "alper" To: Sent: Thursday, August 09, 2001 9:49 AM Subject: RE: [mobile-ip] A question about 'traceroute' > The problem is at least "privacy". If they know your care-of address, > and if they know which care-of address maps to which geographical area > (they can at least figure this out by going around in town), they > can know where you are.... and people don't want that. > > And losing privacy can be exploited for security attacks. > > Yes, you can configure your router (FA) not to respond with > time exceeded, and your host (mn) with port unreachable, echo > reply... > > alper > > -----Original Message----- > From: owner-mobile-ip@sunroof.eng.sun.com > [mailto:owner-mobile-ip@sunroof.eng.sun.com]On Behalf Of Chae-yong Chong > Sent: 08 Aðustos 2001 Çarþamba 17:37 > To: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] A question about 'traceroute' > > > Hi.. > > I do not know why the location of MN has any security vulnerability. > If a location of some node could be that, why not prohibit sending > "ICMP TTL exceed" message from FA. > I think the location itself does not give any information. > > Regards > Chae-yong > > > > ----- Original Message ----- > From: "georg chambert" > To: > Sent: Thursday, August 09, 2001 6:43 AM > Subject: Re: [mobile-ip] A question about 'traceroute' > > > > Hii, would just like to pose a question; > > in my understanding this means that there are easy means > > to get knowledge of the visited location (ie the FA / coloc) > > of the MN, by just anyone interrested. > > Could that not be regarded a potential security hazard for&by the moving > > individual, i.e. the carrier of the MN? > > Rgds > > georg > > > > alper wrote: > > > > > run "traceroute mn" > > > > > > this gives you "ha" and "fa_or_colocated_coa." (look at last two hops > before > > > mn) > > > > > > now run "traceroute -g ha fa_or_colocated_coa" (-g adds a LSRR to the > > > probing > > > packet that has to go through the specified gateway) > > > > > > now you see what makes up the tunnel. > > > > > > alper > > > > > > -----Original Message----- > > > From: owner-mobile-ip@sunroof.eng.sun.com > > > [mailto:owner-mobile-ip@sunroof.eng.sun.com]On Behalf Of Kim Taeyong > > > Sent: 07 A©£ustos 2001 Saly 16:32 > > > To: mobile-ip@sunroof.eng.sun.com > > > Subject: Re: [mobile-ip] A question about 'traceroute' > > > > > > I think traceroute program can work with Mobile IP but it can not trace > > > tunneling section. > > > > > > I think. I do not expriments with mobile IP. > > > > > > From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 9 03:46:17 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16647 for ; Thu, 9 Aug 2001 03:46: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 BAA20182; Thu, 9 Aug 2001 01:47: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 AAA26252; Thu, 9 Aug 2001 00:46:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f797iJg19167 for mobile-ip-dist; Thu, 9 Aug 2001 00:44: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+Sun/8.11.5) with ESMTP id f797iGD19160 for ; Thu, 9 Aug 2001 00:44:16 -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 AAA01130; Thu, 9 Aug 2001 00:44:18 -0700 (PDT) From: James Kempf Message-Id: <200108090744.AAA01130@heliopolis.eng.sun.com> Date: Thu, 9 Aug 2001 00:43:43 -0700 To: , Subject: RE: [mobile-ip] Heterogeneous Handover - How Would it Work? 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 Brad, As far as I know, this is not being addressed. There was some discussion awhile back about forming a Mobile IP trade group to address interoperability issues associated with roaming, but nothing came of it. Perhaps it would be an appropriate topic for a WG in the OPS area of IETF? jak >If that is the case, then WECA's WISPr is dedicated to 802.11b roaming, >while the ETSI has assigned a group to address GPRS roaming. Is there a >group anywhere that is looking into the technical issues associated with >heterogeneous network roaming (such as between, theoretically, 802.11b >WLANs and GPRS)? > >Brad > >> -----Original Message----- >> From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile- >> ip@sunroof.eng.sun.com] On Behalf Of James Kempf >> Sent: Wednesday, August 08, 2001 2:19 AM >> To: mobile-ip@sunroof.eng.sun.com; mobile-ip@sunroof.eng.sun.com >> Subject: Re: [mobile-ip] Heterogeneous Handover - How Would it Work? >> >> Pat, >> >> I think they already have such a standard and I believe it only works >> with GPRS. >> >> jak >> >> >Also, I believe that ETSI is working on a standard called GRX for >GSM<- >> >802.11 >> >roaming. >> > >> >PatC >> >On Tue, Aug 07, 2001 at 09:32:58AM -0700, Dahl, Peter wrote: >> >> FYI, the Wireless ISPs (WISPs) are already talking about such >roaming >> >> issues. >> >> >> >> There appear to be 2 emerging forums for these discussions, one >under >> the >> >> auspices of WECA (http://www.weca.net) known as the WISPr group >('r' >> being >> >> for roaming), the other a yet to be finalized 'WISP Forum' the >prime >> mover >> >> for which is a company in Luxembourg (www.excilan.com). >> >> >> >> Regards >> >> >> >> -----Original Message----- >> >> From: James Kempf [mailto:James.Kempf@Sun.COM] >> >> Sent: Tuesday, August 07, 2001 8:58 AM >> >> To: mobile-ip@sunroof.eng.sun.com; mobile-ip@sunroof.eng.sun.com >> >> Subject: Re: [mobile-ip] Heterogeneous Handover - How Would it >Work? >> >> >> >> >> >> >On the other hand, the home address must belong to some >ISP/operator. >> >> >That ISP must provide a home agent and an ip address, and a CoA >when >> the >> >> >MN is connected to other than the home subnet. Other ISPs that are >> used >> >> >are only access providers, and would give the MN its CoA. This of >> course >> >> >would cause political problems. Who are the ISPs that are willing >to >> be >> >> >access providers only, and who will be providing home agent and >home >> >> >address as well? >> >> > >> >> >> >> This is an issue. What happens if you have one access provider on >> >> one interface, say the wCDMA interface, and another on another, say >> 802.11? >> >> There are now in the US a growing number of 802.11 access >providers, >> >> and I can imagine someone with a laptop having a wCDMA modem and >> >> an 802.11 card. >> >> >> >> Maybe something like the "roaming consortia" that have sprung up >> >> around ISP access might evolve, but the protocol design/engineering >> >> issue is whether there is any additional work (such as the NAI in >> >> the roaming consortia example) needed to enable sharing of a home >> >> address among interfaces for which different ISPs are responsible. >> >> >> >> Something like SUCV, that would allow an ISP to cryptographically >> identify >> >> to what other ISP an address belonged, might be useful in this >context. >> >> >> >> jak > > From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 9 05:54:00 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19416 for ; Thu, 9 Aug 2001 05:54: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 DAA05884; Thu, 9 Aug 2001 03:54: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 CAA07294; Thu, 9 Aug 2001 02:54:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f799qpc19934 for mobile-ip-dist; Thu, 9 Aug 2001 02:52:51 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f799qmD19927 for ; Thu, 9 Aug 2001 02:52: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 CAA18737 for ; Thu, 9 Aug 2001 02:52:56 -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 CAA10991 for ; Thu, 9 Aug 2001 02:52:55 -0700 (PDT) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f799qrN09325 for ; Thu, 9 Aug 2001 11:52:54 +0200 (MEST) Received: from era-t.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id LAA16399; Thu, 9 Aug 2001 11:52:41 +0200 Message-ID: <3B725B6D.7F1A1E84@era-t.ericsson.se> Date: Thu, 09 Aug 2001 11:44:13 +0200 From: georg chambert X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] A question about 'traceroute' References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Yes, this is the kind of problems I'm thinking of. If I understand correct what you say, then; you can as a MN owner depend on (or select) access network operators that are setting up their FA not to respond, and so be safe that no address information revealing anything about location is possible to retrieve. Tnx for your answers & Rgrds Georg alper wrote: > The problem is at least "privacy". If they know your care-of address, > and if they know which care-of address maps to which geographical area > (they can at least figure this out by going around in town), they > can know where you are.... and people don't want that. > > And losing privacy can be exploited for security attacks. > > Yes, you can configure your router (FA) not to respond with > time exceeded, and your host (mn) with port unreachable, echo > reply... > > alper > > -----Original Message----- > From: owner-mobile-ip@sunroof.eng.sun.com > [mailto:owner-mobile-ip@sunroof.eng.sun.com]On Behalf Of Chae-yong Chong > Sent: 08 Aðustos 2001 Çarþamba 17:37 > To: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] A question about 'traceroute' > > Hi.. > > I do not know why the location of MN has any security vulnerability. > If a location of some node could be that, why not prohibit sending > "ICMP TTL exceed" message from FA. > I think the location itself does not give any information. > > Regards > Chae-yong > > ----- Original Message ----- > From: "georg chambert" > To: > Sent: Thursday, August 09, 2001 6:43 AM > Subject: Re: [mobile-ip] A question about 'traceroute' > > > Hii, would just like to pose a question; > > in my understanding this means that there are easy means > > to get knowledge of the visited location (ie the FA / coloc) > > of the MN, by just anyone interrested. > > Could that not be regarded a potential security hazard for&by the moving > > individual, i.e. the carrier of the MN? > > Rgds > > georg > > > > alper wrote: > > > > > run "traceroute mn" > > > > > > this gives you "ha" and "fa_or_colocated_coa." (look at last two hops > before > > > mn) > > > > > > now run "traceroute -g ha fa_or_colocated_coa" (-g adds a LSRR to the > > > probing > > > packet that has to go through the specified gateway) > > > > > > now you see what makes up the tunnel. > > > > > > alper > > > > > > -----Original Message----- > > > From: owner-mobile-ip@sunroof.eng.sun.com > > > [mailto:owner-mobile-ip@sunroof.eng.sun.com]On Behalf Of Kim Taeyong > > > Sent: 07 A©£ustos 2001 Saly 16:32 > > > To: mobile-ip@sunroof.eng.sun.com > > > Subject: Re: [mobile-ip] A question about 'traceroute' > > > > > > I think traceroute program can work with Mobile IP but it can not trace > > > tunneling section. > > > > > > I think. I do not expriments with mobile IP. > > > > From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 9 06:31:11 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20278 for ; Thu, 9 Aug 2001 06:31: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 EAA25699; Thu, 9 Aug 2001 04:32: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 DAA21443; Thu, 9 Aug 2001 03:31:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f79AUsl20117 for mobile-ip-dist; Thu, 9 Aug 2001 03:30:54 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f79AUpD20110 for ; Thu, 9 Aug 2001 03:30: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 DAA15559 for ; Thu, 9 Aug 2001 03:30:56 -0700 (PDT) Received: from elchara.qualcomm.com (elchara.qualcomm.com [129.46.216.81]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA16898 for ; Thu, 9 Aug 2001 04:30:52 -0600 (MDT) Received: from MLIOY2K.qualcomm.com (vpnap-g1-012006.qualcomm.com [10.13.12.6]) by elchara.qualcomm.com (8.8.5/1.4/8.7.2/1.12) with ESMTP id DAA12814; Thu, 9 Aug 2001 03:30:42 -0700 (PDT) Message-Id: <4.3.1.2.20010809104257.03043348@mail1.qualcomm.com> X-Sender: mlioy@mail1.qualcomm.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Thu, 09 Aug 2001 10:43:46 +0100 To: mobile-ip@sunroof.eng.sun.com, "'mobile-ip@sunroof.eng.sun.com'" From: Marcello Lioy Subject: Re: [mobile-ip] TSB-115 copy ? 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 12:03 AM 6/15/2001, Zhao Xiaoming-CXZ004 wrote: >Hi, > >I could not find TSB-115 "Wireless IP Architecture Based on IETF >Protocols". By chance anybody have a copy could send one to me? Thanks. I believe that these documents need to be purchased - they are not freely distributable. -------------------- Marcello (in London) From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 9 06:48:34 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20592 for ; Thu, 9 Aug 2001 06:48: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 EAA05188; Thu, 9 Aug 2001 04:49: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 DAA22480; Thu, 9 Aug 2001 03:49:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f79AmOr20198 for mobile-ip-dist; Thu, 9 Aug 2001 03:48:24 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f79AmKD20191 for ; Thu, 9 Aug 2001 03:48: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 DAA19031 for ; Thu, 9 Aug 2001 03:48:25 -0700 (PDT) Received: from mail.cambianetworks.com (osh200-140.onshore.com [66.54.200.140] (may be forged)) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA26028 for ; Thu, 9 Aug 2001 03:48:24 -0700 (PDT) Received: by mail.cambianetworks.com (Postfix, from userid 1063) id 096EB8AE8C; Thu, 9 Aug 2001 05:38:54 -0500 (CDT) Received: from USAROSRMARKS1 (ho01-24-131-134-27.ce.mediaone.net [24.131.134.27]) by mail.cambianetworks.com (Postfix) with ESMTP id 21D77B298A for ; Thu, 9 Aug 2001 05:38:53 -0500 (CDT) From: "Robert J Marks" To: Subject: RE: [mobile-ip] TSB-115 copy ? Date: Thu, 9 Aug 2001 05:44:54 -0500 Organization: Cambia Networks Message-ID: <000001c120c0$53347140$6700a8c0@cambianetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <4.3.1.2.20010809104257.03043348@mail1.qualcomm.com> X-Virus-Scanned: by AMaViS perl-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: Content-Transfer-Encoding: 7bit The 3GPP2 version, P.R0001, is available freely at http://www.3gpp2.org by following "Specifications" then "TSG-P Specifications". The versions are identical in substance, and may differ only in reference identification, as TSG-115 is a TIA document that may use TIA references, and P.R0001 is a 3GPP2 specification that may use 3GPP2 references. Bob Robert J Marks Cambia Networks Office: +1 847 993 3028 Mobile: +1 708 829 6329 -----Original Message----- From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile-ip@sunroof.eng.sun.com] On Behalf Of Marcello Lioy Sent: Thursday, August 09, 2001 4:44 AM To: mobile-ip@sunroof.eng.sun.com; 'mobile-ip@sunroof.eng.sun.com' Subject: Re: [mobile-ip] TSB-115 copy ? At 12:03 AM 6/15/2001, Zhao Xiaoming-CXZ004 wrote: >Hi, > >I could not find TSB-115 "Wireless IP Architecture Based on IETF >Protocols". By chance anybody have a copy could send one to me? Thanks. I believe that these documents need to be purchased - they are not freely distributable. -------------------- Marcello (in London) From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 9 10:34:06 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25308 for ; Thu, 9 Aug 2001 10:34: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 HAA23397; Thu, 9 Aug 2001 07:34: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 HAA01663; Thu, 9 Aug 2001 07:33:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f79EW0T20724 for mobile-ip-dist; Thu, 9 Aug 2001 07:32:00 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f79EVuD20717 for ; Thu, 9 Aug 2001 07:31: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 HAA09239 for ; Thu, 9 Aug 2001 07:32:01 -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 HAA28331 for ; Thu, 9 Aug 2001 07:32:01 -0700 (PDT) Received: from dragon.ee.vt.edu (dragon.ee.vt.edu [128.173.88.137]) by birch.ee.vt.edu (8.9.3/8.9.3) with ESMTP id KAA01648 for ; Thu, 9 Aug 2001 10:32:00 -0400 (EDT) Received: (from wells@localhost) by dragon.ee.vt.edu (8.10.2+Sun/8.10.2) id f79EVxH08241 for mobile-ip@sunroof.eng.sun.com; Thu, 9 Aug 2001 10:31:59 -0400 (EDT) Date: Thu, 9 Aug 2001 10:31:59 -0400 From: John Wells To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] A question about 'traceroute' Message-ID: <20010809103159.C8179@horus.imag.fr> References: <000801c1206b$564ed140$10e0d5a5@cychong> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="eRtJSFbw+EEWtPj3" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from alper.yegin@sun.com on Wed, Aug 08, 2001 at 05:49:54PM -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: --eRtJSFbw+EEWtPj3 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Alper, It's a pretty difficult problem. HMIP is one way of solving it, in that it hides the CoA within a site, but isn't ideal, since correspondent nodes and observers know it's within a site. I tried to come up with a better solution (see http://www.ee.vt.edu/~wells), but the problem is that to hide the address for two-way live communication, there must be an intermediary to hide the address. Essentially, I made this intermediary like a MAP in basic mode, and forced two way tunnelling, so the client (which acts like an HMIP mobile node) only communicates with this address bound at the intermediary, hopefully not giving any location information. It seems a bit heavyweight which is why I haven't written a draft on it. Has anyone else done any work on lightweight location privacy in v6? I could only find heavyweight solutions requiring special changes in lots of machines, sometimes including intermediate routers. john On Wed, Aug 08, 2001 at 05:49:54PM -0700, alper wrote: > The problem is at least "privacy". If they know your care-of address, > and if they know which care-of address maps to which geographical area > (they can at least figure this out by going around in town), they > can know where you are.... and people don't want that. >=20 > And losing privacy can be exploited for security attacks. >=20 > Yes, you can configure your router (FA) not to respond with > time exceeded, and your host (mn) with port unreachable, echo > reply... >=20 > alper >=20 > -----Original Message----- > From: owner-mobile-ip@sunroof.eng.sun.com > [mailto:owner-mobile-ip@sunroof.eng.sun.com]On Behalf Of Chae-yong Chong > Sent: 08 A=F0ustos 2001 =C7ar=FEamba 17:37 > To: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] A question about 'traceroute' >=20 >=20 > Hi.. >=20 > I do not know why the location of MN has any security vulnerability. > If a location of some node could be that, why not prohibit sending > "ICMP TTL exceed" message from FA. > I think the location itself does not give any information. >=20 > Regards > Chae-yong >=20 >=20 >=20 > ----- Original Message ----- > From: "georg chambert" > To: > Sent: Thursday, August 09, 2001 6:43 AM > Subject: Re: [mobile-ip] A question about 'traceroute' >=20 >=20 > > Hii, would just like to pose a question; > > in my understanding this means that there are easy means > > to get knowledge of the visited location (ie the FA / coloc) > > of the MN, by just anyone interrested. > > Could that not be regarded a potential security hazard for&by the moving > > individual, i.e. the carrier of the MN? > > Rgds > > georg > > > > alper wrote: > > > > > run "traceroute mn" > > > > > > this gives you "ha" and "fa_or_colocated_coa." (look at last two hops > before > > > mn) > > > > > > now run "traceroute -g ha fa_or_colocated_coa" (-g adds a LSRR to the > > > probing > > > packet that has to go through the specified gateway) > > > > > > now you see what makes up the tunnel. > > > > > > alper > > > > > > -----Original Message----- > > > From: owner-mobile-ip@sunroof.eng.sun.com > > > [mailto:owner-mobile-ip@sunroof.eng.sun.com]On Behalf Of Kim Taeyong > > > Sent: 07 A=A9=A3ustos 2001 Saly 16:32 > > > To: mobile-ip@sunroof.eng.sun.com > > > Subject: Re: [mobile-ip] A question about 'traceroute' > > > > > > I think traceroute program can work with Mobile IP but it can not tra= ce > > > tunneling section. > > > > > > I think. I do not expriments with mobile IP. > > > > --=20 John WELLS Virginia Tech Networking and Visualization Lab PGP Public key: http://www.ee.vt.edu/~wells/pgpkey.txt --eRtJSFbw+EEWtPj3 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 iD8DBQE7cp7etvPFKAfa3SIRAqf4AJ9+e85LehK7o1gs0hQJzgsqdu4WFgCeJFd7 RUZkmMFPJ+vr4aXq040Yvms= =xATi -----END PGP SIGNATURE----- --eRtJSFbw+EEWtPj3-- From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 9 10:38:32 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25458 for ; Thu, 9 Aug 2001 10:38:32 -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 IAA00675; Thu, 9 Aug 2001 08:39: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 HAA02585; Thu, 9 Aug 2001 07:39:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f79EbW320768 for mobile-ip-dist; Thu, 9 Aug 2001 07:37:32 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f79EbTD20761 for ; Thu, 9 Aug 2001 07:37: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 HAA10014 for ; Thu, 9 Aug 2001 07:37:29 -0700 (PDT) Received: from birch.ee.vt.edu (birch.ee.vt.edu [128.173.88.34]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA29290 for ; Thu, 9 Aug 2001 08:37:26 -0600 (MDT) Received: from dragon.ee.vt.edu (dragon.ee.vt.edu [128.173.88.137]) by birch.ee.vt.edu (8.9.3/8.9.3) with ESMTP id KAA01693 for ; Thu, 9 Aug 2001 10:37:27 -0400 (EDT) Received: (from wells@localhost) by dragon.ee.vt.edu (8.10.2+Sun/8.10.2) id f79EbRe08267 for mobile-ip@sunroof.eng.sun.com; Thu, 9 Aug 2001 10:37:27 -0400 (EDT) Date: Thu, 9 Aug 2001 10:37:27 -0400 From: John Wells To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] A question about 'traceroute' Message-ID: <20010809103727.D8179@horus.imag.fr> References: <000401c12070$29346490$10e0d5a5@cychong> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="d01dLTUuW90fS44H" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <000401c12070$29346490$10e0d5a5@cychong>; from cychong@telecom.samsung.co.kr on Thu, Aug 09, 2001 at 10:11:03AM +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: --d01dLTUuW90fS44H Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Chae-yong, By private addresses, do you mean RFC 3041 privacy extension for stateless autoconf addresses? The link address part (last 64 bits) change every so often, but the link itself does not change. For fixed nodes, this is probably sufficient to foil eavesdroppers, but it's not sufficient when you communicate for a long time with a correspondant node, or login to a correspondant node server. There, the CN can bind your location (the network id which cannot be hidden) with your name, address, email, or whatever info you give it. There's still the question of hiding the home address too, which is not covered in the 3041 privacy extensions. There's a draft on this: draft-castelluccia-mobileip-privacy-00.txt. john On Thu, Aug 09, 2001 at 10:11:03AM +0900, Chae-yong Chong wrote: > Hi >=20 > Does that geographic area information is applied to any IP network? > Why geographic are information should be considered for Mobile Node speci= ally? >=20 > If MN want to have some "privacy", it should use Private Address with Mob= ile IP. --=20 John WELLS Virginia Tech Networking and Visualization Lab PGP Public key: http://www.ee.vt.edu/~wells/pgpkey.txt --d01dLTUuW90fS44H 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 iD8DBQE7cqAmtvPFKAfa3SIRAh8dAJ0VlHsNv9PDz3j9MfywsaMBRKG+KwCeJdX7 K0250MzYzMo17mHDi7So5Io= =lKPp -----END PGP SIGNATURE----- --d01dLTUuW90fS44H-- From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 9 10:40:00 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25504 for ; Thu, 9 Aug 2001 10:39: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 HAA26890; Thu, 9 Aug 2001 07:40: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 HAA02649; Thu, 9 Aug 2001 07:39:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f79EcQd20777 for mobile-ip-dist; Thu, 9 Aug 2001 07:38:26 -0700 (PDT) Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.179.15]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f79EcLD20770 for ; Thu, 9 Aug 2001 07:38:21 -0700 (PDT) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f79EcK224090 for ; Thu, 9 Aug 2001 16:38:21 +0200 (MET DST) Date: Wed, 8 Aug 2001 16:02:54 +0200 (CEST) From: Erik Nordmark Subject: Re: [mobile-ip] Heterogeneous Handover - How Would it Work? To: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <200108071558.IAA06533@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: > Something like SUCV, that would allow an ISP to cryptographically identify > to what other ISP an address belonged, might be useful in this context. I didn't read the above in the SUCV draft. SUCV allows nodes to challenge the node with an SUCV address to show indicate that they have the private key corresponding to the address. This doesn't identify the ISP as far as I can tell. Or do you intend to infer the identity of the ISP from the high-order bits in the IPv6 address? Erik From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 9 11: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 ESMTP id LAA27707 for ; Thu, 9 Aug 2001 11:37:48 -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 IAA01248; Thu, 9 Aug 2001 08:38: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 IAA26995; Thu, 9 Aug 2001 08:38:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f79Fb7Z20982 for mobile-ip-dist; Thu, 9 Aug 2001 08:37:07 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f79Fb4D20975 for ; Thu, 9 Aug 2001 08:37: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 IAA11537 for ; Thu, 9 Aug 2001 08:37:09 -0700 (PDT) Received: from elchara.qualcomm.com (elchara.qualcomm.com [129.46.216.81]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA15413 for ; Thu, 9 Aug 2001 08:37:06 -0700 (PDT) Received: from MLIOY2K.qualcomm.com ([10.13.12.83]) by elchara.qualcomm.com (8.8.5/1.4/8.7.2/1.12) with ESMTP id IAA13119; Thu, 9 Aug 2001 08:36:59 -0700 (PDT) Message-Id: <4.3.1.2.20010809104356.03084c70@mail1.qualcomm.com> X-Sender: mlioy@mail1.qualcomm.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Thu, 09 Aug 2001 16:35:26 +0100 To: mobile-ip@sunroof.eng.sun.com From: Marcello Lioy Subject: [mobile-ip] Issue with 3012 Cc: "Charles E. Perkins" , jeffd@qualcomm.com, nish@qualcomm.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: There is some vague language in 3012 relating to when new challenges can be sent and when they should be used by the FA. Section 3.2. (Foreign Agent Processing for Registration Requests) states The Foreign Agent MUST NOT accept any Challenge in the Registration Request unless it was offered in last successful Registration Reply issued to the Mobile Node, or else advertised as one of the last CHALLENGE_WINDOW (see section 9) Challenge values inserted into the immediately preceding Agent advertisements. This explicitly states that the FA is NOT supposed to use challenges which are sent to mobiles in RRP failures. However, in Section 3.3. (Foreign Agent Processing for Registration Replies) it also states the following: The Foreign Agent MAY include a new Challenge extension in any Registration Reply, successful or not. which seems to imply that the mobile could use this challenge to authenticate itself. This has already caused interop problems with the mobile following the section 3.2 (i.e. ignoring the challenge in and RRP failure) and the FA following 3.3 (expecting the mobile to use a challenge in a failure). It would be good if this could be clarified to avoid problems in future. -------------------- Marcello (in London) From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 9 11:52:54 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28155 for ; Thu, 9 Aug 2001 11:52: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 IAA09526; Thu, 9 Aug 2001 08:53: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 IAA01542; Thu, 9 Aug 2001 08:53:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f79FqBw21051 for mobile-ip-dist; Thu, 9 Aug 2001 08:52:11 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f79Fq8D21044 for ; Thu, 9 Aug 2001 08:52: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 IAA01140 for ; Thu, 9 Aug 2001 08:52:14 -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 IAA24179 for ; Thu, 9 Aug 2001 08:52: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 f79FqBi28802 for ; Thu, 9 Aug 2001 10:52:11 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Thu, 9 Aug 2001 10:52:07 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.1600); Thu, 9 Aug 2001 10:52:07 -0500 content-class: urn:content-classes:message Subject: RE: [mobile-ip] Heterogeneous Handover - How Would it Work? Date: Thu, 9 Aug 2001 10:52:04 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF440861BD@daebe007.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [mobile-ip] Heterogeneous Handover - How Would it Work? X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 Thread-Index: AcEgp4hsoCvQjIyYEdWrxAAIx6S5QwAQ28cQ To: X-OriginalArrivalTime: 09 Aug 2001 15:52:07.0690 (UTC) FILETIME=[3E4076A0:01C120EB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f79Fq8D21045 Sender: owner-mobile-ip@sunroof.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 Roaming is different from performing a handoff between different access technologies. With Mobile IP you *CAN* move between different access technologies. However the issue of administrative domains and roaming agreements etc. are not in scope of this WG and I suspect this WG has no reason to address those issues. As James suggested this belons in the Ops area. -Basavaraj > > Brad, > > As far as I know, this is not being addressed. There was some > discussion > awhile back about forming a Mobile IP trade group to address > interoperability > issues associated with roaming, but nothing came of it. > > Perhaps it would be an appropriate topic for a WG in the OPS > area of IETF? > > jak > > >If that is the case, then WECA's WISPr is dedicated to > 802.11b roaming, > >while the ETSI has assigned a group to address GPRS roaming. > Is there a > >group anywhere that is looking into the technical issues > associated with > >heterogeneous network roaming (such as between, > theoretically, 802.11b > >WLANs and GPRS)? > > > >Brad > > > >> -----Original Message----- > >> From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile- > >> ip@sunroof.eng.sun.com] On Behalf Of James Kempf > >> Sent: Wednesday, August 08, 2001 2:19 AM > >> To: mobile-ip@sunroof.eng.sun.com; mobile-ip@sunroof.eng.sun.com > >> Subject: Re: [mobile-ip] Heterogeneous Handover - How > Would it Work? > >> > >> Pat, > >> > >> I think they already have such a standard and I believe it > only works > >> with GPRS. > >> > >> jak > >> > >> >Also, I believe that ETSI is working on a standard called GRX for > >GSM<- > >> >802.11 > >> >roaming. > >> > > >> >PatC > >> >On Tue, Aug 07, 2001 at 09:32:58AM -0700, Dahl, Peter wrote: > >> >> FYI, the Wireless ISPs (WISPs) are already talking about such > >roaming > >> >> issues. > >> >> > >> >> There appear to be 2 emerging forums for these discussions, one > >under > >> the > >> >> auspices of WECA (http://www.weca.net) known as the WISPr group > >('r' > >> being > >> >> for roaming), the other a yet to be finalized 'WISP Forum' the > >prime > >> mover > >> >> for which is a company in Luxembourg (www.excilan.com). > >> >> > >> >> Regards > >> >> > >> >> -----Original Message----- > >> >> From: James Kempf [mailto:James.Kempf@Sun.COM] > >> >> Sent: Tuesday, August 07, 2001 8:58 AM > >> >> To: mobile-ip@sunroof.eng.sun.com; mobile-ip@sunroof.eng.sun.com > >> >> Subject: Re: [mobile-ip] Heterogeneous Handover - How Would it > >Work? > >> >> > >> >> > >> >> >On the other hand, the home address must belong to some > >ISP/operator. > >> >> >That ISP must provide a home agent and an ip address, and a CoA > >when > >> the > >> >> >MN is connected to other than the home subnet. Other > ISPs that are > >> used > >> >> >are only access providers, and would give the MN its > CoA. This of > >> course > >> >> >would cause political problems. Who are the ISPs that > are willing > >to > >> be > >> >> >access providers only, and who will be providing home agent and > >home > >> >> >address as well? > >> >> > > >> >> > >> >> This is an issue. What happens if you have one access > provider on > >> >> one interface, say the wCDMA interface, and another on > another, say > >> 802.11? > >> >> There are now in the US a growing number of 802.11 access > >providers, > >> >> and I can imagine someone with a laptop having a wCDMA modem and > >> >> an 802.11 card. > >> >> > >> >> Maybe something like the "roaming consortia" that have sprung up > >> >> around ISP access might evolve, but the protocol > design/engineering > >> >> issue is whether there is any additional work (such as > the NAI in > >> >> the roaming consortia example) needed to enable sharing > of a home > >> >> address among interfaces for which different ISPs are > responsible. > >> >> > >> >> Something like SUCV, that would allow an ISP to > cryptographically > >> identify > >> >> to what other ISP an address belonged, might be useful in this > >context. > >> >> > >> >> jak > > > > > > From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 9 11:55:29 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28262 for ; Thu, 9 Aug 2001 11:55: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 IAA11016; Thu, 9 Aug 2001 08:56: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 IAA02446; Thu, 9 Aug 2001 08:56:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f79FtDR21096 for mobile-ip-dist; Thu, 9 Aug 2001 08:55:13 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f79Ft9D21088 for ; Thu, 9 Aug 2001 08:55:09 -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 IAA02142 for ; Thu, 9 Aug 2001 08:55: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 patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA03789 for ; Thu, 9 Aug 2001 09:55:12 -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 f79FtFi29273 for ; Thu, 9 Aug 2001 10:55:16 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Thu, 9 Aug 2001 10:55:10 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.1600); Thu, 9 Aug 2001 10:55:09 -0500 content-class: urn:content-classes:message Subject: RE: [mobile-ip] Heterogeneous Handover - How Would it Work? Date: Thu, 9 Aug 2001 10:55:06 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF440861BE@daebe007.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [mobile-ip] Heterogeneous Handover - How Would it Work? X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 Thread-Index: AcEgO8Zw6EMHkYwnEdWJUgAIx6TWpQAr8BNA To: Cc: X-OriginalArrivalTime: 09 Aug 2001 15:55:09.0942 (UTC) FILETIME=[AAE1E960:01C120EB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f79FtAD21090 Sender: owner-mobile-ip@sunroof.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 Clearly, you are mixing roaming with seamless mobility across heterogeneous access types. The Mobile IP WG does not deal with aspects related to roaming agreements between operators or administrative domains. That is NOT what this WG is about. -Basavaraj > -----Original Message----- > From: ext Dahl, Peter [mailto:Peter.Dahl@VerizonWireless.com] > Sent: Wednesday, August 08, 2001 1:53 PM > To: 'mobile-ip@sunroof.eng.sun.com' > Subject: RE: [mobile-ip] Heterogeneous Handover - How Would it Work? > > > ...not forgetting cdma2000. I am not aware of any work in > 3GPP2 or IEEE, > perhaps 3GPP ? > > Pete > > -----Original Message----- > From: Brad Casemore [mailto:bcasemore@home.com] > Sent: Wednesday, August 08, 2001 11:29 AM > To: mobile-ip@sunroof.eng.sun.com > Subject: RE: [mobile-ip] Heterogeneous Handover - How Would it Work? > > > If that is the case, then WECA's WISPr is dedicated to > 802.11b roaming, > while the ETSI has assigned a group to address GPRS roaming. > Is there a > group anywhere that is looking into the technical issues > associated with > heterogeneous network roaming (such as between, theoretically, 802.11b > WLANs and GPRS)? > > Brad > > > -----Original Message----- > > From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile- > > ip@sunroof.eng.sun.com] On Behalf Of James Kempf > > Sent: Wednesday, August 08, 2001 2:19 AM > > To: mobile-ip@sunroof.eng.sun.com; mobile-ip@sunroof.eng.sun.com > > Subject: Re: [mobile-ip] Heterogeneous Handover - How Would it Work? > > > > Pat, > > > > I think they already have such a standard and I believe it > only works > > with GPRS. > > > > jak > > > > >Also, I believe that ETSI is working on a standard called GRX for > GSM<- > > >802.11 > > >roaming. > > > > > >PatC > > >On Tue, Aug 07, 2001 at 09:32:58AM -0700, Dahl, Peter wrote: > > >> FYI, the Wireless ISPs (WISPs) are already talking about such > roaming > > >> issues. > > >> > > >> There appear to be 2 emerging forums for these discussions, one > under > > the > > >> auspices of WECA (http://www.weca.net) known as the WISPr group > ('r' > > being > > >> for roaming), the other a yet to be finalized 'WISP Forum' the > prime > > mover > > >> for which is a company in Luxembourg (www.excilan.com). > > >> > > >> Regards > > >> > > >> -----Original Message----- > > >> From: James Kempf [mailto:James.Kempf@Sun.COM] > > >> Sent: Tuesday, August 07, 2001 8:58 AM > > >> To: mobile-ip@sunroof.eng.sun.com; mobile-ip@sunroof.eng.sun.com > > >> Subject: Re: [mobile-ip] Heterogeneous Handover - How Would it > Work? > > >> > > >> > > >> >On the other hand, the home address must belong to some > ISP/operator. > > >> >That ISP must provide a home agent and an ip address, and a CoA > when > > the > > >> >MN is connected to other than the home subnet. Other > ISPs that are > > used > > >> >are only access providers, and would give the MN its > CoA. This of > > course > > >> >would cause political problems. Who are the ISPs that > are willing > to > > be > > >> >access providers only, and who will be providing home agent and > home > > >> >address as well? > > >> > > > >> > > >> This is an issue. What happens if you have one access provider on > > >> one interface, say the wCDMA interface, and another on > another, say > > 802.11? > > >> There are now in the US a growing number of 802.11 access > providers, > > >> and I can imagine someone with a laptop having a wCDMA modem and > > >> an 802.11 card. > > >> > > >> Maybe something like the "roaming consortia" that have sprung up > > >> around ISP access might evolve, but the protocol > design/engineering > > >> issue is whether there is any additional work (such as the NAI in > > >> the roaming consortia example) needed to enable sharing of a home > > >> address among interfaces for which different ISPs are > responsible. > > >> > > >> Something like SUCV, that would allow an ISP to cryptographically > > identify > > >> to what other ISP an address belonged, might be useful in this > context. > > >> > > >> jak > From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 9 16:34:49 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05037 for ; Thu, 9 Aug 2001 16:34: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 OAA02368; Thu, 9 Aug 2001 14:35: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 NAA02632; Thu, 9 Aug 2001 13:35:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f79KXoF21759 for mobile-ip-dist; Thu, 9 Aug 2001 13:33:50 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f79KXkD21752 for ; Thu, 9 Aug 2001 13:33: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 NAA04754 for ; Thu, 9 Aug 2001 13:33:52 -0700 (PDT) Received: from zcars0m9.ca.nortel.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA19628 for ; Thu, 9 Aug 2001 13:33:51 -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 f79KXE915478 for ; Thu, 9 Aug 2001 16:33:29 -0400 (EDT) Received: from zrchb200.us.nortel.com by smtprch1.nortel.com; Thu, 9 Aug 2001 15:33:58 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 9 Aug 2001 15:33:31 -0500 Message-ID: <85AA7486A2C1D411BCA20000F8073E430312FF48@crchy271.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com Cc: "Peter.Dahl" Subject: RE: [mobile-ip] Heterogeneous Handover - How Would it Work? Date: Thu, 9 Aug 2001 15:33:31 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C12112.8D95D7A0" Sender: owner-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_01C12112.8D95D7A0 Content-Type: text/plain; charset="iso-8859-1" Raj, That's like saying that BGP doesn't deal with the routing policy related to business relationships between the owners of autonomous systems. You are shoe-holing the group into only dealing with an enterprise - not the Internet. -----Original Message----- From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com] Sent: Thursday, August 09, 2001 10:55 AM To: mobile-ip Cc: Peter.Dahl Subject: RE: [mobile-ip] Heterogeneous Handover - How Would it Work? Clearly, you are mixing roaming with seamless mobility across heterogeneous access types. The Mobile IP WG does not deal with aspects related to roaming agreements between operators or administrative domains. That is NOT what this WG is about. -Basavaraj > -----Original Message----- > From: ext Dahl, Peter [mailto:Peter.Dahl@VerizonWireless.com] > Sent: Wednesday, August 08, 2001 1:53 PM > To: 'mobile-ip@sunroof.eng.sun.com' > Subject: RE: [mobile-ip] Heterogeneous Handover - How Would it Work? > > > ...not forgetting cdma2000. I am not aware of any work in > 3GPP2 or IEEE, > perhaps 3GPP ? > > Pete > > -----Original Message----- > From: Brad Casemore [mailto:bcasemore@home.com] > Sent: Wednesday, August 08, 2001 11:29 AM > To: mobile-ip@sunroof.eng.sun.com > Subject: RE: [mobile-ip] Heterogeneous Handover - How Would it Work? > > > If that is the case, then WECA's WISPr is dedicated to > 802.11b roaming, > while the ETSI has assigned a group to address GPRS roaming. > Is there a > group anywhere that is looking into the technical issues > associated with > heterogeneous network roaming (such as between, theoretically, 802.11b > WLANs and GPRS)? > > Brad > > > -----Original Message----- > > From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile- > > ip@sunroof.eng.sun.com] On Behalf Of James Kempf > > Sent: Wednesday, August 08, 2001 2:19 AM > > To: mobile-ip@sunroof.eng.sun.com; mobile-ip@sunroof.eng.sun.com > > Subject: Re: [mobile-ip] Heterogeneous Handover - How Would it Work? > > > > Pat, > > > > I think they already have such a standard and I believe it > only works > > with GPRS. > > > > jak > > > > >Also, I believe that ETSI is working on a standard called GRX for > GSM<- > > >802.11 > > >roaming. > > > > > >PatC > > >On Tue, Aug 07, 2001 at 09:32:58AM -0700, Dahl, Peter wrote: > > >> FYI, the Wireless ISPs (WISPs) are already talking about such > roaming > > >> issues. > > >> > > >> There appear to be 2 emerging forums for these discussions, one > under > > the > > >> auspices of WECA (http://www.weca.net) known as the WISPr group > ('r' > > being > > >> for roaming), the other a yet to be finalized 'WISP Forum' the > prime > > mover > > >> for which is a company in Luxembourg (www.excilan.com). > > >> > > >> Regards > > >> > > >> -----Original Message----- > > >> From: James Kempf [mailto:James.Kempf@Sun.COM] > > >> Sent: Tuesday, August 07, 2001 8:58 AM > > >> To: mobile-ip@sunroof.eng.sun.com; mobile-ip@sunroof.eng.sun.com > > >> Subject: Re: [mobile-ip] Heterogeneous Handover - How Would it > Work? > > >> > > >> > > >> >On the other hand, the home address must belong to some > ISP/operator. > > >> >That ISP must provide a home agent and an ip address, and a CoA > when > > the > > >> >MN is connected to other than the home subnet. Other > ISPs that are > > used > > >> >are only access providers, and would give the MN its > CoA. This of > > course > > >> >would cause political problems. Who are the ISPs that > are willing > to > > be > > >> >access providers only, and who will be providing home agent and > home > > >> >address as well? > > >> > > > >> > > >> This is an issue. What happens if you have one access provider on > > >> one interface, say the wCDMA interface, and another on > another, say > > 802.11? > > >> There are now in the US a growing number of 802.11 access > providers, > > >> and I can imagine someone with a laptop having a wCDMA modem and > > >> an 802.11 card. > > >> > > >> Maybe something like the "roaming consortia" that have sprung up > > >> around ISP access might evolve, but the protocol > design/engineering > > >> issue is whether there is any additional work (such as the NAI in > > >> the roaming consortia example) needed to enable sharing of a home > > >> address among interfaces for which different ISPs are > responsible. > > >> > > >> Something like SUCV, that would allow an ISP to cryptographically > > identify > > >> to what other ISP an address belonged, might be useful in this > context. > > >> > > >> jak > ------_=_NextPart_001_01C12112.8D95D7A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Heterogeneous Handover - How Would it = Work?

Raj,

That's like saying that BGP doesn't deal with the = routing policy related to business relationships between the owners of = autonomous systems. You are shoe-holing the group into only dealing = with an enterprise - not the Internet.

-----Original Message-----
From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.c= om]
Sent: Thursday, August 09, 2001 10:55 AM
To: mobile-ip
Cc: Peter.Dahl
Subject: RE: [mobile-ip] Heterogeneous Handover - = How Would it Work?


Clearly, you are mixing roaming with seamless = mobility across
heterogeneous
access types. The Mobile IP WG does not deal with = aspects related to
roaming
agreements between operators or administrative = domains. That is NOT what
this WG is about.

-Basavaraj

> -----Original Message-----
> From: ext Dahl, Peter [mailto:Peter.Dahl@Verizon= Wireless.com]
> Sent: Wednesday, August 08, 2001 1:53 PM
> To: 'mobile-ip@sunroof.eng.sun.com'
> Subject: RE: [mobile-ip] Heterogeneous Handover = - How Would it Work?
>
>
> ...not forgetting cdma2000.  I am not = aware of any work in
> 3GPP2 or IEEE,
> perhaps 3GPP ?
>
> Pete
>
> -----Original Message-----
> From: Brad Casemore [mailto:bcasemore@home.com]=
> Sent: Wednesday, August 08, 2001 11:29 = AM
> To: mobile-ip@sunroof.eng.sun.com
> Subject: RE: [mobile-ip] Heterogeneous Handover = - How Would it Work?
>
>
> If that is the case, then WECA's WISPr is = dedicated to
> 802.11b roaming,
> while the ETSI has assigned a group to address = GPRS roaming.
> Is there a
> group anywhere that is looking into the = technical issues
> associated with
> heterogeneous network roaming (such as between, = theoretically, 802.11b
> WLANs and GPRS)?
>
> Brad
>
> > -----Original Message-----
> > From: owner-mobile-ip@sunroof.eng.sun.com = [mailto:owner-mobile-
> > ip@sunroof.eng.sun.com] On Behalf Of James = Kempf
> > Sent: Wednesday, August 08, 2001 2:19 = AM
> > To: mobile-ip@sunroof.eng.sun.com; = mobile-ip@sunroof.eng.sun.com
> > Subject: Re: [mobile-ip] Heterogeneous = Handover - How Would it Work?
> >
> > Pat,
> >
> > I think they already have such a standard = and I believe it
> only works
> > with GPRS.
> >
> >     =         jak
> >
> > >Also, I believe that ETSI is working = on a standard called GRX for
> GSM<-
> > >802.11
> > >roaming.
> > >
> > >PatC
> > >On Tue, Aug 07, 2001 at 09:32:58AM = -0700, Dahl, Peter wrote:
> > >> FYI, the Wireless ISPs (WISPs) = are already talking about such
> roaming
> > >> issues.
> > >>
> > >> There appear to be 2 emerging = forums for these discussions, one
> under
> > the
> > >> auspices of WECA (http://www.weca.net) = known as the WISPr group
> ('r'
> > being
> > >> for roaming), the other a yet to = be finalized 'WISP Forum' the
> prime
> > mover
> > >> for which is a company in = Luxembourg (www.excilan.com).
> > >>
> > >> Regards
> > >>
> > >> -----Original Message-----
> > >> From: James Kempf [mailto:James.Kempf@Sun.COM]
> > >> Sent: Tuesday, August 07, 2001 = 8:58 AM
> > >> To: = mobile-ip@sunroof.eng.sun.com; mobile-ip@sunroof.eng.sun.com
> > >> Subject: Re: [mobile-ip] = Heterogeneous Handover - How Would it
> Work?
> > >>
> > >>
> > >> >On the other hand, the home = address must belong to some
> ISP/operator.
> > >> >That ISP must provide a home = agent and an ip address, and a CoA
> when
> > the
> > >> >MN is connected to other than = the home subnet. Other
> ISPs that are
> > used
> > >> >are only access providers, = and would give the MN its
> CoA. This of
> > course
> > >> >would cause political = problems. Who are the ISPs that
> are willing
> to
> > be
> > >> >access providers only, and = who will be providing home agent and
> home
> > >> >address as well?
> > >> >
> > >>
> > >> This is an issue. What happens if = you have one access provider on
> > >> one interface, say the wCDMA = interface, and another on
> another, say
> > 802.11?
> > >> There are now in the US a growing = number of 802.11 access
> providers,
> > >> and I can imagine someone with a = laptop having a wCDMA modem and
> > >> an 802.11 card.
> > >>
> > >> Maybe something like the = "roaming consortia" that have sprung up
> > >> around ISP access might evolve, = but the protocol
> design/engineering
> > >> issue is whether there is any = additional work (such as the NAI in
> > >> the roaming consortia example) = needed to enable sharing of a home
> > >> address among interfaces for = which different ISPs are
> responsible.
> > >>
> > >> Something like SUCV, that would = allow an ISP to cryptographically
> > identify
> > >> to what other ISP an address = belonged, might be useful in this
> context.
> > >>
> > >>  =         jak
>

------_=_NextPart_001_01C12112.8D95D7A0-- From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 10 04:00:25 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00945 for ; Fri, 10 Aug 2001 04:00: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 BAA17227; Fri, 10 Aug 2001 01:01: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 AAA19024; Fri, 10 Aug 2001 00:59:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7A7wOp22840 for mobile-ip-dist; Fri, 10 Aug 2001 00:58:24 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7A7wLD22833 for ; Fri, 10 Aug 2001 00:58:21 -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 AAA19775; Fri, 10 Aug 2001 00:58:20 -0700 (PDT) From: James Kempf Message-Id: <200108100758.AAA19775@heliopolis.eng.sun.com> Date: Fri, 10 Aug 2001 08:57:17 +0-100 To: , Cc: "Peter.Dahl" Subject: RE: [mobile-ip] Heterogeneous Handover - How Would it Work? 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 Glenn, I think Raj is right on here, sorry. There are enough technical issues involved in getting MIP to be deployable that the MIP group really needs to focus on. An example is this NAT question. If there are any operational issues involved in handover between operators that need resolution, they should probably be handled in a separate working group, like ROAMOPS. An example of such an issue might be advertising access routers between operators using something like the Seamoby CAR discovery protocol, which is just now getting off the ground. jak >Raj, > >That's like saying that BGP doesn't deal with the routing policy related to >business relationships between the owners of autonomous systems. You are >shoe-holing the group into only dealing with an enterprise - not the >Internet. > >-----Original Message----- >From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com] >Sent: Thursday, August 09, 2001 10:55 AM >To: mobile-ip >Cc: Peter.Dahl >Subject: RE: [mobile-ip] Heterogeneous Handover - How Would it Work? > > >Clearly, you are mixing roaming with seamless mobility across >heterogeneous >access types. The Mobile IP WG does not deal with aspects related to >roaming >agreements between operators or administrative domains. That is NOT what >this WG is about. > >-Basavaraj > >> -----Original Message----- >> From: ext Dahl, Peter [mailto:Peter.Dahl@VerizonWireless.com] >> Sent: Wednesday, August 08, 2001 1:53 PM >> To: 'mobile-ip@sunroof.eng.sun.com' >> Subject: RE: [mobile-ip] Heterogeneous Handover - How Would it Work? >> >> >> ...not forgetting cdma2000. I am not aware of any work in >> 3GPP2 or IEEE, >> perhaps 3GPP ? >> >> Pete >> >> -----Original Message----- >> From: Brad Casemore [mailto:bcasemore@home.com] >> Sent: Wednesday, August 08, 2001 11:29 AM >> To: mobile-ip@sunroof.eng.sun.com >> Subject: RE: [mobile-ip] Heterogeneous Handover - How Would it Work? >> >> >> If that is the case, then WECA's WISPr is dedicated to >> 802.11b roaming, >> while the ETSI has assigned a group to address GPRS roaming. >> Is there a >> group anywhere that is looking into the technical issues >> associated with >> heterogeneous network roaming (such as between, theoretically, 802.11b >> WLANs and GPRS)? >> >> Brad >> >> > -----Original Message----- >> > From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile- >> > ip@sunroof.eng.sun.com] On Behalf Of James Kempf >> > Sent: Wednesday, August 08, 2001 2:19 AM >> > To: mobile-ip@sunroof.eng.sun.com; mobile-ip@sunroof.eng.sun.com >> > Subject: Re: [mobile-ip] Heterogeneous Handover - How Would it Work? >> > >> > Pat, >> > >> > I think they already have such a standard and I believe it >> only works >> > with GPRS. >> > >> > jak >> > >> > >Also, I believe that ETSI is working on a standard called GRX for >> GSM<- >> > >802.11 >> > >roaming. >> > > >> > >PatC >> > >On Tue, Aug 07, 2001 at 09:32:58AM -0700, Dahl, Peter wrote: >> > >> FYI, the Wireless ISPs (WISPs) are already talking about such >> roaming >> > >> issues. >> > >> >> > >> There appear to be 2 emerging forums for these discussions, one >> under >> > the >> > >> auspices of WECA (http://www.weca.net) known as the WISPr group >> ('r' >> > being >> > >> for roaming), the other a yet to be finalized 'WISP Forum' the >> prime >> > mover >> > >> for which is a company in Luxembourg (www.excilan.com). >> > >> >> > >> Regards >> > >> >> > >> -----Original Message----- >> > >> From: James Kempf [mailto:James.Kempf@Sun.COM] >> > >> Sent: Tuesday, August 07, 2001 8:58 AM >> > >> To: mobile-ip@sunroof.eng.sun.com; mobile-ip@sunroof.eng.sun.com >> > >> Subject: Re: [mobile-ip] Heterogeneous Handover - How Would it >> Work? >> > >> >> > >> >> > >> >On the other hand, the home address must belong to some >> ISP/operator. >> > >> >That ISP must provide a home agent and an ip address, and a CoA >> when >> > the >> > >> >MN is connected to other than the home subnet. Other >> ISPs that are >> > used >> > >> >are only access providers, and would give the MN its >> CoA. This of >> > course >> > >> >would cause political problems. Who are the ISPs that >> are willing >> to >> > be >> > >> >access providers only, and who will be providing home agent and >> home >> > >> >address as well? >> > >> > >> > >> >> > >> This is an issue. What happens if you have one access provider on >> > >> one interface, say the wCDMA interface, and another on >> another, say >> > 802.11? >> > >> There are now in the US a growing number of 802.11 access >> providers, >> > >> and I can imagine someone with a laptop having a wCDMA modem and >> > >> an 802.11 card. >> > >> >> > >> Maybe something like the "roaming consortia" that have sprung up >> > >> around ISP access might evolve, but the protocol >> design/engineering >> > >> issue is whether there is any additional work (such as the NAI in >> > >> the roaming consortia example) needed to enable sharing of a home >> > >> address among interfaces for which different ISPs are >> responsible. >> > >> >> > >> Something like SUCV, that would allow an ISP to cryptographically >> > identify >> > >> to what other ISP an address belonged, might be useful in this >> context. >> > >> >> > >> jak >> From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 10 04:13:25 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01163 for ; Fri, 10 Aug 2001 04:13: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 CAA20840; Fri, 10 Aug 2001 02:14:21 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA04284; Fri, 10 Aug 2001 01:13:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7A8BnX22929 for mobile-ip-dist; Fri, 10 Aug 2001 01:11: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+Sun/8.11.5) with ESMTP id f7A8BkD22922 for ; Fri, 10 Aug 2001 01:11:46 -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 BAA19957; Fri, 10 Aug 2001 01:11:40 -0700 (PDT) From: James Kempf Message-Id: <200108100811.BAA19957@heliopolis.eng.sun.com> Date: Fri, 10 Aug 2001 09:10:37 +0-100 To: , Subject: Re: [mobile-ip] Heterogeneous Handover - How Would it Work? 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 >> Something like SUCV, that would allow an ISP to cryptographically identify >> to what other ISP an address belonged, might be useful in this context. > >I didn't read the above in the SUCV draft. SUCV allows nodes to challenge >the node with an SUCV address to show indicate that they have the private >key corresponding to the address. This doesn't identify the ISP as far >as I can tell. >Or do you intend to infer the identity of the ISP from the high-order >bits in the IPv6 address? > Right, the high order bits identify the ISP, the low order identify the mobile node. I suppose there is an issue here in that a mobile node could manufacture the high order bits and thus claim it was from an ISV that it wasn't, but the low order bits should provide proof. jak From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 10 05:31:39 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01891 for ; Fri, 10 Aug 2001 05:31:38 -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 CAA10684; Fri, 10 Aug 2001 02:32: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 CAA07751; Fri, 10 Aug 2001 02:31:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7A9UxH23289 for mobile-ip-dist; Fri, 10 Aug 2001 02:30:59 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7A9UrD23281 for ; Fri, 10 Aug 2001 02:30:53 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA02668 for ; Fri, 10 Aug 2001 02:31:01 -0700 (PDT) Received: from rajma.kniveton.com (adsl-63-197-0-77.dsl.snfc21.pacbell.net [63.197.0.77]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA12270 for ; Fri, 10 Aug 2001 03:31:06 -0600 (MDT) Received: from Kniveton.com (host217-33-141-92.ietf.ignite.net [217.33.141.92]) by rajma.kniveton.com (8.11.1/8.11.1) with ESMTP id f7A9Uqd59174 for ; Fri, 10 Aug 2001 02:30:53 -0700 (PDT) Message-ID: <3B73A9C9.38C82250@Kniveton.com> Date: Fri, 10 Aug 2001 10:30:49 +0100 From: "T.J. Kniveton" Organization: NOKIA Research X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Mobile Routers support without optimization 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 During the London meeting, Thierry Ernst talked about support for Mobile Networks under IPv6. There was some concern about how to properly authenticate authorization for the ability to change subnet routing information. For instance, it seems to be trickier to know when to allow a binding for a /4 prefix than for a /128 prefix (host) on a correspondent node. This opens up a nasty redirection attack on any correspondent node supporting mobile routers. Putting aside route optimization and the processing of prefix scope binding updates on the CN, the problem is greatly reduced. At the home agent, there is already some configuration presumed, and deciding which prefixes are assigned to which MRs (and hence, which PSBAs to accept) is more feasible. In the worst case, if a HA does not discriminate in accepting these bindings, the /4 hijacked prefix would only be forwarded to the MN for packets generated internally by the HA (while acting as a CN); however, packets will never show up on the home link destined for the MN, since the upstream aggregation routers will not forward these packets to the home link, but rather to the correct part of the network where the /4 prefix really lives. A side effect of this is that prefixes used by MRs will have to be topologically correct, in that they must in the usual case be routed to the home link. This seems like a good feature, since the CN can rely on the prefix ownership authorization that is implicit in the topology and router configurations. -TJ From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 10 05:35:28 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01933 for ; Fri, 10 Aug 2001 05:35: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 CAA11981; Fri, 10 Aug 2001 02:36:24 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA08044; Fri, 10 Aug 2001 02:35:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7A9Yws23365 for mobile-ip-dist; Fri, 10 Aug 2001 02:34:58 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7A9YsD23358 for ; Fri, 10 Aug 2001 02:34: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 CAA07987 for ; Fri, 10 Aug 2001 02:35:01 -0700 (PDT) Received: from rajma.kniveton.com (adsl-63-197-0-77.dsl.snfc21.pacbell.net [63.197.0.77]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA00340 for ; Fri, 10 Aug 2001 02:35:00 -0700 (PDT) Received: from Kniveton.com (host217-33-141-92.ietf.ignite.net [217.33.141.92]) by rajma.kniveton.com (8.11.1/8.11.1) with ESMTP id f7A9Yxd59215 for ; Fri, 10 Aug 2001 02:34:59 -0700 (PDT) Message-ID: <3B73AAC0.72031B8@Kniveton.com> Date: Fri, 10 Aug 2001 10:34:56 +0100 From: "T.J. Kniveton" Organization: NOKIA Research X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Mobile Routers: Why is P bit needed? 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 There is one question I had on the Mobile Networks draft which I thought would be better suited for the list than the meeting: What is the need for a Prefix Scope Registration bit? I can not think of a case where a MR would have to include a Prefix Scope extension on a BU and wouldn't want it to be processed. Isn't the inclusion of said extension, or not, tantamount to indicating its presence with the P bit? -TJ From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 10 06:04:58 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02344 for ; Fri, 10 Aug 2001 06:04: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 DAA20039; Fri, 10 Aug 2001 03:05:59 -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 DAA13115; Fri, 10 Aug 2001 03:05:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7AA4fA23573 for mobile-ip-dist; Fri, 10 Aug 2001 03:04:41 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7AA4cD23566 for ; Fri, 10 Aug 2001 03:04:38 -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 DAA05021 for ; Fri, 10 Aug 2001 03:04:43 -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 DAA12481 for ; Fri, 10 Aug 2001 03:04:43 -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 f7AA4ki20738 for ; Fri, 10 Aug 2001 05:04:46 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Fri, 10 Aug 2001 05:04:27 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.1600); Fri, 10 Aug 2001 05:04:24 -0500 content-class: urn:content-classes:message Subject: RE: [mobile-ip] Heterogeneous Handover - How Would it Work? Date: Fri, 10 Aug 2001 05:04:29 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF440861C9@daebe007.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [mobile-ip] Heterogeneous Handover - How Would it Work? X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 Thread-Index: AcEhEtqoCeN88I0GEdWBSQBQi2X+DwAcPKfg To: Cc: , X-OriginalArrivalTime: 10 Aug 2001 10:04:24.0805 (UTC) FILETIME=[D56A9950:01C12183] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f7AA4cD23567 Sender: owner-mobile-ip@sunroof.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 Glenn, >Raj, > >That's like saying that BGP doesn't deal with the routing policy >related to business relationships between the owners of autonomous >systems. You are shoe-holing the group into only dealing with an >enterprise - not the Internet. > I am not sure why you believe my statement shoe-holes MIPv4 to enterprise only. For MIPv4 to work within the enterprise and the Internet you have to deal with the NAT problem as James mentioned and that is something that this WG can and should work on (at IETF51 we have decided that this is an area that will be worked on in this WG). However the relationship between operators and roaming between them is a different problem and that I do not believe is in the scope of this WG. -Basavaraj >> >>Clearly, you are mixing roaming with seamless mobility across >>heterogeneous >>access types. The Mobile IP WG does not deal with aspects related to >>roaming >>agreements between operators or administrative domains. That is NOT what >>this WG is about. >> >>-Basavaraj From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 10 06:20:45 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02667 for ; Fri, 10 Aug 2001 06:20: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 EAA17593; Fri, 10 Aug 2001 04:21:35 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA14371; Fri, 10 Aug 2001 03:20:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7AAJfa23688 for mobile-ip-dist; Fri, 10 Aug 2001 03:19:41 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7AAJbD23681 for ; Fri, 10 Aug 2001 03:19:37 -0700 (PDT) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA14305; Fri, 10 Aug 2001 03:19:42 -0700 (PDT) Received: from sun.com (vpn-129-156-96-47.EMEA.Sun.COM [129.156.96.47]) by nasnfs.Eng.Sun.COM (8.10.2+Sun/8.10.2) with ESMTP id f7AAJfw00719; Fri, 10 Aug 2001 03:19:41 -0700 (PDT) Message-ID: <3B73B4BB.D45D5686@sun.com> Date: Fri, 10 Aug 2001 12:17:31 +0200 From: gabriel montenegro X-Mailer: Mozilla 4.77 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Heterogeneous Handover - How Would it Work? References: <200108100811.BAA19957@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: > >> Something like SUCV, that would allow an ISP to cryptographically identify > >> to what other ISP an address belonged, might be useful in this context. > > > >I didn't read the above in the SUCV draft. SUCV allows nodes to challenge > >the node with an SUCV address to show indicate that they have the private > >key corresponding to the address. This doesn't identify the ISP as far > >as I can tell. > >Or do you intend to infer the identity of the ISP from the high-order > >bits in the IPv6 address? > > > > Right, the high order bits identify the ISP, the low order identify > the mobile node. > > I suppose there is an issue here in that a mobile node could manufacture > the high order bits and thus claim it was from an ISV that it wasn't, > but the low order bits should provide proof. sucv addresses (as opposed to sucv id's) only give you a cryptographic assurance on the lower 64 bits. the upper 64 are, of course, just the prefix which could give you some indication/assurance as to the ISP. at any rate the nature of the assurance is not cryptographic, it's merely based on return routability or some such soft binding. if you want hard crypto assurance on all the bits then HIP (or sucv id's) can do this. the hip draft talks about how to allow for HAA (host assigning authority) field. this is what could relate to your ISP, for example. but then you no longer have a routable entity. -gabriel From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 10 06:40:51 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03042 for ; Fri, 10 Aug 2001 06:40: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 DAA28430; Fri, 10 Aug 2001 03:41: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 DAA07345; Fri, 10 Aug 2001 03:41:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7AAeEg23873 for mobile-ip-dist; Fri, 10 Aug 2001 03:40:14 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7AAeBD23866 for ; Fri, 10 Aug 2001 03:40:11 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA15616 for ; Fri, 10 Aug 2001 03:40:17 -0700 (PDT) Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA12665 for ; Fri, 10 Aug 2001 04:40:23 -0600 (MDT) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate3.mot.com (motgate3 2.1) with ESMTP id DAA12746 for ; Fri, 10 Aug 2001 03:31:04 -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 DAA25694 for ; Fri, 10 Aug 2001 03:30:53 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r3.mot.com with ESMTP for mobile-ip@sunroof.eng.sun.com; Fri, 10 Aug 2001 05:28:29 -0500 Received: from crm.mot.com (nero.crm.mot.com [140.101.173.36]) by thorgal.crm.mot.com (Postfix) with ESMTP id D4D8E2ECF8 for ; Fri, 10 Aug 2001 12:28:34 +0200 (CEST) Message-Id: <3B73B753.D3365C7E@crm.mot.com> Date: Fri, 10 Aug 2001 12:28:35 +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 Subject: Re: [mobile-ip] Mobile Routers support without optimization References: <3B73A9C9.38C82250@Kniveton.com> Content-Type: multipart/mixed; boundary="------------1B314F58605A0153EFEF0D41" Sender: owner-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. --------------1B314F58605A0153EFEF0D41 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello TJ, Actually Binding Updates for prefixes do not disable route optimization feature. Clearly, the authorization process is trickier. It can however be performed provided that it makes use of the knowledge the HA has about the binding 'Mobile Prefix' / 'Mobile Router'. HA can then be asked by the CN before CN updates its Binding Cache upon receiption of a prefix BU. In draft-ernst-mobileip-v6-network-02.txt, we study a light enhancement to BAKE that allows to use it to authorize a prefix BU. Regards, Alexis. "T.J. Kniveton" wrote: > > During the London meeting, Thierry Ernst talked about support for Mobile > Networks under IPv6. There was some concern about how to properly > authenticate authorization for the ability to change subnet routing > information. For instance, it seems to be trickier to know when to allow > a binding for a /4 prefix than for a /128 prefix (host) on a > correspondent node. This opens up a nasty redirection attack on any > correspondent node supporting mobile routers. > > Putting aside route optimization and the processing of prefix scope > binding updates on the CN, the problem is greatly reduced. At the home > agent, there is already some configuration presumed, and deciding which > prefixes are assigned to which MRs (and hence, which PSBAs to accept) is > more feasible. In the worst case, if a HA does not discriminate in > accepting these bindings, the /4 hijacked prefix would only be forwarded > to the MN for packets generated internally by the HA (while acting as a > CN); however, packets will never show up on the home link destined for > the MN, since the upstream aggregation routers will not forward these > packets to the home link, but rather to the correct part of the network > where the /4 prefix really lives. > > A side effect of this is that prefixes used by MRs will have to be > topologically correct, in that they must in the usual case be routed to > the home link. This seems like a good feature, since the CN can rely on > the prefix ownership authorization that is implicit in the topology and > router configurations. > > -TJ --------------1B314F58605A0153EFEF0D41 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 --------------1B314F58605A0153EFEF0D41-- From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 10 10:34:01 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05493 for ; Fri, 10 Aug 2001 10:34: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 IAA20687; Fri, 10 Aug 2001 08:34: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 HAA01236; Fri, 10 Aug 2001 07:34:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7AEXAG24364 for mobile-ip-dist; Fri, 10 Aug 2001 07:33:10 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7AEX7D24357 for ; Fri, 10 Aug 2001 07:33: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 HAA20908 for ; Fri, 10 Aug 2001 07:33:13 -0700 (PDT) Received: from zrc2s03g.us.nortel.com (zrc2s03g.nortelnetworks.com [47.103.122.66]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA10942 for ; Fri, 10 Aug 2001 07:33:11 -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 JAA20141 for ; Fri, 10 Aug 2001 09:33:06 -0500 (CDT) Received: from zrchb200.us.nortel.com by smtprch1.nortel.com; Fri, 10 Aug 2001 09:33:06 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 10 Aug 2001 09:32:39 -0500 Message-ID: <85AA7486A2C1D411BCA20000F8073E4303130349@crchy271.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Heterogeneous Handover - How Would it Work? Date: Fri, 10 Aug 2001 09:32:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C121A9.4EBA0CD0" Sender: owner-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_01C121A9.4EBA0CD0 Content-Type: text/plain; charset="iso-8859-1" Let's change the description of the MIP WG then: Stick an "Interdomain" before the Routing for Mobile/Wireless Hosts -----Original Message----- From: James Kempf [mailto:James.Kempf@Sun.COM] Sent: Friday, August 10, 2001 4:11 AM To: mobile-ip; mobile-ip Subject: Re: [mobile-ip] Heterogeneous Handover - How Would it Work? >> Something like SUCV, that would allow an ISP to cryptographically identify >> to what other ISP an address belonged, might be useful in this context. > >I didn't read the above in the SUCV draft. SUCV allows nodes to challenge >the node with an SUCV address to show indicate that they have the private >key corresponding to the address. This doesn't identify the ISP as far >as I can tell. >Or do you intend to infer the identity of the ISP from the high-order >bits in the IPv6 address? > Right, the high order bits identify the ISP, the low order identify the mobile node. I suppose there is an issue here in that a mobile node could manufacture the high order bits and thus claim it was from an ISV that it wasn't, but the low order bits should provide proof. jak ------_=_NextPart_001_01C121A9.4EBA0CD0 Content-Type: text/html; charset="iso-8859-1" RE: [mobile-ip] Heterogeneous Handover - How Would it Work?

Let's change the description of the MIP WG then:

Stick an "Interdomain" before the Routing for Mobile/Wireless Hosts

-----Original Message-----
From: James Kempf [mailto:James.Kempf@Sun.COM]
Sent: Friday, August 10, 2001 4:11 AM
To: mobile-ip; mobile-ip
Subject: Re: [mobile-ip] Heterogeneous Handover - How Would it Work?


>> Something like SUCV, that would allow an ISP to cryptographically identify
>> to what other ISP an address belonged, might be useful in this context.
>
>I didn't read the above in the SUCV draft. SUCV allows nodes to challenge
>the node with an SUCV address to show indicate that they have the private
>key corresponding to the address. This doesn't identify the ISP as far
>as I can tell.
>Or do you intend to infer the identity of the ISP from the high-order
>bits in the IPv6 address?
>

Right, the high order bits identify the ISP, the low order identify
the mobile node.

I suppose there is an issue here in that a mobile node could manufacture
the high order bits and thus claim  it was from an ISV that it wasn't,
but the low order bits should provide proof.

                jak

------_=_NextPart_001_01C121A9.4EBA0CD0-- From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 10 12:07:42 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07190 for ; Fri, 10 Aug 2001 12:07: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 KAA08938; Fri, 10 Aug 2001 10:08:36 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA00763; Fri, 10 Aug 2001 09:07:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7AG6vY24923 for mobile-ip-dist; Fri, 10 Aug 2001 09:06:57 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7AG6rD24916 for ; Fri, 10 Aug 2001 09:06:53 -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 JAA17485 for ; Fri, 10 Aug 2001 09:07:00 -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 KAA16315 for ; Fri, 10 Aug 2001 10:07:05 -0600 (MDT) Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id LAA29078 for ; Fri, 10 Aug 2001 11:06:52 -0500 (CDT) Received: from zrchb200.us.nortel.com by smtprch2.nortel.com; Fri, 10 Aug 2001 11:00:22 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 10 Aug 2001 11:06:27 -0500 Message-ID: <85AA7486A2C1D411BCA20000F8073E43031304CB@crchy271.us.nortel.com> From: "Glenn Morrow" To: "Basavaraj.Patil" , mobile-ip Cc: "Peter.Dahl" Subject: RE: [mobile-ip] Heterogeneous Handover - How Would it Work? Date: Fri, 10 Aug 2001 11:06:25 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C121B6.6817F6D0" 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_01C121B6.6817F6D0 Content-Type: text/plain; charset="iso-8859-1" It just seems to me that a roaming agreement is nothing more than a routing policy in an all IP network. Why is a working group with a description of IP Routing for Wireless/Mobile Hosts limiting itself to just certain aspects of the "routing" problem. I see this as directly related to IP routing for Wireless/Mobile Hosts - that was my point. -----Original Message----- From: Basavaraj.Patil [mailto:Basavaraj.Patil@nokia.com] Sent: Friday, August 10, 2001 5:04 AM To: mobile-ip Cc: Peter.Dahl; Morrow, Glenn [RICH2:C330:EXCH] Subject: RE: [mobile-ip] Heterogeneous Handover - How Would it Work? Glenn, >Raj, > >That's like saying that BGP doesn't deal with the routing policy >related to business relationships between the owners of autonomous >systems. You are shoe-holing the group into only dealing with an >enterprise - not the Internet. > I am not sure why you believe my statement shoe-holes MIPv4 to enterprise only. For MIPv4 to work within the enterprise and the Internet you have to deal with the NAT problem as James mentioned and that is something that this WG can and should work on (at IETF51 we have decided that this is an area that will be worked on in this WG). However the relationship between operators and roaming between them is a different problem and that I do not believe is in the scope of this WG. -Basavaraj >> >>Clearly, you are mixing roaming with seamless mobility across >>heterogeneous >>access types. The Mobile IP WG does not deal with aspects related to >>roaming >>agreements between operators or administrative domains. That is NOT what >>this WG is about. >> >>-Basavaraj ------_=_NextPart_001_01C121B6.6817F6D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Heterogeneous Handover - How Would it = Work?

It just seems to me that a roaming agreement is = nothing more than a routing policy in an all IP network. Why is a = working group with a description of

 IP Routing for Wireless/Mobile Hosts

limiting itself to just certain aspects of the = "routing" problem. I see this as directly related to IP = routing for Wireless/Mobile Hosts - that was my point.








-----Original Message-----
From: Basavaraj.Patil [mailto:Basavaraj.Patil@nokia.c= om]
Sent: Friday, August 10, 2001 5:04 AM
To: mobile-ip
Cc: Peter.Dahl; Morrow, Glenn = [RICH2:C330:EXCH]
Subject: RE: [mobile-ip] Heterogeneous Handover - = How Would it Work?


 
Glenn,
 
>Raj,
>
>That's like saying that BGP doesn't deal with = the routing policy
>related to business relationships between the = owners of autonomous
>systems. You are shoe-holing the group into only = dealing with an
>enterprise - not the Internet. 
>
 
I am not sure why you believe my statement = shoe-holes MIPv4 to
enterprise only. For MIPv4 to work within the = enterprise and the
Internet you have to deal with the NAT problem as = James mentioned and
that is something that this WG can and should work = on (at IETF51 we
have decided that this is an area that will be = worked on in this
WG). However the relationship between operators and = roaming between
them is a different problem and that I do not = believe is in the scope
of this WG.
 
-Basavaraj
 
>>
>>Clearly, you are mixing roaming with = seamless mobility across
>>heterogeneous
>>access types. The Mobile IP WG does not deal = with aspects related to
>>roaming
>>agreements between operators or = administrative domains. That is NOT
what
>>this WG is about.
>>
>>-Basavaraj

------_=_NextPart_001_01C121B6.6817F6D0-- From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 10 12:29:47 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07549 for ; Fri, 10 Aug 2001 12:29: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 JAA28263; Fri, 10 Aug 2001 09:30: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 JAA21977; Fri, 10 Aug 2001 09:29:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7AGScm25011 for mobile-ip-dist; Fri, 10 Aug 2001 09:28:38 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7AGSYD25004 for ; Fri, 10 Aug 2001 09:28:34 -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 JAA05160 for ; Fri, 10 Aug 2001 09:28:37 -0700 (PDT) Received: from howler.tri.sbc.com (howler.tri.sbc.com [205.173.58.4]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA08791 for ; Fri, 10 Aug 2001 09:28:31 -0700 (PDT) Received: from sbctri.tri.sbc.com (sbctri [144.60.1.10]) by howler.tri.sbc.com (8.11.0/8.11.0) with ESMTP id f7AGSsj10074 for ; Fri, 10 Aug 2001 11:28:54 -0500 (CDT) Received: from trimail2.tri.sbc.com (localhost [127.0.0.1]) by sbctri.tri.sbc.com (8.11.0/8.9.3) with ESMTP id f7AGS4Q16614 for ; Fri, 10 Aug 2001 11:28:04 -0500 (CDT) Received: by trimail2.tri.sbc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 10 Aug 2001 11:28:12 -0500 Message-ID: <4D45BA2A58A7D3119E050008C7E69E29F7946B@trimail2.tri.sbc.com> From: "Doradla, Anil" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] Heterogeneous Handover - where do i look Date: Fri, 10 Aug 2001 11:28:03 -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: Coming back to the question of handover across heterogeneous wireless networks. Can anyone advise me as to where i should look at? We are seeing a desire for handover between 802.11 and GPRS networks. Is there any group looking at the feasibility of this ? Thanks in advance Anil Doradla SBC- Technology Resources, Inc. Austin, TX-78727 -----Original Message----- From: James Kempf [mailto:James.Kempf@sun.com] Sent: Friday, August 10, 2001 3:57 AM To: mobile-ip@sunroof.eng.sun.com; mobile-ip@sunroof.eng.sun.com Cc: Peter.Dahl Subject: RE: [mobile-ip] Heterogeneous Handover - How Would it Work? Glenn, I think Raj is right on here, sorry. There are enough technical issues involved in getting MIP to be deployable that the MIP group really needs to focus on. An example is this NAT question. If there are any operational issues involved in handover between operators that need resolution, they should probably be handled in a separate working group, like ROAMOPS. An example of such an issue might be advertising access routers between operators using something like the Seamoby CAR discovery protocol, which is just now getting off the ground. jak >Raj, > >That's like saying that BGP doesn't deal with the routing policy related to >business relationships between the owners of autonomous systems. You are >shoe-holing the group into only dealing with an enterprise - not the >Internet. > >-----Original Message----- >From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com] >Sent: Thursday, August 09, 2001 10:55 AM >To: mobile-ip >Cc: Peter.Dahl >Subject: RE: [mobile-ip] Heterogeneous Handover - How Would it Work? > > >Clearly, you are mixing roaming with seamless mobility across >heterogeneous >access types. The Mobile IP WG does not deal with aspects related to >roaming >agreements between operators or administrative domains. That is NOT what >this WG is about. > >-Basavaraj > >> -----Original Message----- >> From: ext Dahl, Peter [mailto:Peter.Dahl@VerizonWireless.com] >> Sent: Wednesday, August 08, 2001 1:53 PM >> To: 'mobile-ip@sunroof.eng.sun.com' >> Subject: RE: [mobile-ip] Heterogeneous Handover - How Would it Work? >> >> >> ...not forgetting cdma2000. I am not aware of any work in >> 3GPP2 or IEEE, >> perhaps 3GPP ? >> >> Pete >> >> -----Original Message----- >> From: Brad Casemore [mailto:bcasemore@home.com] >> Sent: Wednesday, August 08, 2001 11:29 AM >> To: mobile-ip@sunroof.eng.sun.com >> Subject: RE: [mobile-ip] Heterogeneous Handover - How Would it Work? >> >> >> If that is the case, then WECA's WISPr is dedicated to >> 802.11b roaming, >> while the ETSI has assigned a group to address GPRS roaming. >> Is there a >> group anywhere that is looking into the technical issues >> associated with >> heterogeneous network roaming (such as between, theoretically, 802.11b >> WLANs and GPRS)? >> >> Brad >> >> > -----Original Message----- >> > From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile- >> > ip@sunroof.eng.sun.com] On Behalf Of James Kempf >> > Sent: Wednesday, August 08, 2001 2:19 AM >> > To: mobile-ip@sunroof.eng.sun.com; mobile-ip@sunroof.eng.sun.com >> > Subject: Re: [mobile-ip] Heterogeneous Handover - How Would it Work? >> > >> > Pat, >> > >> > I think they already have such a standard and I believe it >> only works >> > with GPRS. >> > >> > jak >> > >> > >Also, I believe that ETSI is working on a standard called GRX for >> GSM<- >> > >802.11 >> > >roaming. >> > > >> > >PatC >> > >On Tue, Aug 07, 2001 at 09:32:58AM -0700, Dahl, Peter wrote: >> > >> FYI, the Wireless ISPs (WISPs) are already talking about such >> roaming >> > >> issues. >> > >> >> > >> There appear to be 2 emerging forums for these discussions, one >> under >> > the >> > >> auspices of WECA (http://www.weca.net) known as the WISPr group >> ('r' >> > being >> > >> for roaming), the other a yet to be finalized 'WISP Forum' the >> prime >> > mover >> > >> for which is a company in Luxembourg (www.excilan.com). >> > >> >> > >> Regards >> > >> >> > >> -----Original Message----- >> > >> From: James Kempf [mailto:James.Kempf@Sun.COM] >> > >> Sent: Tuesday, August 07, 2001 8:58 AM >> > >> To: mobile-ip@sunroof.eng.sun.com; mobile-ip@sunroof.eng.sun.com >> > >> Subject: Re: [mobile-ip] Heterogeneous Handover - How Would it >> Work? >> > >> >> > >> >> > >> >On the other hand, the home address must belong to some >> ISP/operator. >> > >> >That ISP must provide a home agent and an ip address, and a CoA >> when >> > the >> > >> >MN is connected to other than the home subnet. Other >> ISPs that are >> > used >> > >> >are only access providers, and would give the MN its >> CoA. This of >> > course >> > >> >would cause political problems. Who are the ISPs that >> are willing >> to >> > be >> > >> >access providers only, and who will be providing home agent and >> home >> > >> >address as well? >> > >> > >> > >> >> > >> This is an issue. What happens if you have one access provider on >> > >> one interface, say the wCDMA interface, and another on >> another, say >> > 802.11? >> > >> There are now in the US a growing number of 802.11 access >> providers, >> > >> and I can imagine someone with a laptop having a wCDMA modem and >> > >> an 802.11 card. >> > >> >> > >> Maybe something like the "roaming consortia" that have sprung up >> > >> around ISP access might evolve, but the protocol >> design/engineering >> > >> issue is whether there is any additional work (such as the NAI in >> > >> the roaming consortia example) needed to enable sharing of a home >> > >> address among interfaces for which different ISPs are >> responsible. >> > >> >> > >> Something like SUCV, that would allow an ISP to cryptographically >> > identify >> > >> to what other ISP an address belonged, might be useful in this >> context. >> > >> >> > >> jak >> From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 10 16:38:02 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11250 for ; Fri, 10 Aug 2001 16:38: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 NAA07175; Fri, 10 Aug 2001 13:38: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 NAA25733; Fri, 10 Aug 2001 13:37:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7AKafU25803 for mobile-ip-dist; Fri, 10 Aug 2001 13:36:41 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7AKabD25796 for ; Fri, 10 Aug 2001 13:36: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 NAA14640 for ; Fri, 10 Aug 2001 13:36:44 -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 OAA24890 for ; Fri, 10 Aug 2001 14:36:42 -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 NAA24367 for ; Fri, 10 Aug 2001 13:36:43 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f7AKagS11987 for ; Fri, 10 Aug 2001 13:36:42 -0700 X-mProtect: Fri, 10 Aug 2001 13:36:42 -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 smtpddCBLaq; Fri, 10 Aug 2001 13:36:40 PDT Message-ID: <3B7445D8.43F28C10@iprg.nokia.com> Date: Fri, 10 Aug 2001 13:36: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] problem of infinite lifetime in BU References: <20010618183642.A7184@yuchung> 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 dont know if anyone has replied to your question. anyway see comments below Yuchung Cheng wrote: > > Why BU can have infinite lifetime? > > I mean if MN sends such BU to HA, then MN crashes and boot again, > the new registration probably fails because HA performs sequence > number checking and the binding never expires? this is taken careof in the latest draft 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. the MN which receives such a packet sends a BU with the sequence number greater than the last accepted sequence number. vijay From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 10 17:33:47 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11872 for ; Fri, 10 Aug 2001 17:33: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 PAA01688; Fri, 10 Aug 2001 15:34: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 OAA26134; Fri, 10 Aug 2001 14:32:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7ALVcF26006 for mobile-ip-dist; Fri, 10 Aug 2001 14:31:38 -0700 (PDT) Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.179.15]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7ALVYD25996 for ; Fri, 10 Aug 2001 14:31:34 -0700 (PDT) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f7ALVU223657; Fri, 10 Aug 2001 23:31:30 +0200 (MET DST) Date: Fri, 10 Aug 2001 11:36:26 +0200 (CEST) From: Erik Nordmark Subject: Re: [mobile-ip] About authorization and security policies To: pekka.nikander@nomadiclab.com Cc: MobileIP Mailing List In-Reply-To: "Your message with ID" <3B712FBB.607E428B@nomadiclab.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > I hope this helps to clarify the situation. Yes. Thank you very much! In case A (IKE and AH/ESP) I think one way of getting the authroization is to have the SA be created between the home address and the correspondent. Thus in this case the routability to the home address can be used implicitly by IKE in the key exchange. Thus as long as there is a way for iked to tell IP to ignore the binding cache when sending the IKE packets this should fall out pretty easy unless I'm confused. (Of course, my confusion increases assympotically during the IETF week :-) Such an approach would mean that you would need to do something different with respect to IKE for the MN to HA exchanges since in that case you can't rely on the HA reaching the MN as a way to establish authorization. Thus in this case you want to associate a something (shared secret, certificate) with the authority to "be" a certain MN. But this is a local issue contained within the HA as far as I can tell. Erik From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 10 18:03:52 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12149 for ; Fri, 10 Aug 2001 18:03: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 QAA19503; Fri, 10 Aug 2001 16:04: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 PAA02925; Fri, 10 Aug 2001 15:04:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7AM3Yo26168 for mobile-ip-dist; Fri, 10 Aug 2001 15:03:34 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.89.50] (may be forged)) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7AM3VD26161 for ; Fri, 10 Aug 2001 15:03:31 -0700 (PDT) Received: (from mohanp@localhost) by jurassic.eng.sun.com (8.11.5+Sun/8.11.5) id f7AM3bl152465; Fri, 10 Aug 2001 15:03:37 -0700 (PDT) From: Mohan Parthasarathy Message-Id: <200108102203.f7AM3bl152465@jurassic.eng.sun.com> Subject: Re: [mobile-ip] About authorization and security policies In-Reply-To: from Erik Nordmark at "Aug 10, 2001 11:36:26 am" To: mobile-ip@sunroof.eng.sun.com Date: Fri, 10 Aug 2001 15:03:37 -0700 (PDT) CC: pekka.nikander@nomadiclab.com 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 > > I hope this helps to clarify the situation. > > Yes. Thank you very much! > > In case A (IKE and AH/ESP) I think one way of getting the > authroization is to have the SA be created between the home address and the > correspondent. Thus in this case the routability to the home address can > be used implicitly by IKE in the key exchange. > > Thus as long as there is a way for iked to tell IP to ignore > the binding cache when sending the IKE packets this should fall out > pretty easy unless I'm confused. (Of course, my confusion increases > assympotically during the IETF week :-) > This is discussed in section 10.2 of the ipv6 draft. It specifically says that IKE must use only CoA as the source address. If you want to use the Home Address, then i think you should setup the SA with Home Agent first (so that it has the right binding cache) using the CoA as the source address. Then, while setting up the SA with CN use the home address (and possibly a socket option on the other end to avoid using the binding cache), i think there should not be any problem. -mohan > Such an approach would mean that you would need to do something > different with respect to IKE for the MN to HA exchanges since > in that case you can't rely on the HA reaching the MN as a way > to establish authorization. Thus in this case you want to associate > a something (shared secret, certificate) with the authority to "be" > a certain MN. But this is a local issue contained within the HA > as far as I can tell. > > Erik > > From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 10 20:53:27 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13616 for ; Fri, 10 Aug 2001 20:53:27 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA29276; Fri, 10 Aug 2001 18:54:10 -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 RAA12110; Fri, 10 Aug 2001 17:53:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7B0qWr26511 for mobile-ip-dist; Fri, 10 Aug 2001 17:52:32 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7B0qTD26504 for ; Fri, 10 Aug 2001 17:52:29 -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 RAA25818 for ; Fri, 10 Aug 2001 17:52:36 -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 SAA13368 for ; Fri, 10 Aug 2001 18:52: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 RAA17634 for ; Fri, 10 Aug 2001 17:52:35 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f7B0qY824537 for ; Fri, 10 Aug 2001 17:52:34 -0700 X-mProtect: Fri, 10 Aug 2001 17:52:34 -0700 Nokia Silicon Valley Messaging Protection Received: from maxdialin30.iprg.nokia.com (205.226.20.224, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdQ0dWvq; Fri, 10 Aug 2001 17:52:31 PDT Message-ID: <3B7481EA.EBA332B8@iprg.nokia.com> Date: Fri, 10 Aug 2001 17:52:58 -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] Heterogeneous Handover - How Would it Work? References: <85AA7486A2C1D411BCA20000F8073E4303130349@crchy271.us.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Glenn, Since Mobile IP should work for intradomain mobility, I don't see why this would be a good idea. Regards, Charlie P. Glenn Morrow wrote: > Let's change the description of the MIP WG then: > > Stick an "Interdomain" before the Routing for Mobile/Wireless Hosts > > -----Original Message----- > From: James Kempf [mailto:James.Kempf@Sun.COM] > Sent: Friday, August 10, 2001 4:11 AM > To: mobile-ip; mobile-ip > Subject: Re: [mobile-ip] Heterogeneous Handover - How Would it Work? > > >> Something like SUCV, that would allow an ISP to cryptographically > identify > >> to what other ISP an address belonged, might be useful in this > context. > > > >I didn't read the above in the SUCV draft. SUCV allows nodes to > challenge > >the node with an SUCV address to show indicate that they have the > private > >key corresponding to the address. This doesn't identify the ISP as > far > >as I can tell. > >Or do you intend to infer the identity of the ISP from the high-order > > >bits in the IPv6 address? > > > > Right, the high order bits identify the ISP, the low order identify > the mobile node. > > I suppose there is an issue here in that a mobile node could > manufacture > the high order bits and thus claim it was from an ISV that it wasn't, > > but the low order bits should provide proof. > > jak From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 10 21:00:02 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13664 for ; Fri, 10 Aug 2001 21:00: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 TAA01467; Fri, 10 Aug 2001 19:00:58 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA13081; Fri, 10 Aug 2001 18:00:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7B0xhs26592 for mobile-ip-dist; Fri, 10 Aug 2001 17:59:43 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7B0xdD26585 for ; Fri, 10 Aug 2001 17:59:39 -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 RAA26734 for ; Fri, 10 Aug 2001 17:59:47 -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 SAA16355 for ; Fri, 10 Aug 2001 18:59: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 RAA18013 for ; Fri, 10 Aug 2001 17:59:45 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f7B0xie01832 for ; Fri, 10 Aug 2001 17:59:44 -0700 X-mProtect: Fri, 10 Aug 2001 17:59:44 -0700 Nokia Silicon Valley Messaging Protection Received: from maxdialin30.iprg.nokia.com (205.226.20.224, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdbf4GQp; Fri, 10 Aug 2001 17:59:41 PDT Message-ID: <3B748398.C5C27797@iprg.nokia.com> Date: Fri, 10 Aug 2001 18:00:08 -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] RFC2002bis 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, A new version of RFC2002bis has been prepared. According to the most recent guidance given by the IESG, a change in the mandated authentication algorithm has been strongly suggested. Unfortunately, this will have the effect of causing almost all previous implementations of Mobile IP for IPv4 to become incompatible with the new specification. The working group chairs recently asked the working group, by way of the mailing list, whether this incompatible change would be acceptable. The discussion was quite limited, somewhat to my surprise. This has been taken as evidence that going with HMAC_MD5 is more-or-less O.K. Thus, it has been decided to go ahead with the change. On the other hand, it is conceivable that not all interested parties have been notified of the possible change, or have had time to reply. If there are dissenters to this change, now would be the time to express that opinion. That is the most important point of this note. Another factor in the discussion concerns the acceptability of RFC2002bis as a basis for moving Mobile IPv4 to Draft Standard. I have been told that, contrary to my previous understanding, a version of RFC2002bis could be promoted to Draft Standard even if it is first published with the several options which have not been tested for interoperability. These options are: 1. 'R' bit to the Agent Advertisement 2. 'S' bit to Registration Request 3. Prefix Lengths Extension to Agent Advertisement 4. Possibly other options that may come under discussion (I don't know of any in this class). I'll call these the "unpromotable options" On the other hand, it is likely that the IESG will not promote Mobile IPv4 to Draft Standard unless the authentication algorithm has been changed to HMAC_MD5. Consideration of all these factors leads me to believe that one of the following scenarios will happen. 1. New RFC2002bis goes to Proposed Standard with HMAC_MD5, and is promoted to Draft Standard after the ordained amount of time after the unpromotable options are excised. These would then properly be re-published in another document which would cycle at Proposed Standard. 2. New RFC2002bis goes to Proposed Standard with HMAC_MD5, and activity occurs to exhibit interoperability for the unpromotable options. Then, since the options would become promotable, RFC2002bis could go to Draft Standard without substantial revision. 3. (combination of 1 and 2): some of the unpromotable options, but not all of them, are tested for interoperability. Then fewer of the options would be excised, and the other new document would be thinner. 4. The working group could decide that moving to HMAC_MD5 was premature. Then RFC2002bis might possibly be published with "envelope-mode" specified (as it is now). Then another version of Mobile IPv4 would be published later with HMAC_MD5 mandated instead of "envelope-mode" mandated. The advantage of this approach is that it would be possible to create correct and interoperable implementations of Mobile IPv4. Up until now, all interoperable implementations have had to handle the SPI field as part of the computation of the authentication data in a way that was not clear from RFC 2002. Fixing this problem was the most important reason for embarking on RFC2002bis in the first place. I think that basically accounts for the most likely possibilities, but maybe there are others that could happen. However, it seems likely that HMAC_MD5 will be required by the IESG as the mandated default algorithm in the Draft Standard version of Mobile IPv4, because there has been published work showing that envelope mode is vulnerable to an attack that reduces its cryptographic strength. Following strategies 1-3 will mean that there is no RFC which can be read to create new implementations of Mobile IPv4 which are interoperable with existing versions of Mobile IPv4. On the other hand, following 1-3 will mean that RFC2002bis is a more likely candidate for promotion to Draft Standard, avoiding the need for one more revision to accomplish that purpose. Quick action is expected on the HMAC_MD5 version of RFC200bis, so it is possible that any discussion about backwards incompatibility will happen as part of IETF Last Call. Whatever people decide on these issues is fine with me. As draft editor, I'll happily produce whatever documents are indicated by near-term and Last Call discussions over the next weeks. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Sat Aug 11 02:21:05 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03990 for ; Sat, 11 Aug 2001 02:21: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 AAA06765; Sat, 11 Aug 2001 00:22: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 XAA22562; Fri, 10 Aug 2001 23:21:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7B6KPr26920 for mobile-ip-dist; Fri, 10 Aug 2001 23:20:25 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7B6KLD26913 for ; Fri, 10 Aug 2001 23:20: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 XAA26422 for ; Fri, 10 Aug 2001 23:20:30 -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 XAA02857 for ; Fri, 10 Aug 2001 23:20:29 -0700 (PDT) Received: from zbin ([127.0.0.1]) by ms.samsung.com (Netscape Messaging Server 4.15 ms Jul 11 2001 16:32:57) with SMTP id GHW48P00.E6R for ; Sat, 11 Aug 2001 15:19:37 +0900 Message-ID: <000f01c1222e$b49b6f50$11a1024b@zbin> From: "zb" To: References: <4D45BA2A58A7D3119E050008C7E69E29F7946B@trimail2.tri.sbc.com> Subject: Re: [mobile-ip] Heterogeneous Handover - where do i look Date: Sat, 11 Aug 2001 15:27:33 +0900 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.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Another possible use may be roaming between GPRS and bluetooth. For example, in a building, a cell phone can access internet with bluetooth. When it is out of the building, the internet access can be through GPRS zb ----- Original Message ----- From: "Doradla, Anil" To: Sent: Saturday, August 11, 2001 1:28 AM Subject: [mobile-ip] Heterogeneous Handover - where do i look > Coming back to the question of handover across heterogeneous wireless > networks. Can anyone advise me as to where i should look at? > We are seeing a desire for handover between 802.11 and GPRS networks. Is > there any group looking at the feasibility of this ? > > Thanks in advance > > Anil Doradla > SBC- Technology Resources, Inc. > Austin, TX-78727 > > > -----Original Message----- > From: James Kempf [mailto:James.Kempf@sun.com] > Sent: Friday, August 10, 2001 3:57 AM > To: mobile-ip@sunroof.eng.sun.com; mobile-ip@sunroof.eng.sun.com > Cc: Peter.Dahl > Subject: RE: [mobile-ip] Heterogeneous Handover - How Would it Work? > > > Glenn, > > I think Raj is right on here, sorry. There are enough technical issues > involved in getting MIP to be deployable that the MIP group really > needs to focus on. An example is this NAT question. > > If there are any operational issues involved in handover between operators > that > need resolution, they should probably be handled in a separate working > group, like ROAMOPS. An example of such an issue might be advertising > access routers between operators using something like the Seamoby > CAR discovery protocol, which is just now getting off the ground. > > jak > >Raj, > > > >That's like saying that BGP doesn't deal with the routing policy related to > >business relationships between the owners of autonomous systems. You are > >shoe-holing the group into only dealing with an enterprise - not the > >Internet. > > > >-----Original Message----- > >From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com] > >Sent: Thursday, August 09, 2001 10:55 AM > >To: mobile-ip > >Cc: Peter.Dahl > >Subject: RE: [mobile-ip] Heterogeneous Handover - How Would it Work? > > > > > >Clearly, you are mixing roaming with seamless mobility across > >heterogeneous > >access types. The Mobile IP WG does not deal with aspects related to > >roaming > >agreements between operators or administrative domains. That is NOT what > >this WG is about. > > > >-Basavaraj > > > >> -----Original Message----- > >> From: ext Dahl, Peter [mailto:Peter.Dahl@VerizonWireless.com] > >> Sent: Wednesday, August 08, 2001 1:53 PM > >> To: 'mobile-ip@sunroof.eng.sun.com' > >> Subject: RE: [mobile-ip] Heterogeneous Handover - How Would it Work? > >> > >> > >> ...not forgetting cdma2000. I am not aware of any work in > >> 3GPP2 or IEEE, > >> perhaps 3GPP ? > >> > >> Pete > >> > >> -----Original Message----- > >> From: Brad Casemore [mailto:bcasemore@home.com] > >> Sent: Wednesday, August 08, 2001 11:29 AM > >> To: mobile-ip@sunroof.eng.sun.com > >> Subject: RE: [mobile-ip] Heterogeneous Handover - How Would it Work? > >> > >> > >> If that is the case, then WECA's WISPr is dedicated to > >> 802.11b roaming, > >> while the ETSI has assigned a group to address GPRS roaming. > >> Is there a > >> group anywhere that is looking into the technical issues > >> associated with > >> heterogeneous network roaming (such as between, theoretically, 802.11b > >> WLANs and GPRS)? > >> > >> Brad > >> > >> > -----Original Message----- > >> > From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile- > >> > ip@sunroof.eng.sun.com] On Behalf Of James Kempf > >> > Sent: Wednesday, August 08, 2001 2:19 AM > >> > To: mobile-ip@sunroof.eng.sun.com; mobile-ip@sunroof.eng.sun.com > >> > Subject: Re: [mobile-ip] Heterogeneous Handover - How Would it Work? > >> > > >> > Pat, > >> > > >> > I think they already have such a standard and I believe it > >> only works > >> > with GPRS. > >> > > >> > jak > >> > > >> > >Also, I believe that ETSI is working on a standard called GRX for > >> GSM<- > >> > >802.11 > >> > >roaming. > >> > > > >> > >PatC > >> > >On Tue, Aug 07, 2001 at 09:32:58AM -0700, Dahl, Peter wrote: > >> > >> FYI, the Wireless ISPs (WISPs) are already talking about such > >> roaming > >> > >> issues. > >> > >> > >> > >> There appear to be 2 emerging forums for these discussions, one > >> under > >> > the > >> > >> auspices of WECA (http://www.weca.net) known as the WISPr group > >> ('r' > >> > being > >> > >> for roaming), the other a yet to be finalized 'WISP Forum' the > >> prime > >> > mover > >> > >> for which is a company in Luxembourg (www.excilan.com). > >> > >> > >> > >> Regards > >> > >> > >> > >> -----Original Message----- > >> > >> From: James Kempf [mailto:James.Kempf@Sun.COM] > >> > >> Sent: Tuesday, August 07, 2001 8:58 AM > >> > >> To: mobile-ip@sunroof.eng.sun.com; mobile-ip@sunroof.eng.sun.com > >> > >> Subject: Re: [mobile-ip] Heterogeneous Handover - How Would it > >> Work? > >> > >> > >> > >> > >> > >> >On the other hand, the home address must belong to some > >> ISP/operator. > >> > >> >That ISP must provide a home agent and an ip address, and a CoA > >> when > >> > the > >> > >> >MN is connected to other than the home subnet. Other > >> ISPs that are > >> > used > >> > >> >are only access providers, and would give the MN its > >> CoA. This of > >> > course > >> > >> >would cause political problems. Who are the ISPs that > >> are willing > >> to > >> > be > >> > >> >access providers only, and who will be providing home agent and > >> home > >> > >> >address as well? > >> > >> > > >> > >> > >> > >> This is an issue. What happens if you have one access provider on > >> > >> one interface, say the wCDMA interface, and another on > >> another, say > >> > 802.11? > >> > >> There are now in the US a growing number of 802.11 access > >> providers, > >> > >> and I can imagine someone with a laptop having a wCDMA modem and > >> > >> an 802.11 card. > >> > >> > >> > >> Maybe something like the "roaming consortia" that have sprung up > >> > >> around ISP access might evolve, but the protocol > >> design/engineering > >> > >> issue is whether there is any additional work (such as the NAI in > >> > >> the roaming consortia example) needed to enable sharing of a home > >> > >> address among interfaces for which different ISPs are > >> responsible. > >> > >> > >> > >> Something like SUCV, that would allow an ISP to cryptographically > >> > identify > >> > >> to what other ISP an address belonged, might be useful in this > >> context. > >> > >> > >> > >> jak > >> > From owner-mobile-ip@sunroof.eng.sun.com Sat Aug 11 12:56:38 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07383 for ; Sat, 11 Aug 2001 12:56:38 -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 JAA21492; Sat, 11 Aug 2001 09:57:36 -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 JAA10324; Sat, 11 Aug 2001 09:57:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7BGtwP27831 for mobile-ip-dist; Sat, 11 Aug 2001 09:55:58 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7BGtsD27824 for ; Sat, 11 Aug 2001 09:55:54 -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 JAA10270 for ; Sat, 11 Aug 2001 09:56:05 -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 KAA18959 for ; Sat, 11 Aug 2001 10:56:02 -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 f7BGu6i29745 for ; Sat, 11 Aug 2001 11:56:06 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Sat, 11 Aug 2001 11:55:47 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.1600); Sat, 11 Aug 2001 11:55:47 -0500 content-class: urn:content-classes:message Subject: RE: [mobile-ip] Heterogeneous Handover - where do i look Date: Sat, 11 Aug 2001 11:55:46 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF440861E4@daebe007.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [mobile-ip] Heterogeneous Handover - where do i look X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 Thread-Index: AcEhubrW1mPK4o2sEdWBSQBQi2X+DwAzEy9w To: Cc: X-OriginalArrivalTime: 11 Aug 2001 16:55:47.0209 (UTC) FILETIME=[77B04F90:01C12286] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f7BGtsD27825 Sender: owner-mobile-ip@sunroof.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 > > Coming back to the question of handover across heterogeneous wireless > networks. Can anyone advise me as to where i should look at? > We are seeing a desire for handover between 802.11 and GPRS > networks. Is there any group looking at the feasibility of this ? > > Thanks in advance > Taking a very simplistic approach (and ignoring all the lower layer complexities), and assuming that you have Mobile IP client in your MN, an FA in your GGSN and MIPv4 support in the WLAN (FA in the WLAN), you could accomplish a handoff between the two based on the low-latency handoff solution (current WG I-D) between the two networks. However you need to deal with the underlying complexities of L2 triggers and a MN which is capable of both interfaces etc. -Basavaraj > Anil Doradla > SBC- Technology Resources, Inc. > Austin, TX-78727 > > > -----Original Message----- > From: James Kempf [mailto:James.Kempf@sun.com] > Sent: Friday, August 10, 2001 3:57 AM > To: mobile-ip@sunroof.eng.sun.com; mobile-ip@sunroof.eng.sun.com > Cc: Peter.Dahl > Subject: RE: [mobile-ip] Heterogeneous Handover - How Would it Work? > > > Glenn, > > I think Raj is right on here, sorry. There are enough technical issues > involved in getting MIP to be deployable that the MIP group really > needs to focus on. An example is this NAT question. > > If there are any operational issues involved in handover > between operators > that > need resolution, they should probably be handled in a separate working > group, like ROAMOPS. An example of such an issue might be advertising > access routers between operators using something like the Seamoby > CAR discovery protocol, which is just now getting off the ground. > > jak > >Raj, > > > >That's like saying that BGP doesn't deal with the routing > policy related to > >business relationships between the owners of autonomous > systems. You are > >shoe-holing the group into only dealing with an enterprise - not the > >Internet. > > > >-----Original Message----- > >From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com] > >Sent: Thursday, August 09, 2001 10:55 AM > >To: mobile-ip > >Cc: Peter.Dahl > >Subject: RE: [mobile-ip] Heterogeneous Handover - How Would it Work? > > > > > >Clearly, you are mixing roaming with seamless mobility across > >heterogeneous > >access types. The Mobile IP WG does not deal with aspects related to > >roaming > >agreements between operators or administrative domains. That > is NOT what > >this WG is about. > > > >-Basavaraj > > > >> -----Original Message----- > >> From: ext Dahl, Peter [mailto:Peter.Dahl@VerizonWireless.com] > >> Sent: Wednesday, August 08, 2001 1:53 PM > >> To: 'mobile-ip@sunroof.eng.sun.com' > >> Subject: RE: [mobile-ip] Heterogeneous Handover - How > Would it Work? > >> > >> > >> ...not forgetting cdma2000. I am not aware of any work in > >> 3GPP2 or IEEE, > >> perhaps 3GPP ? > >> > >> Pete > >> > >> -----Original Message----- > >> From: Brad Casemore [mailto:bcasemore@home.com] > >> Sent: Wednesday, August 08, 2001 11:29 AM > >> To: mobile-ip@sunroof.eng.sun.com > >> Subject: RE: [mobile-ip] Heterogeneous Handover - How > Would it Work? > >> > >> > >> If that is the case, then WECA's WISPr is dedicated to > >> 802.11b roaming, > >> while the ETSI has assigned a group to address GPRS roaming. > >> Is there a > >> group anywhere that is looking into the technical issues > >> associated with > >> heterogeneous network roaming (such as between, > theoretically, 802.11b > >> WLANs and GPRS)? > >> > >> Brad > >> > >> > -----Original Message----- > >> > From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile- > >> > ip@sunroof.eng.sun.com] On Behalf Of James Kempf > >> > Sent: Wednesday, August 08, 2001 2:19 AM > >> > To: mobile-ip@sunroof.eng.sun.com; mobile-ip@sunroof.eng.sun.com > >> > Subject: Re: [mobile-ip] Heterogeneous Handover - How > Would it Work? > >> > > >> > Pat, > >> > > >> > I think they already have such a standard and I believe it > >> only works > >> > with GPRS. > >> > > >> > jak > >> > > >> > >Also, I believe that ETSI is working on a standard > called GRX for > >> GSM<- > >> > >802.11 > >> > >roaming. > >> > > > >> > >PatC > >> > >On Tue, Aug 07, 2001 at 09:32:58AM -0700, Dahl, Peter wrote: > >> > >> FYI, the Wireless ISPs (WISPs) are already talking about such > >> roaming > >> > >> issues. > >> > >> > >> > >> There appear to be 2 emerging forums for these > discussions, one > >> under > >> > the > >> > >> auspices of WECA (http://www.weca.net) known as the > WISPr group > >> ('r' > >> > being > >> > >> for roaming), the other a yet to be finalized 'WISP Forum' the > >> prime > >> > mover > >> > >> for which is a company in Luxembourg (www.excilan.com). > >> > >> > >> > >> Regards > >> > >> > >> > >> -----Original Message----- > >> > >> From: James Kempf [mailto:James.Kempf@Sun.COM] > >> > >> Sent: Tuesday, August 07, 2001 8:58 AM > >> > >> To: mobile-ip@sunroof.eng.sun.com; > mobile-ip@sunroof.eng.sun.com > >> > >> Subject: Re: [mobile-ip] Heterogeneous Handover - How Would it > >> Work? > >> > >> > >> > >> > >> > >> >On the other hand, the home address must belong to some > >> ISP/operator. > >> > >> >That ISP must provide a home agent and an ip > address, and a CoA > >> when > >> > the > >> > >> >MN is connected to other than the home subnet. Other > >> ISPs that are > >> > used > >> > >> >are only access providers, and would give the MN its > >> CoA. This of > >> > course > >> > >> >would cause political problems. Who are the ISPs that > >> are willing > >> to > >> > be > >> > >> >access providers only, and who will be providing > home agent and > >> home > >> > >> >address as well? > >> > >> > > >> > >> > >> > >> This is an issue. What happens if you have one access > provider on > >> > >> one interface, say the wCDMA interface, and another on > >> another, say > >> > 802.11? > >> > >> There are now in the US a growing number of 802.11 access > >> providers, > >> > >> and I can imagine someone with a laptop having a > wCDMA modem and > >> > >> an 802.11 card. > >> > >> > >> > >> Maybe something like the "roaming consortia" that > have sprung up > >> > >> around ISP access might evolve, but the protocol > >> design/engineering > >> > >> issue is whether there is any additional work (such > as the NAI in > >> > >> the roaming consortia example) needed to enable > sharing of a home > >> > >> address among interfaces for which different ISPs are > >> responsible. > >> > >> > >> > >> Something like SUCV, that would allow an ISP to > cryptographically > >> > identify > >> > >> to what other ISP an address belonged, might be useful in this > >> context. > >> > >> > >> > >> jak > >> > From owner-mobile-ip@sunroof.eng.sun.com Sat Aug 11 15:17:39 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08302 for ; Sat, 11 Aug 2001 15:17: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 NAA11261; Sat, 11 Aug 2001 13:18: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 MAA01166; Sat, 11 Aug 2001 12:18:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7BJH6i28057 for mobile-ip-dist; Sat, 11 Aug 2001 12:17:06 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7BJH3D28050 for ; Sat, 11 Aug 2001 12:17: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 MAA10555 for ; Sat, 11 Aug 2001 12:17:13 -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 MAA13435 for ; Sat, 11 Aug 2001 12:17:12 -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 f7BJHCQ12316 for ; Sat, 11 Aug 2001 12:17: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 ACK00290; Sat, 11 Aug 2001 12:17:10 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA16596; Sat, 11 Aug 2001 12:17:10 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15221.33974.611899.864341@thomasm-u1.cisco.com> Date: Sat, 11 Aug 2001 12:17:10 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Piggybacking In-Reply-To: <85AA7486A2C1D411BCA20000F8073E430308AC97@crchy271.us.nortel.com> References: <85AA7486A2C1D411BCA20000F8073E430308AC97@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, > > Please explain in more detail why you believe the performance would be > better without piggybacking. I would suspect the performance to be better > with piggybacking. It obviously depends on the particular link layer. However, for one example that I'm pretty familiar with -- DOCSIS cable -- it would better to separate them into two packets because you would then be able to reap the benefit of payload header supression (PHS) as well as use concatenation to place both packets on the same upstream grant request. > I would also have some severe reservations about having a snooping ROHC > compression strategy drive the more pure IP standard. I don't understand what you mean here. ROHC would be greatly complicated if it had to consider piggybacking too. If we separate them, it could be made to look like a normal UDP packet which ROHC already knows how to compress. Mike From owner-mobile-ip@sunroof.eng.sun.com Sun Aug 12 04:23:33 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09982 for ; Sun, 12 Aug 2001 04:23: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 CAA25940; Sun, 12 Aug 2001 02:24: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 BAA04359; Sun, 12 Aug 2001 01:23:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7C8MsA28684 for mobile-ip-dist; Sun, 12 Aug 2001 01:22:54 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7C8MoD28677 for ; Sun, 12 Aug 2001 01:22: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 BAA04330 for ; Sun, 12 Aug 2001 01:23:01 -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 BAA15526 for ; Sun, 12 Aug 2001 01:23:00 -0700 (PDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (motgate 2.1) with ESMTP id BAA26294 for ; Sun, 12 Aug 2001 01:23:00 -0700 (MST)] Received: [from test9.crm.mot.com (zfr24-sr2-17.corp.mot.com [140.101.145.17]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id BAA13702 for ; Sun, 12 Aug 2001 01:22:58 -0700 (MST)] Received: from test9.crm.mot.com.crm.mot.com (localhost [127.0.0.1]) by test9.crm.mot.com (8.9.3/8.9.3) with ESMTP id KAA01359 for ; Sun, 12 Aug 2001 10:22:19 +0200 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile Routers: Why is P bit needed? References: <3B73AAC0.72031B8@Kniveton.com> From: Alexandru Petrescu Date: 12 Aug 2001 09:44:06 +0200 In-Reply-To: <3B73AAC0.72031B8@Kniveton.com> 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: 17 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: "T.J. Kniveton" writes: > What is the need for a Prefix Scope Registration bit? I can not > think of a case where a MR would have to include a Prefix Scope > extension on a BU and wouldn't want it to be processed. Isn't the > inclusion of said extension, or not, tantamount to indicating its > presence with the P bit? I think yes, having a Mobile Network Prefix Sub-Option type set aside as a distinctive value eliminates the need for the P bit. Moreover, I think it's better to extend the BU first with specific sub-options and to touch the Reservd field as late as possible. Other parts of the draft rely a lot on this P bit, but I think the P bit could simply be deduced from the presence of the respective sub-option type. Alex From owner-mobile-ip@sunroof.eng.sun.com Sun Aug 12 09:10:49 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15035 for ; Sun, 12 Aug 2001 09:10: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 GAA26348; Sun, 12 Aug 2001 06:11:42 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA13277; Sun, 12 Aug 2001 06:09:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7CD8fZ29042 for mobile-ip-dist; Sun, 12 Aug 2001 06:08:41 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7CD8cD29035 for ; Sun, 12 Aug 2001 06:08:38 -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 GAA13877 for ; Sun, 12 Aug 2001 06:08:48 -0700 (PDT) Received: from m2.bezeqint.net (m2.bezeqint.net [192.115.106.47]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA02327 for ; Sun, 12 Aug 2001 07:08:44 -0600 (MDT) Received: from nana (clnt-7163.bezeqint.net [212.179.7.163]) by m2.bezeqint.net (Mirapoint) with ESMTP id AEZ04384; Sun, 12 Aug 2001 16:08:43 +0300 (IDT) From: "Yaniv Bargury" To: Subject: RE: [mobile-ip] Heterogeneous Handover - where do i look Date: Sun, 12 Aug 2001 16:11:32 +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) Importance: Normal In-Reply-To: <000f01c1222e$b49b6f50$11a1024b@zbin> 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 Another possibility is roaming between wired internet to wireless. > -----Original Message----- > From: owner-mobile-ip@sunroof.eng.sun.com > [mailto:owner-mobile-ip@sunroof.eng.sun.com]On Behalf Of zb > Sent: Sat, August 11, 2001 8:28 AM > To: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Heterogeneous Handover - where do i look > > > Another possible use may be roaming between GPRS and bluetooth. > For example, > in a building, a cell phone can access internet with bluetooth. > When it is > out of the building, the internet access can be through GPRS > > zb > > ----- Original Message ----- > From: "Doradla, Anil" > To: > Sent: Saturday, August 11, 2001 1:28 AM > Subject: [mobile-ip] Heterogeneous Handover - where do i look > > > > Coming back to the question of handover across heterogeneous wireless > > networks. Can anyone advise me as to where i should look at? > > We are seeing a desire for handover between 802.11 and GPRS > networks. Is > > there any group looking at the feasibility of this ? > > > > Thanks in advance > > > > Anil Doradla > > SBC- Technology Resources, Inc. > > Austin, TX-78727 > > > > > > -----Original Message----- > > From: James Kempf [mailto:James.Kempf@sun.com] > > Sent: Friday, August 10, 2001 3:57 AM > > To: mobile-ip@sunroof.eng.sun.com; mobile-ip@sunroof.eng.sun.com > > Cc: Peter.Dahl > > Subject: RE: [mobile-ip] Heterogeneous Handover - How Would it Work? > > > > > > Glenn, > > > > I think Raj is right on here, sorry. There are enough technical issues > > involved in getting MIP to be deployable that the MIP group really > > needs to focus on. An example is this NAT question. > > > > If there are any operational issues involved in handover > between operators > > that > > need resolution, they should probably be handled in a separate working > > group, like ROAMOPS. An example of such an issue might be advertising > > access routers between operators using something like the Seamoby > > CAR discovery protocol, which is just now getting off the ground. > > > > jak > > >Raj, > > > > > >That's like saying that BGP doesn't deal with the routing > policy related > to > > >business relationships between the owners of autonomous > systems. You are > > >shoe-holing the group into only dealing with an enterprise - not the > > >Internet. > > > > > >-----Original Message----- > > >From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com] > > >Sent: Thursday, August 09, 2001 10:55 AM > > >To: mobile-ip > > >Cc: Peter.Dahl > > >Subject: RE: [mobile-ip] Heterogeneous Handover - How Would it Work? > > > > > > > > >Clearly, you are mixing roaming with seamless mobility across > > >heterogeneous > > >access types. The Mobile IP WG does not deal with aspects related to > > >roaming > > >agreements between operators or administrative domains. That > is NOT what > > >this WG is about. > > > > > >-Basavaraj > > > > > >> -----Original Message----- > > >> From: ext Dahl, Peter [mailto:Peter.Dahl@VerizonWireless.com] > > >> Sent: Wednesday, August 08, 2001 1:53 PM > > >> To: 'mobile-ip@sunroof.eng.sun.com' > > >> Subject: RE: [mobile-ip] Heterogeneous Handover - How Would it Work? > > >> > > >> > > >> ...not forgetting cdma2000. I am not aware of any work in > > >> 3GPP2 or IEEE, > > >> perhaps 3GPP ? > > >> > > >> Pete > > >> > > >> -----Original Message----- > > >> From: Brad Casemore [mailto:bcasemore@home.com] > > >> Sent: Wednesday, August 08, 2001 11:29 AM > > >> To: mobile-ip@sunroof.eng.sun.com > > >> Subject: RE: [mobile-ip] Heterogeneous Handover - How Would it Work? > > >> > > >> > > >> If that is the case, then WECA's WISPr is dedicated to > > >> 802.11b roaming, > > >> while the ETSI has assigned a group to address GPRS roaming. > > >> Is there a > > >> group anywhere that is looking into the technical issues > > >> associated with > > >> heterogeneous network roaming (such as between, > theoretically, 802.11b > > >> WLANs and GPRS)? > > >> > > >> Brad > > >> > > >> > -----Original Message----- > > >> > From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile- > > >> > ip@sunroof.eng.sun.com] On Behalf Of James Kempf > > >> > Sent: Wednesday, August 08, 2001 2:19 AM > > >> > To: mobile-ip@sunroof.eng.sun.com; mobile-ip@sunroof.eng.sun.com > > >> > Subject: Re: [mobile-ip] Heterogeneous Handover - How > Would it Work? > > >> > > > >> > Pat, > > >> > > > >> > I think they already have such a standard and I believe it > > >> only works > > >> > with GPRS. > > >> > > > >> > jak > > >> > > > >> > >Also, I believe that ETSI is working on a standard called GRX for > > >> GSM<- > > >> > >802.11 > > >> > >roaming. > > >> > > > > >> > >PatC > > >> > >On Tue, Aug 07, 2001 at 09:32:58AM -0700, Dahl, Peter wrote: > > >> > >> FYI, the Wireless ISPs (WISPs) are already talking about such > > >> roaming > > >> > >> issues. > > >> > >> > > >> > >> There appear to be 2 emerging forums for these discussions, one > > >> under > > >> > the > > >> > >> auspices of WECA (http://www.weca.net) known as the WISPr group > > >> ('r' > > >> > being > > >> > >> for roaming), the other a yet to be finalized 'WISP Forum' the > > >> prime > > >> > mover > > >> > >> for which is a company in Luxembourg (www.excilan.com). > > >> > >> > > >> > >> Regards > > >> > >> > > >> > >> -----Original Message----- > > >> > >> From: James Kempf [mailto:James.Kempf@Sun.COM] > > >> > >> Sent: Tuesday, August 07, 2001 8:58 AM > > >> > >> To: mobile-ip@sunroof.eng.sun.com; > mobile-ip@sunroof.eng.sun.com > > >> > >> Subject: Re: [mobile-ip] Heterogeneous Handover - How Would it > > >> Work? > > >> > >> > > >> > >> > > >> > >> >On the other hand, the home address must belong to some > > >> ISP/operator. > > >> > >> >That ISP must provide a home agent and an ip address, > and a CoA > > >> when > > >> > the > > >> > >> >MN is connected to other than the home subnet. Other > > >> ISPs that are > > >> > used > > >> > >> >are only access providers, and would give the MN its > > >> CoA. This of > > >> > course > > >> > >> >would cause political problems. Who are the ISPs that > > >> are willing > > >> to > > >> > be > > >> > >> >access providers only, and who will be providing home > agent and > > >> home > > >> > >> >address as well? > > >> > >> > > > >> > >> > > >> > >> This is an issue. What happens if you have one access > provider on > > >> > >> one interface, say the wCDMA interface, and another on > > >> another, say > > >> > 802.11? > > >> > >> There are now in the US a growing number of 802.11 access > > >> providers, > > >> > >> and I can imagine someone with a laptop having a wCDMA > modem and > > >> > >> an 802.11 card. > > >> > >> > > >> > >> Maybe something like the "roaming consortia" that have > sprung up > > >> > >> around ISP access might evolve, but the protocol > > >> design/engineering > > >> > >> issue is whether there is any additional work (such as > the NAI in > > >> > >> the roaming consortia example) needed to enable > sharing of a home > > >> > >> address among interfaces for which different ISPs are > > >> responsible. > > >> > >> > > >> > >> Something like SUCV, that would allow an ISP to > cryptographically > > >> > identify > > >> > >> to what other ISP an address belonged, might be useful in this > > >> context. > > >> > >> > > >> > >> jak > > >> > > > From owner-mobile-ip@sunroof.eng.sun.com Sun Aug 12 12:50:14 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17272 for ; Sun, 12 Aug 2001 12:50: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 JAA08722; Sun, 12 Aug 2001 09:51: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 JAA27797; Sun, 12 Aug 2001 09:50:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7CGnwB29358 for mobile-ip-dist; Sun, 12 Aug 2001 09:49:58 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7CGnsD29351 for ; Sun, 12 Aug 2001 09:49: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 JAA06283 for ; Sun, 12 Aug 2001 09:50:04 -0700 (PDT) Received: from elchara.qualcomm.com (elchara.qualcomm.com [129.46.216.81]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA23938 for ; Sun, 12 Aug 2001 09:49:55 -0700 (PDT) Received: from MLIOY2K.qualcomm.com (r-cserve-host115.qualcomm.com [129.46.62.115]) by elchara.qualcomm.com (8.8.5/1.4/8.7.2/1.12) with ESMTP id JAA18149; Sun, 12 Aug 2001 09:49:50 -0700 (PDT) Message-Id: <4.3.1.2.20010811154415.031f77d0@mail1.qualcomm.com> X-Sender: mlioy@mail1.qualcomm.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Sun, 12 Aug 2001 18:38:37 +0200 To: mobile-ip@sunroof.eng.sun.com From: Marcello Lioy Subject: Re: [mobile-ip] RFC2002bis Cc: charliep@iprg.nokia.com, nish@qualcomm.com, jeffd@qualcomm.com, susiea@qualcomm.com In-Reply-To: <3B748398.C5C27797@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: At 02:00 8/11/2001, you wrote: >Hello folks, > >A new version of RFC2002bis has been prepared. According >to the most recent guidance given by the IESG, a change in >the mandated authentication algorithm has been strongly >suggested. Unfortunately, this will have the effect of >causing almost all previous implementations of Mobile IP >for IPv4 to become incompatible with the new specification. > >The working group chairs recently asked the working group, >by way of the mailing list, whether this incompatible >change would be acceptable. The discussion was quite >limited, somewhat to my surprise. This has been taken >as evidence that going with HMAC_MD5 is more-or-less >O.K. Thus, it has been decided to go ahead with the >change. On the other hand, it is conceivable that not >all interested parties have been notified of the possible >change, or have had time to reply. If there are dissenters >to this change, now would be the time to express that >opinion. This could be an issue. TIA/EIA IS-835 (the packet data standard for CDMA2000) is going to be deployed in North America this fall. It specifies the user of RFC 2002. There are two major areas of incompatibilty in RFC 2002bis: 1) the inclusion of the SPI in the auth calculation 2) HMAC_MD5 if that is decided on. Both of these things break 2002 - which means that the mobiles and infrastructure that are 835 compliant will be obsoleted when RFC 2002 is obsoleted. I think that both of these fixes are good (the SPI was a bug that slipped through in 2002, and HMAC sounds like it is less vulnerable than vanila MD5) but they could cause issues in these planned network deployments. ----------------------------------- Marcello (Wandering through France) From owner-mobile-ip@sunroof.eng.sun.com Sun Aug 12 15:15:36 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18109 for ; Sun, 12 Aug 2001 15:15: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 NAA27256; Sun, 12 Aug 2001 13:16: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 MAA15615; Sun, 12 Aug 2001 12:15:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7CJEB629554 for mobile-ip-dist; Sun, 12 Aug 2001 12:14:11 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7CJE7D29547 for ; Sun, 12 Aug 2001 12:14: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 MAA27355 for ; Sun, 12 Aug 2001 12:14:17 -0700 (PDT) Received: from tsbgw.wide.toshiba.co.jp (tsbgw.wide.toshiba.co.jp [202.249.10.123]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA24265 for ; Sun, 12 Aug 2001 12:14:16 -0700 (PDT) Received: from maltese.wide.toshiba.co.jp (maltese.wide.toshiba.co.jp [202.249.10.99]) by tsbgw.wide.toshiba.co.jp (8.9.3/8.9.1) with ESMTP id EAA22163 for ; Mon, 13 Aug 2001 04:14:14 +0900 (JST) Received: from isl.rdc.toshiba.co.jp (spiffy.isl.rdc.toshiba.co.jp [133.196.10.10]) by maltese.wide.toshiba.co.jp (8.9.1/8.9.1) with ESMTP id EAA12109 for ; Mon, 13 Aug 2001 04:14:14 +0900 (JST) Received: from tanuki (kddlos0140.mobile.toshiba.co.jp [10.16.11.59]) by isl.rdc.toshiba.co.jp (8.9.3/8.9.3/8.4) with SMTP id EAA27180; Mon, 13 Aug 2001 04:14:11 +0900 (JST) Message-Id: <200108121914.EAA27180@isl.rdc.toshiba.co.jp> Date: Mon, 13 Aug 2001 04:13:01 +0900 From: Yoshiyuki Tsuda Subject: Re: [mobile-ip] RFC2002bis To: mobile-ip@sunroof.eng.sun.com Organization: Corporate R&D Center, Toshiba Corporation In-Reply-To: <3B748398.C5C27797@iprg.nokia.com> References: <3B748398.C5C27797@iprg.nokia.com> X-Mailer: Datula version 1.51.08.01 for Windows 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, Thank you for your so-far enormous efforts on MIPv4. I have two comments embedded in the following: at Fri, 10 Aug 2001 18:00:08 -0700, Charlie Perkins wrote: >Hello folks, > >A new version of RFC2002bis has been prepared. According >to the most recent guidance given by the IESG, a change in >the mandated authentication algorithm has been strongly >suggested. Unfortunately, this will have the effect of >causing almost all previous implementations of Mobile IP >for IPv4 to become incompatible with the new specification. > >The working group chairs recently asked the working group, >by way of the mailing list, whether this incompatible >change would be acceptable. The discussion was quite >limited, somewhat to my surprise. This has been taken >as evidence that going with HMAC_MD5 is more-or-less >O.K. Thus, it has been decided to go ahead with the >change. On the other hand, it is conceivable that not >all interested parties have been notified of the possible >change, or have had time to reply. If there are dissenters >to this change, now would be the time to express that >opinion. > >That is the most important point of this note. > >Another factor in the discussion concerns the acceptability >of RFC2002bis as a basis for moving Mobile IPv4 to Draft >Standard. I have been told that, contrary to my previous >understanding, a version of RFC2002bis could be promoted >to Draft Standard even if it is first published with >the several options which have not been tested for >interoperability. These options are: >1. 'R' bit to the Agent Advertisement From my memory, we had checked 'R' bit at the Testathon, thanks to Steve. >2. 'S' bit to Registration Request >3. Prefix Lengths Extension to Agent Advertisement Also, about Prefix Length Extension, we had tested it at the 3rd bakeoff at Sun, thanks to Pat. But, I agree it is the best&last time to sum up tested or not-tested functions, and recycle untested bits. >4. Possibly other options that may come under discussion > (I don't know of any in this class). >I'll call these the "unpromotable options" > >On the other hand, it is likely that the IESG will not >promote Mobile IPv4 to Draft Standard unless the authentication >algorithm has been changed to HMAC_MD5. This might affect 3GPP2 process, I'm afraid. I believe Tom Hiller has received your email, so he can reply if the above may affect 3GPP2 or not. Thanks so many. -Yoshi From owner-mobile-ip@sunroof.eng.sun.com Sun Aug 12 16:24:56 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18584 for ; Sun, 12 Aug 2001 16:24: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 NAA21850; Sun, 12 Aug 2001 13:25: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 NAA00345; Sun, 12 Aug 2001 13:25:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7CKNk429691 for mobile-ip-dist; Sun, 12 Aug 2001 13:23:46 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7CKNgD29684 for ; Sun, 12 Aug 2001 13:23:42 -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 NAA00222 for ; Sun, 12 Aug 2001 13:23:52 -0700 (PDT) From: Basavaraj.Patil@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 NAA23780 for ; Sun, 12 Aug 2001 13:23:51 -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 f7CKOpI22677 for ; Sun, 12 Aug 2001 15:24:51 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Sun, 12 Aug 2001 15:23:49 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.1600); Sun, 12 Aug 2001 15:23:45 -0500 content-class: urn:content-classes:message Subject: RE: [mobile-ip] RFC2002bis Date: Sun, 12 Aug 2001 15:23:45 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF440861EC@daebe007.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [mobile-ip] RFC2002bis X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 Thread-Index: AcEjTwsxOX7IJ48zEdWpVgBQi2kYTQAHa+0Q To: Cc: X-OriginalArrivalTime: 12 Aug 2001 20:23:45.0831 (UTC) FILETIME=[AFF0AB70:01C1236C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f7CKNhD29685 Sender: owner-mobile-ip@sunroof.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, Some comments inline: >>Hello folks, >> >>A new version of RFC2002bis has been prepared. According >>to the most recent guidance given by the IESG, a change in >>the mandated authentication algorithm has been strongly >>suggested. Unfortunately, this will have the effect of >>causing almost all previous implementations of Mobile IP >>for IPv4 to become incompatible with the new specification. >> >>The working group chairs recently asked the working group, >>by way of the mailing list, whether this incompatible >>change would be acceptable. The discussion was quite >>limited, somewhat to my surprise. This has been taken >>as evidence that going with HMAC_MD5 is more-or-less >>O.K. Thus, it has been decided to go ahead with the >>change. On the other hand, it is conceivable that not >>all interested parties have been notified of the possible >>change, or have had time to reply. If there are dissenters >>to this change, now would be the time to express that >>opinion. > >This could be an issue. TIA/EIA IS-835 (the packet data standard for >CDMA2000) is going to be deployed in North America this fall. It specifies >the user of RFC 2002. There are two major areas of incompatibilty in RFC >2002bis: >1) the inclusion of the SPI in the auth calculation >2) HMAC_MD5 if that is decided on. > So IS-835 implemantations would be compliant with RFC2002. The SPI interpretation in 2002 was a problem which was one of the reasons for working on 2002bis. >Both of these things break 2002 - which means that the mobiles and >infrastructure that are 835 compliant will be obsoleted when RFC 2002 is >obsoleted. > Well, the IS835 implementations would still be compliant with RFC2002, which would be obsoleted by a new RFC. The point is they would still be compliant with RFC2002, but NOT the new RFC which supercedes it. >I think that both of these fixes are good (the SPI was a bug that slipped >through in 2002, and HMAC sounds like it is less vulnerable than vanila >MD5) but they could cause issues in these planned network >deployments. The IS-835 network is not yet deployed on a commercial basis. And you seem to agree that the above fixes would be good for the spec. Would make sense to consider making these changes now than later when it is deployed. >----------------------------------- >Marcello (Wandering through France) > -Basavaraj From owner-mobile-ip@sunroof.eng.sun.com Sun Aug 12 19:12:17 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19678 for ; Sun, 12 Aug 2001 19:12: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 RAA06174; Sun, 12 Aug 2001 17:13: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 QAA22701; Sun, 12 Aug 2001 16:12:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7CNBv829865 for mobile-ip-dist; Sun, 12 Aug 2001 16:11:58 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7CNBsD29858 for ; Sun, 12 Aug 2001 16:11: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 QAA14492 for ; Sun, 12 Aug 2001 16:12:04 -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 QAA10208 for ; Sun, 12 Aug 2001 16:12:02 -0700 (PDT) Received: from cychong (a22416 [165.213.224.16]) by telecom.samsung.co.kr (8.9.3/8.9.3) with SMTP id IAA11326 for ; Mon, 13 Aug 2001 08:14:42 +0900 (KST) Message-ID: <000801c12384$c9e4e100$10e0d5a5@cychong> From: "Chae-yong Chong" To: References: <697DAA22C5004B4596E033803A7CEF440861EC@daebe007.NOE.Nokia.com> Subject: Re: [mobile-ip] RFC2002bis Date: Mon, 13 Aug 2001 08:16:16 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.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 f7CNBsD29859 Sender: owner-mobile-ip@sunroof.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. This is just an information for you. The IS-835 network is already deployed in Korea on a commercial basis. If you asked that how many subscribers are using Mobile IP service, I am sorry not to give you an exact answer. That answer could be given by some guys of Operators, SK Telecom ro KTF :-) I think you all just consider the situation of North American. :-( As far as I know, there is no commercial product for Mobile Node software. Okay. I agree that you could assume that the current deployment in Korea could be regarded to a nothing. (If the number of Mobile IP service subscriber is just trivial) I just write this message to let you know that IS-835 is ALREADY deployed somewhere :-) Chae-yong > The IS-835 network is not yet deployed on a commercial basis. And you > seem to agree that the above fixes would be good for the spec. Would > make sense to consider making these changes now than later when it is > deployed. > > >----------------------------------- > >Marcello (Wandering through France) > > > > -Basavaraj > > From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 13 03:07:58 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11595 for ; Mon, 13 Aug 2001 03:07: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 AAA13851; Mon, 13 Aug 2001 00:08:57 -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 AAA18763; Mon, 13 Aug 2001 00:08:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7D77Pi00309 for mobile-ip-dist; Mon, 13 Aug 2001 00:07:25 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7D77LD00301 for ; Mon, 13 Aug 2001 00:07:21 -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 AAA18705 for ; Mon, 13 Aug 2001 00:07:31 -0700 (PDT) Received: from elchara.qualcomm.com (elchara.qualcomm.com [129.46.216.81]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA24481 for ; Mon, 13 Aug 2001 00:07:21 -0700 (PDT) Received: from MLIOY2K.qualcomm.com (l-cserve-host127.qualcomm.com [129.46.63.127]) by elchara.qualcomm.com (8.8.5/1.4/8.7.2/1.12) with ESMTP id AAA18846; Mon, 13 Aug 2001 00:07:12 -0700 (PDT) Message-Id: <4.3.1.2.20010813085957.0177c4d0@mail1.qualcomm.com> X-Sender: mlioy@mail1.qualcomm.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Mon, 13 Aug 2001 09:05:20 +0200 To: Basavaraj.Patil@nokia.com, From: Marcello Lioy Subject: RE: [mobile-ip] RFC2002bis Cc: nish@qualcomm.com, jeffd@qualcomm.com, jwillkie@qualcomm.com, susiea@qualcomm.com In-Reply-To: <697DAA22C5004B4596E033803A7CEF440861EC@daebe007.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: At 22:23 8/12/2001, Basavaraj.Patil@nokia.com wrote: > >This could be an issue. TIA/EIA IS-835 (the packet data standard for > >CDMA2000) is going to be deployed in North America this fall. It >specifies > >the user of RFC 2002. There are two major areas of incompatibilty in >RFC > >2002bis: > >1) the inclusion of the SPI in the auth calculation > >2) HMAC_MD5 if that is decided on. > > > >So IS-835 implemantations would be compliant with RFC2002. The SPI >interpretation in 2002 was a problem which was one of the reasons for >working on 2002bis. This is true - however some of the network infrastructure vendors are following the letter of the law and not including the SPI. Once this is deployed (which will be soon), fixing it will be difficult. > >Both of these things break 2002 - which means that the mobiles and > >infrastructure that are 835 compliant will be obsoleted when RFC 2002 > >is obsoleted. > > > >Well, the IS835 implementations would still be compliant with RFC2002, >which would be obsoleted by a new RFC. The point is they would still >be compliant with RFC2002, but NOT the new RFC which supercedes it. True and since this is a closed system it is not all that dramatic - but it would be nice if it were "future proof." > >I think that both of these fixes are good (the SPI was a bug that slipped > >through in 2002, and HMAC sounds like it is less vulnerable than vanila > >MD5) but they could cause issues in these planned network > >deployments. > >The IS-835 network is not yet deployed on a commercial basis. And you >seem to agree that the above fixes would be good for the spec. Would >make sense to consider making these changes now than later when it is >deployed. While the network is not deployed commercially, North American deployment is expected before the end of this year, which is why I raised my concerns to the list. ----------------------------------- Marcello (Wandering through France) From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 13 04:50:39 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12404 for ; Mon, 13 Aug 2001 04:50: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 CAA06340; Mon, 13 Aug 2001 02:51: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 BAA17506; Mon, 13 Aug 2001 01:51:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7D8o7E00609 for mobile-ip-dist; Mon, 13 Aug 2001 01:50:07 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7D8o4D00602 for ; Mon, 13 Aug 2001 01:50: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 BAA13129 for ; Mon, 13 Aug 2001 01:50:14 -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 BAA25691 for ; Mon, 13 Aug 2001 01:50:13 -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 f7D8oFi19004 for ; Mon, 13 Aug 2001 03:50:15 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Mon, 13 Aug 2001 03:49:56 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.1600); Mon, 13 Aug 2001 03:49:52 -0500 content-class: urn:content-classes:message Subject: RE: [mobile-ip] RFC2002bis Date: Mon, 13 Aug 2001 03:49:59 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF440861F0@daebe007.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [mobile-ip] RFC2002bis X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 Thread-Index: AcEjhI8IJm6k249uEdWxLgAIx6TWeAAUER3Q To: Cc: X-OriginalArrivalTime: 13 Aug 2001 08:49:52.0946 (UTC) FILETIME=[EB385120:01C123D4] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f7D8o4D00603 Sender: owner-mobile-ip@sunroof.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. > >This is just an information for you. > Thanks for the update. >The IS-835 network is already deployed in Korea on a commercial basis. >If you asked that how many subscribers are using Mobile IP service, I am >sorry not to give you an exact answer. That answer could be given by >some guys of Operators, SK Telecom ro KTF :-) >I think you all just consider the situation of North American. :-( > Not necessarily. We are equally aware of developments in other regions :) >As far as I know, there is no commercial product for >Mobile Node software. Okay. I agree that you could assume that You mentioned above that the network is already operational. Yet there are no commercial products (terminals supporting MN software)? Can you elaborate what you mean by "commercial product for Mobile Node software"? >the current deployment in Korea could be regarded to a nothing. >(If the number of Mobile IP service subscriber is just trivial) >I just write this message to let you know that IS-835 is ALREADY >deployed somewhere :-) > >Chae-yong > -Basavaraj >> The IS-835 network is not yet deployed on a commercial basis. And you >> seem to agree that the above fixes would be good for the spec. Would >> make sense to consider making these changes now than later when it is >> deployed. >> >> >----------------------------------- >> >Marcello (Wandering through France) >> > >> >> -Basavaraj >> From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 13 07:06:18 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13646 for ; Mon, 13 Aug 2001 07:06: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 FAA03587; Mon, 13 Aug 2001 05:07:10 -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 EAA09923; Mon, 13 Aug 2001 04:06:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7DB5e200937 for mobile-ip-dist; Mon, 13 Aug 2001 04:05:40 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7DB5aD00930 for ; Mon, 13 Aug 2001 04:05: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 EAA26404 for ; Mon, 13 Aug 2001 04:05:45 -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 FAA03057 for ; Mon, 13 Aug 2001 05:05:42 -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 HAA13450; Mon, 13 Aug 2001 07:04:32 -0400 (EDT) Message-Id: <200108131104.HAA13450@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-roe-mobileip-updateauth-00.txt Date: Mon, 13 Aug 2001 07:04: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 : Authentication of Mobile IPv6 Binding Updates and Acknowledgments Author(s) : M. Roe Filename : draft-roe-mobileip-updateauth-00.txt Pages : 13 Date : 08-Aug-01 This memo describes four different protocols that MAY be used for authenticating Binding Update or Binding Acknowledgment destination options [5]. Each protocol provides a different level of security, ranging from no authentication to a challenge-response mechanism using digital signatures. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-roe-mobileip-updateauth-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-roe-mobileip-updateauth-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-roe-mobileip-updateauth-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: <20010809113459.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-roe-mobileip-updateauth-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-roe-mobileip-updateauth-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010809113459.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 13 07:06:50 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13672 for ; Mon, 13 Aug 2001 07:06:50 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA03830; Mon, 13 Aug 2001 05:07: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 EAA09976; Mon, 13 Aug 2001 04:07:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7DB6VI00955 for mobile-ip-dist; Mon, 13 Aug 2001 04:06:31 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7DB6RD00948; Mon, 13 Aug 2001 04:06: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 EAA26452; Mon, 13 Aug 2001 04:06:36 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA10979; Mon, 13 Aug 2001 05:06:42 -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 HAA13578; Mon, 13 Aug 2001 07:05:19 -0400 (EDT) Message-Id: <200108131105.HAA13578@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Subject: [mobile-ip] I-D ACTION:draft-engelstad-ngtrans-mipv4-over-mipv6-01.txt Date: Mon, 13 Aug 2001 07:05:18 -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-01.txt Pages : 21 Date : 09-Aug-01 This draft outlines how a dual stack mobile node can be reached and communicate by means of both IPv4 and IPv6, even in situations where the mobile node is in reach of only either IPv4 or IPv6 networks. A Dual Stack Mobility Agent accommodates mobility and translates between IPv4 and IPv6 traffic. It may operate as a mobility agent in its own right or as a module that relays traffic between existing single stack Mobile IPv4 and Mobile IPv6 home agents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-engelstad-ngtrans-mipv4-over-mipv6-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-engelstad-ngtrans-mipv4-over-mipv6-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-engelstad-ngtrans-mipv4-over-mipv6-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: <20010809115441.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-engelstad-ngtrans-mipv4-over-mipv6-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-engelstad-ngtrans-mipv4-over-mipv6-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010809115441.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 13 08:42:30 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17560 for ; Mon, 13 Aug 2001 08:42: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 FAA09084; Mon, 13 Aug 2001 05:43:24 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA16759; Mon, 13 Aug 2001 05:43:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7DCfga01286 for mobile-ip-dist; Mon, 13 Aug 2001 05:41:42 -0700 (PDT) Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.179.15]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7DCfcD01277 for ; Mon, 13 Aug 2001 05:41:38 -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 f7DCfe216364; Mon, 13 Aug 2001 14:41:40 +0200 (MET DST) Date: Mon, 13 Aug 2001 14:39:01 +0200 (CEST) From: Erik Nordmark Subject: Re: [mobile-ip] Mobile Routers support without optimization To: "T.J. Kniveton" Cc: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3B73A9C9.38C82250@Kniveton.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: > Putting aside route optimization and the processing of prefix scope > binding updates on the CN, the problem is greatly reduced. At the home > agent, there is already some configuration presumed, and deciding which > prefixes are assigned to which MRs (and hence, which PSBAs to accept) is > more feasible. In the worst case, if a HA does not discriminate in > accepting these bindings, the /4 hijacked prefix would only be forwarded > to the MN for packets generated internally by the HA (while acting as a > CN); however, packets will never show up on the home link destined for > the MN, since the upstream aggregation routers will not forward these > packets to the home link, but rather to the correct part of the network > where the /4 prefix really lives. I think you can solve the above without any prefixes in the BUs. The scenario I'm thinking about is something like a personal area network with a router at its edge - I carry the whole PAN including the router with me when I walk. When I'm at home the PAN router has adjancencies with other routers attached to the home link which it uses to exchange routing information about the subnet prefixes assigned to my PAN. When I move away from home it is sufficient for the PAN router to - send a binding update for its own address (which the other routers have as the nexthop in the routing tables). This BU will have the R-bit set so that NUD works. - tunnel all traffic from the PAN back to the home network. Thus the PAN router will continue to exchange reachability information with the routers on home network using the routing protocol (e.g. OSPF). All packets will be tunneled in both directions. The nodes in my PAN will not notice that they are moving. At least the above provides a basic level of support for this scenario. Erik From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 13 08:42:37 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17591 for ; Mon, 13 Aug 2001 08:42:36 -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 FAA09094; Mon, 13 Aug 2001 05:43: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 FAA16730; Mon, 13 Aug 2001 05:42:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7DCfoQ01293 for mobile-ip-dist; Mon, 13 Aug 2001 05:41:50 -0700 (PDT) Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.179.15]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7DCffD01285 for ; Mon, 13 Aug 2001 05:41:45 -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 f7DCfi216370; Mon, 13 Aug 2001 14:41:44 +0200 (MET DST) Date: Mon, 13 Aug 2001 14:39:05 +0200 (CEST) From: Erik Nordmark Subject: Re: [mobile-ip] Mobile Routers support without optimization To: Alexis_Olivereau-AAO011@email.mot.com Cc: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3B73B753.D3365C7E@crm.mot.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: > Actually Binding Updates for prefixes do not disable route optimization > feature. Clearly, the authorization process is trickier. It can however > be performed provided that it makes use of the knowledge the HA has > about the binding 'Mobile Prefix' / 'Mobile Router'. HA can then be > asked by the CN before CN updates its Binding Cache upon receiption of a > prefix BU. I don't understand how the CN checking with the HA solves the trust issue for using BUs to redirect whole prefixes. Example: I run a MN and a HA . My MN sends a BU for a /3 to a CN the fact that my MN says "yes" when the CN asks if the binding is ok. The redirection of a prefix must be related to the routing for that whole prefix going to the HA. In general you can't verify that this is the case for a prefix without actually sending packets to all IP addresses in the prefix and seeing that you get a response back from the HA. But, what problem are we really trying to solve by being able to send a BU for a whole prefix? This seems like optimizing something which is close to a non-problem. Erik From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 13 10:29:12 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21051 for ; Mon, 13 Aug 2001 10:29: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 IAA21141; Mon, 13 Aug 2001 08:29: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 HAA10590; Mon, 13 Aug 2001 07:29:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7DESSP01530 for mobile-ip-dist; Mon, 13 Aug 2001 07:28:28 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7DESOD01523 for ; Mon, 13 Aug 2001 07:28:24 -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 HAA00257 for ; Mon, 13 Aug 2001 07:28: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 IAA16210 for ; Mon, 13 Aug 2001 08:28:42 -0600 (MDT) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f7DESEN06332; Mon, 13 Aug 2001 16:28:15 +0200 (MEST) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id QAA20289; Mon, 13 Aug 2001 16:28:14 +0200 Message-ID: <3B77E391.1E9A5D34@era.ericsson.se> Date: Mon, 13 Aug 2001 16:26:25 +0200 From: Mattias Pettersson Organization: Ericsson Research X-Mailer: Mozilla 4.77 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com CC: "T.J. Kniveton" Subject: Re: [mobile-ip] Mobile Routers support without optimization 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 Erik, Erik Nordmark wrote: > I think you can solve the above without any prefixes in the BUs. > > The scenario I'm thinking about is something like a personal area network > with a router at its edge - I carry the whole PAN including the router > with me when I walk. > > When I'm at home the PAN router has adjancencies with other routers attached > to the home link which it uses to exchange routing information about the > subnet prefixes assigned to my PAN. > > When I move away from home it is sufficient for the PAN router to > - send a binding update for its own address (which the other routers > have as the nexthop in the routing tables). This BU will > have the R-bit set so that NUD works. > - tunnel all traffic from the PAN back to the home network. This is exactly what I pointed out to Thierry a while ago. If routing is consistent and transparent with regards to this home link, I also think that this is the ideal solution. However, Mobile IPv6 fails to be fully transparent when it comes to link-local addresses. Unfortunately, we couldn't make an agreement on how nodes would function. It is obviously implementation dependent whether the home agent will do binding cache lookup and routing table lookup in the correct order to allow this. I pointed out that a BSD home agent could probably work like described above, but Thierry shows in the draft that INRIA's MIPv6 code would not. > > Thus the PAN router will continue to exchange reachability information > with the routers on home network using the routing protocol (e.g. OSPF). > All packets will be tunneled in both directions. The nodes in my PAN > will not notice that they are moving. Routing protocols use link-local addresses, so this would fail (at least with today's specification of Mobile IPv6 and routing protocols). Maybe Mobile IPv6 should be changed to tunnel *all* packets. > > At least the above provides a basic level of support for this scenario. > > Erik /Mattias From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 13 10:58:37 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21483 for ; Mon, 13 Aug 2001 10:58:36 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA01492; Mon, 13 Aug 2001 07:59: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 HAA16624; Mon, 13 Aug 2001 07:59:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7DEw7A01671 for mobile-ip-dist; Mon, 13 Aug 2001 07:58:07 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7DEw3D01664 for ; Mon, 13 Aug 2001 07:58: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 HAA03618 for ; Mon, 13 Aug 2001 07:58:12 -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 HAA11741 for ; Mon, 13 Aug 2001 07:58:12 -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 f7DEwNn03662; Mon, 13 Aug 2001 07:58: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 ACL04837; Mon, 13 Aug 2001 07:58:11 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA17148; Mon, 13 Aug 2001 07:58:11 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15223.60162.967362.605180@thomasm-u1.cisco.com> Date: Mon, 13 Aug 2001 07:58:10 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Cc: "T.J. Kniveton" Subject: Re: [mobile-ip] Mobile Routers support without optimization In-Reply-To: References: <3B73A9C9.38C82250@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 Erik Nordmark writes: > Thus the PAN router will continue to exchange reachability information > with the routers on home network using the routing protocol (e.g. OSPF). > All packets will be tunneled in both directions. The nodes in my PAN > will not notice that they are moving. Sure. All you've done is managed to avoid the hard problem which is route optimization :-) Maybe this inevitable since the problem is obviously not a trivial one, but there are issues of reliabilty and robustness which need to be considered. The MR's home agent provides an additional single point of failure, so the fate sharing is wrong. For MIPv6, this is supposed to be a transient single point of failure (on the average case), so that seems like an acceptible design tradeoff. However, if we relegate MR's (which potentially subtend very large subnets for, oh say, planes or ships) to dog leg routing, we're actually *increasing* the desire for robust and optimal routing. As you add more layers of mobility, the path becomes more and more fragile which doesn't seem very satisfying. In fact, it starts to resemble the PSTN... Mike From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 13 11:06:03 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21611 for ; Mon, 13 Aug 2001 11:06: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 IAA05306; Mon, 13 Aug 2001 08:06: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 IAA17763; Mon, 13 Aug 2001 08:06:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7DF5xu01755 for mobile-ip-dist; Mon, 13 Aug 2001 08:05:59 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7DF5uD01748 for ; Mon, 13 Aug 2001 08:05:56 -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 IAA04839 for ; Mon, 13 Aug 2001 08:06:05 -0700 (PDT) Received: from elchara.qualcomm.com (elchara.qualcomm.com [129.46.216.81]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA06552 for ; Mon, 13 Aug 2001 09:06:13 -0600 (MDT) Received: from MLIOY2K.qualcomm.com (l-cserve-host20.qualcomm.com [129.46.63.20]) by elchara.qualcomm.com (8.8.5/1.4/8.7.2/1.12) with ESMTP id IAA19285; Mon, 13 Aug 2001 08:05:51 -0700 (PDT) Message-Id: <4.3.1.2.20010813170049.02eadf08@mail1.qualcomm.com> X-Sender: mlioy@mail1.qualcomm.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Mon, 13 Aug 2001 17:03:05 +0200 To: mobile-ip@sunroof.eng.sun.com, From: Marcello Lioy Subject: Re: [mobile-ip] RFC2002bis In-Reply-To: <000801c12384$c9e4e100$10e0d5a5@cychong> References: <697DAA22C5004B4596E033803A7CEF440861EC@daebe007.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: At 01:16 8/13/2001, Chae-yong Chong wrote: >Hi. > >This is just an information for you. > >The IS-835 network is already deployed in Korea on a commercial basis. >If you asked that how many subscribers are using Mobile IP service, I am >sorry not to give you an exact answer. That answer could be given by >some guys of Operators, SK Telecom ro KTF :-) >I think you all just consider the situation of North American. :-( I know for a fact that the current IS835 deployment in Korea does not support Mobile IP - this will change in short order, as the infrastructure will be upgraded, when the new mobiles will have support for it. I did not mean to disregard Korea - It is just that the only large scale M.IP deployment that was immanent was that in the U.S. >As far as I know, there is no commercial product for >Mobile Node software. Okay. I agree that you could assume that >the current deployment in Korea could be regarded to a nothing. >(If the number of Mobile IP service subscriber is just trivial) >I just write this message to let you know that IS-835 is ALREADY deployed >somewhere :-) > >Chae-yong > > > The IS-835 network is not yet deployed on a commercial basis. And you > > seem to agree that the above fixes would be good for the spec. Would > > make sense to consider making these changes now than later when it is > > deployed. > > > > >----------------------------------- > > >Marcello (Wandering through France) > > > > > > > -Basavaraj > > > > ----------------------------------- Marcello (Wandering through France) From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 13 11:19:18 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21925 for ; Mon, 13 Aug 2001 11:19: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 JAA29101; Mon, 13 Aug 2001 09:20: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 IAA20127; Mon, 13 Aug 2001 08:20:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7DFJ3t01883 for mobile-ip-dist; Mon, 13 Aug 2001 08:19:03 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7DFJ0D01876 for ; Mon, 13 Aug 2001 08:19: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 IAA20010 for ; Mon, 13 Aug 2001 08:19:09 -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 IAA18126 for ; Mon, 13 Aug 2001 08:19:08 -0700 (PDT) Received: from inrialpes.fr (galibier.inrialpes.fr [194.199.24.97]) by ebene.inrialpes.fr (8.11.3/8.11.3) with ESMTP id f7DFFwb06418 for ; Mon, 13 Aug 2001 17:15:58 +0200 (MEST) Message-ID: <3B77EFC5.952C1429@inrialpes.fr> Date: Mon, 13 Aug 2001 17:18:29 +0200 From: Thierry Ernst Organization: INRIA Rhone-Alpes X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile Routers: Why is P bit needed? References: <3B73AAC0.72031B8@Kniveton.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 > There is one question I had on the Mobile Networks draft which I thought > would be better suited for the list than the meeting: > > What is the need for a Prefix Scope Registration bit? I can not think of > a case where a MR would have to include a Prefix Scope extension on a BU > and wouldn't want it to be processed. Isn't the inclusion of said > extension, or not, tantamount to indicating its presence with the P bit? May be the 'P' bit is not needed. I put it there as an indication for the receiver to check if a Mobile Network Prefix sub-option is needed or not. 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 Aug 13 11:33:35 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22227 for ; Mon, 13 Aug 2001 11:33: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 IAA18847; Mon, 13 Aug 2001 08:34: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 IAA22355; Mon, 13 Aug 2001 08:33:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7DFWE901968 for mobile-ip-dist; Mon, 13 Aug 2001 08:32:14 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7DFWAD01961 for ; Mon, 13 Aug 2001 08:32: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 IAA08903 for ; Mon, 13 Aug 2001 08:32:19 -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 JAA22039 for ; Mon, 13 Aug 2001 09:32:24 -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 KAA27187 for ; Mon, 13 Aug 2001 10:32:07 -0500 (CDT) Received: from zrchb200.us.nortel.com by smtprch1.nortel.com; Mon, 13 Aug 2001 10:30:44 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 13 Aug 2001 10:30:15 -0500 Message-ID: <85AA7486A2C1D411BCA20000F8073E4303130C86@crchy271.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Piggybacking Date: Mon, 13 Aug 2001 10:30:10 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1240C.D6F0D740" Sender: owner-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_01C1240C.D6F0D740 Content-Type: text/plain; charset="iso-8859-1" -----Original Message----- From: Michael Thomas [mailto:mat@cisco.com] Sent: Saturday, August 11, 2001 2:17 PM To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Piggybacking Glenn Morrow writes: > Michael, > > Please explain in more detail why you believe the performance would be > better without piggybacking. I would suspect the performance to be better > with piggybacking. It obviously depends on the particular link layer. However, for one example that I'm pretty familiar with -- DOCSIS cable -- it would better to separate them into two packets because you would then be able to reap the benefit of payload header supression (PHS) as well as use concatenation to place both packets on the same upstream grant request. GM] Balderdash on the upstream grant point - no gain one way or the other. See my point below on the PHS. > I would also have some severe reservations about having a snooping ROHC > compression strategy drive the more pure IP standard. I don't understand what you mean here. ROHC would be greatly complicated if it had to consider piggybacking too. If we separate them, it could be made to look like a normal UDP packet which ROHC already knows how to compress. GM] Mike - so I guess you don't want to use Routing headers, IPSEC headers, router alerts, home address options, etc.. etc.. etc.. because ROHC will become more complex. It seems to me that you are being quite arbitrary in your complexity argument. In my mind the complexity is not more than these other header options. ROHC is a snooping technology. It is not a pure layer 3 solution. We should not drive the definition of MIPv6 based upon this complexity argument of this snooping technology. The PHS is a similar thing to ROHC and the same points apply. The BU will not be sent on every packet. I don't see a problem with an exception here and there to improve the overall end to end quality of service (route optimization) of the users flows. Glenn ------_=_NextPart_001_01C1240C.D6F0D740 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Piggybacking

-----Original Message-----
From: Michael Thomas [mailto:mat@cisco.com]
Sent: Saturday, August 11, 2001 2:17 PM
To: mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] Piggybacking


Glenn Morrow writes:
 > Michael,
 >
 > Please explain in more detail why you = believe the performance would be
 > better without piggybacking. I would = suspect the performance to be better
 > with piggybacking.

   It obviously depends on the particular = link layer.
   However, for one example that I'm = pretty familiar
   with -- DOCSIS cable -- it would better = to separate
   them into two packets because you would = then be able
   to reap the benefit of payload header = supression
   (PHS) as well as use concatenation to = place both
   packets on the same upstream grant = request.

GM] Balderdash on the upstream grant point - no gain = one way or the other. See my point below on the PHS.

 > I would also have some severe reservations = about having a snooping ROHC
 > compression strategy drive the more pure = IP standard.

   I don't understand what you mean here. = ROHC would
   be greatly complicated if it had to = consider
   piggybacking too. If we separate them, = it could
   be made to look like a normal UDP = packet which
   ROHC already knows how to = compress.

GM] Mike - so I guess you don't want to use Routing = headers, IPSEC headers, router alerts, home address options, etc.. = etc.. etc.. because ROHC will become more complex. It seems to me that = you are being quite arbitrary in your complexity argument. In my mind = the complexity is not more than these other header options. ROHC is a = snooping technology. It is not a pure layer 3 solution. We should not = drive the definition of MIPv6 based upon this complexity argument of = this snooping technology. The PHS is a similar thing to ROHC and the = same points apply. The BU will not be sent on every packet. I don't see = a problem with an exception here and there to improve the overall end = to end quality of service (route optimization) of the users = flows.

Glenn

------_=_NextPart_001_01C1240C.D6F0D740-- From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 13 11:51:23 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22667 for ; Mon, 13 Aug 2001 11:51:23 -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 IAA28066; Mon, 13 Aug 2001 08:52: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 IAA25614; Mon, 13 Aug 2001 08:51:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7DFoxq02075 for mobile-ip-dist; Mon, 13 Aug 2001 08:50:59 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7DFouD02068 for ; Mon, 13 Aug 2001 08:50: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 IAA11988 for ; Mon, 13 Aug 2001 08:51:06 -0700 (PDT) Received: from zrc2s03g.us.nortel.com (zrc2s03g.nortelnetworks.com [47.103.122.66]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA04987 for ; Mon, 13 Aug 2001 08:50:54 -0700 (PDT) Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id KAA06609 for ; Mon, 13 Aug 2001 10:50:45 -0500 (CDT) Received: from zrchb200.us.nortel.com by smtprch2.nortel.com; Mon, 13 Aug 2001 10:44:11 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 13 Aug 2001 10:50:18 -0500 Message-ID: <85AA7486A2C1D411BCA20000F8073E4303130CD8@crchy271.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Heterogeneous Handover - How Would it Work? Date: Mon, 13 Aug 2001 10:50:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1240F.A6B454F0" 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_01C1240F.A6B454F0 Content-Type: text/plain; charset="iso-8859-1" Charlie, I'm not sure it will always work for interdomain mobility on handoff. The communication between the source and target administrative domains during a handoff might need to be enhanced in order to convey the addresses of routes (FAs, ARs) that are appropriate for handoff. This is what I trying to convey. I don't want to see the name changed. We should understand that under certain situations the addresses for the source and target routers may not even be known across autonomous systems. Defining and solving these issues seems to fit into the MIP WG. They are related to roaming agreements in a manner. I see ROAMOPS as subscription management - not routing. Glenn -----Original Message----- From: Charlie Perkins [mailto:charliep@iprg.nokia.com] Sent: Friday, August 10, 2001 7:53 PM To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Heterogeneous Handover - How Would it Work? Hello Glenn, Since Mobile IP should work for intradomain mobility, I don't see why this would be a good idea. Regards, Charlie P. Glenn Morrow wrote: > Let's change the description of the MIP WG then: > > Stick an "Interdomain" before the Routing for Mobile/Wireless Hosts > > -----Original Message----- > From: James Kempf [mailto:James.Kempf@Sun.COM] > Sent: Friday, August 10, 2001 4:11 AM > To: mobile-ip; mobile-ip > Subject: Re: [mobile-ip] Heterogeneous Handover - How Would it Work? > > >> Something like SUCV, that would allow an ISP to cryptographically > identify > >> to what other ISP an address belonged, might be useful in this > context. > > > >I didn't read the above in the SUCV draft. SUCV allows nodes to > challenge > >the node with an SUCV address to show indicate that they have the > private > >key corresponding to the address. This doesn't identify the ISP as > far > >as I can tell. > >Or do you intend to infer the identity of the ISP from the high-order > > >bits in the IPv6 address? > > > > Right, the high order bits identify the ISP, the low order identify > the mobile node. > > I suppose there is an issue here in that a mobile node could > manufacture > the high order bits and thus claim it was from an ISV that it wasn't, > > but the low order bits should provide proof. > > jak ------_=_NextPart_001_01C1240F.A6B454F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Heterogeneous Handover - How Would it = Work?

Charlie,

I'm not sure it will always work for interdomain = mobility on handoff. The communication between the source and target = administrative domains during a handoff might need to be enhanced in = order to convey the addresses of routes (FAs, ARs) that are appropriate = for handoff.

This is what I trying to convey. I don't want to see = the name changed. We should understand that under certain situations = the addresses for the source and target routers may not even be known = across autonomous systems. Defining and solving these issues seems to = fit into the MIP WG. They are related to roaming agreements in a = manner. I see ROAMOPS as subscription management - not = routing.

Glenn



-----Original Message-----
From: Charlie Perkins [mailto:charliep@iprg.nokia.com]
Sent: Friday, August 10, 2001 7:53 PM
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Heterogeneous Handover - = How Would it Work?


Hello Glenn,

Since Mobile IP should work for intradomain mobility, = I don't
see why this would be a good idea.

Regards,
Charlie P.


Glenn Morrow wrote:

> Let's change the description of the MIP WG = then:
>
> Stick an "Interdomain" before the = Routing for Mobile/Wireless Hosts
>
> -----Original Message-----
> From: James Kempf [mailto:James.Kempf@Sun.COM]
> Sent: Friday, August 10, 2001 4:11 AM
> To: mobile-ip; mobile-ip
> Subject: Re: [mobile-ip] Heterogeneous Handover = - How Would it Work?
>
> >> Something like SUCV, that would allow = an ISP to cryptographically
> identify
> >> to what other ISP an address belonged, = might be useful in this
> context.
> >
> >I didn't read the above in the SUCV draft. = SUCV allows nodes to
> challenge
> >the node with an SUCV address to show = indicate that they have the
> private
> >key corresponding to the address. This = doesn't identify the ISP as
> far
> >as I can tell.
> >Or do you intend to infer the identity of = the ISP from the high-order
>
> >bits in the IPv6 address?
> >
>
> Right, the high order bits identify the ISP, = the low order identify
> the mobile node.
>
> I suppose there is an issue here in that a = mobile node could
> manufacture
> the high order bits and thus claim  it was = from an ISV that it wasn't,
>
> but the low order bits should provide = proof.
>
>          = ;       jak

------_=_NextPart_001_01C1240F.A6B454F0-- From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 13 11: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 ESMTP id LAA22827 for ; Mon, 13 Aug 2001 11:55:47 -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 JAA00077; Mon, 13 Aug 2001 09:56:31 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA26433; Mon, 13 Aug 2001 08:56:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7DFtKN02156 for mobile-ip-dist; Mon, 13 Aug 2001 08:55:20 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7DFtGD02149 for ; Mon, 13 Aug 2001 08:55:16 -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 IAA23276 for ; Mon, 13 Aug 2001 08:55:26 -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 JAA29064 for ; Mon, 13 Aug 2001 09:55:23 -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 f7DFtgT19912 for ; Mon, 13 Aug 2001 08:55: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 ACM00703; Mon, 13 Aug 2001 08:55:23 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA17153; Mon, 13 Aug 2001 08:55:23 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15223.63595.672881.848898@thomasm-u1.cisco.com> Date: Mon, 13 Aug 2001 08:55:23 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Piggybacking In-Reply-To: <85AA7486A2C1D411BCA20000F8073E4303130C86@crchy271.us.nortel.com> References: <85AA7486A2C1D411BCA20000F8073E4303130C86@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: > It obviously depends on the particular link layer. > However, for one example that I'm pretty familiar > with -- DOCSIS cable -- it would better to separate > them into two packets because you would then be able > to reap the benefit of payload header supression > (PHS) as well as use concatenation to place both > packets on the same upstream grant request. > > GM] Balderdash on the upstream grant point - no gain one way or the other. > See my point below on the PHS. I never claimed it was a gain. And my initial comment said that it may be neutral to a net gain. Concatenation substantially weakens the argument for piggybacking because the net extra cost is mainly a matter of bandwidth, which can be mitigated by normal compression techniques. > > I would also have some severe reservations about having a snooping ROHC > > compression strategy drive the more pure IP standard. > > I don't understand what you mean here. ROHC would > be greatly complicated if it had to consider > piggybacking too. If we separate them, it could > be made to look like a normal UDP packet which > ROHC already knows how to compress. > > GM] Mike - so I guess you don't want to use Routing headers, IPSEC headers, > router alerts, home address options, etc.. etc.. etc.. because ROHC will > become more complex. It seems to me that you are being quite arbitrary in > your complexity argument. Not at all. If the headers are essentially static over the life of a flow, they can be compressed. If you inject variability into the flow -- like occassional BU's -- it becomes much more complicated. > In my mind the complexity is not more than these > other header options. ROHC is a snooping technology. It is not a pure layer > 3 solution. We should not drive the definition of MIPv6 based upon this > complexity argument of this snooping technology. The PHS is a similar thing > to ROHC and the same points apply. The BU will not be sent on every packet. > I don't see a problem with an exception here and there to improve the > overall end to end quality of service (route optimization) of the users > flows. Fine. On 10bT ethernet the marginal gains in bandwidth efficiency are not worth the added complexity in the stack, both for normal IP processing as Alper pointed out, path MTU considerations, as well as the complexities that arise from things that have to deal with 5-tuple processing like IPsec and RSVP. If you don't believe that, then why shouldn't we piggyback ICMP messages on TCP connections? Mike From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 13 11:56:32 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22851 for ; Mon, 13 Aug 2001 11:56: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 JAA00795; Mon, 13 Aug 2001 09:57: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 IAA26589; Mon, 13 Aug 2001 08:57:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7DFu6402178 for mobile-ip-dist; Mon, 13 Aug 2001 08:56:06 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7DFu2D02171 for ; Mon, 13 Aug 2001 08:56: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 IAA23440 for ; Mon, 13 Aug 2001 08:56:12 -0700 (PDT) Received: from atlsnmx1.nextel.com (nat-167-20.nextel.com [168.73.245.70]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA07628 for ; Mon, 13 Aug 2001 08:56:09 -0700 (PDT) Received: from atlntgw01.nextel.com (atlntgw01.nextel.com [10.8.79.187]) by atlsnmx1.nextel.com (8.8.8+Sun/8.8.6) with ESMTP id LAA25655 for ; Mon, 13 Aug 2001 11:55:56 -0400 (EDT) Received: by atlntgw01.nextel.com with Internet Mail Service (5.5.2650.21) id ; Mon, 13 Aug 2001 11:57:46 -0400 Message-ID: <020A5EC56F3FD411B5230008C716D0858687A1@NHQNTEX01> From: "Martin, David P" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] RFC2002bis Date: Mon, 13 Aug 2001 11:54:36 -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: First of all, I want to thank Charlie for bringing this item up ... Second of all, we are nearing two million data subscribers using Mobile IP, today. Obviously we would expect to have inter-operability between the current Mobile IP standard and any future enhancements to the standard. Finally, can someone point me to the original discussion of the interoperability issue? I don't recall seeing it come up prior to Charlie's email. Thanks. > -----Original Message----- > From: Marcello Lioy [mailto:lioy@qualcomm.com] > Sent: Monday, August 13, 2001 11:03 AM > To: mobile-ip@sunroof.eng.sun.com; mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] RFC2002bis > > > At 01:16 8/13/2001, Chae-yong Chong wrote: > >Hi. > > > >This is just an information for you. > > > >The IS-835 network is already deployed in Korea on a > commercial basis. > >If you asked that how many subscribers are using Mobile IP > service, I am > >sorry not to give you an exact answer. That answer could be given by > >some guys of Operators, SK Telecom ro KTF :-) > >I think you all just consider the situation of North American. :-( > > I know for a fact that the current IS835 deployment in Korea does not > support Mobile IP - this will change in short order, as the > infrastructure > will be upgraded, when the new mobiles will have support for it. > > I did not mean to disregard Korea - It is just that the only > large scale > M.IP deployment that was immanent was that in the U.S. > > > >As far as I know, there is no commercial product for > >Mobile Node software. Okay. I agree that you could assume that > >the current deployment in Korea could be regarded to a nothing. > >(If the number of Mobile IP service subscriber is just trivial) > >I just write this message to let you know that IS-835 is > ALREADY deployed > >somewhere :-) > > > >Chae-yong > > > > > The IS-835 network is not yet deployed on a commercial > basis. And you > > > seem to agree that the above fixes would be good for the > spec. Would > > > make sense to consider making these changes now than > later when it is > > > deployed. > > > > > > >----------------------------------- > > > >Marcello (Wandering through France) > > > > > > > > > > -Basavaraj > > > > > > > > ----------------------------------- > Marcello (Wandering through France) > From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 13 12:06:04 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23155 for ; Mon, 13 Aug 2001 12:06: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 KAA08855; Mon, 13 Aug 2001 10: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 JAA28507; Mon, 13 Aug 2001 09:06:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7DG5XD02339 for mobile-ip-dist; Mon, 13 Aug 2001 09:05:33 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7DG5UD02332 for ; Mon, 13 Aug 2001 09:05:30 -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 JAA07354 for ; Mon, 13 Aug 2001 09:05:39 -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 KAA07825 for ; Mon, 13 Aug 2001 10:05:36 -0600 (MDT) Received: (qmail 32155 invoked by uid 500); 13 Aug 2001 15:54:04 -0000 Date: Mon, 13 Aug 2001 08:54:03 -0700 From: Pat Calhoun To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] RFC2002bis Message-ID: <20010813085403.C30653@charizard.diameter.org> References: <020A5EC56F3FD411B5230008C716D0858687A1@NHQNTEX01> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <020A5EC56F3FD411B5230008C716D0858687A1@NHQNTEX01>; from David.P.Martin@Nextel.com on Mon, Aug 13, 2001 at 11:54:36AM -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: > Second of all, we are nearing two million data subscribers using Mobile IP, > today. Obviously we would expect to have inter-operability between the > current Mobile IP standard and any future enhancements to the standard. > > Finally, can someone point me to the original discussion of the > interoperability issue? I don't recall seeing it come up prior to Charlie's > email. Everyone that has ever participated in a bakeoff has had to modify their code to NOT comply with RFC2002 in order to interoperate. RFC 2002 has a bug, and this new version is intending on fixing that. It is rather unfortunate that RFC 2002 had this bug, but IMHO anyone that has an implementation which includes this RFC 2002 bug (SPI) is not compliant and will not interoperate. Regardless of the service being provided. As far as support for HMAC-MD5, I don't see a problem. Manufacturers of Foreign and Home agents that wish to see any product sales will support prefix+suffix MD5 to support the existing RFC 2002 installed base. Of course, these same products should allow for a switch to turn off support for prefix+suffix MD5 in order to protect itself again possible attacks. My 2 cents, PatC From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 13 12:09:20 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23253 for ; Mon, 13 Aug 2001 12:09: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 KAA11790; Mon, 13 Aug 2001 10:10: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 JAA26622; Mon, 13 Aug 2001 09:09:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7DG8m602423 for mobile-ip-dist; Mon, 13 Aug 2001 09:08:48 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7DG8iD02416 for ; Mon, 13 Aug 2001 09:08: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 JAA08012 for ; Mon, 13 Aug 2001 09:08:54 -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 KAA10458 for ; Mon, 13 Aug 2001 10:08:51 -0600 (MDT) Received: (qmail 32206 invoked by uid 500); 13 Aug 2001 15:57:19 -0000 Date: Mon, 13 Aug 2001 08:57:19 -0700 From: Pat Calhoun To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Heterogeneous Handover - How Would it Work? Message-ID: <20010813085719.E30653@charizard.diameter.org> References: <85AA7486A2C1D411BCA20000F8073E4303130CD8@crchy271.us.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <85AA7486A2C1D411BCA20000F8073E4303130CD8@crchy271.us.nortel.com>; from gmorrow@nortelnetworks.com on Mon, Aug 13, 2001 at 10:50:18AM -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: Since ROAMOPS was specifically looking at the dial-up market, perhaps it is time to revive the WG to look at wireless roaming implications. Does this make sense? PatC On Mon, Aug 13, 2001 at 10:50:18AM -0500, Glenn Morrow wrote: > Charlie, > > I'm not sure it will always work for interdomain mobility on handoff. The > communication between the source and target administrative domains during a > handoff might need to be enhanced in order to convey the addresses of routes > (FAs, ARs) that are appropriate for handoff. > > This is what I trying to convey. I don't want to see the name changed. We > should understand that under certain situations the addresses for the source > and target routers may not even be known across autonomous systems. Defining > and solving these issues seems to fit into the MIP WG. They are related to > roaming agreements in a manner. I see ROAMOPS as subscription management - > not routing. > > Glenn > > > > -----Original Message----- > From: Charlie Perkins [mailto:charliep@iprg.nokia.com] > Sent: Friday, August 10, 2001 7:53 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Heterogeneous Handover - How Would it Work? > > > Hello Glenn, > > Since Mobile IP should work for intradomain mobility, I don't > see why this would be a good idea. > > Regards, > Charlie P. > > > Glenn Morrow wrote: > > > Let's change the description of the MIP WG then: > > > > Stick an "Interdomain" before the Routing for Mobile/Wireless Hosts > > > > -----Original Message----- > > From: James Kempf [mailto:James.Kempf@Sun.COM] > > Sent: Friday, August 10, 2001 4:11 AM > > To: mobile-ip; mobile-ip > > Subject: Re: [mobile-ip] Heterogeneous Handover - How Would it Work? > > > > >> Something like SUCV, that would allow an ISP to cryptographically > > identify > > >> to what other ISP an address belonged, might be useful in this > > context. > > > > > >I didn't read the above in the SUCV draft. SUCV allows nodes to > > challenge > > >the node with an SUCV address to show indicate that they have the > > private > > >key corresponding to the address. This doesn't identify the ISP as > > far > > >as I can tell. > > >Or do you intend to infer the identity of the ISP from the high-order > > > > >bits in the IPv6 address? > > > > > > > Right, the high order bits identify the ISP, the low order identify > > the mobile node. > > > > I suppose there is an issue here in that a mobile node could > > manufacture > > the high order bits and thus claim it was from an ISV that it wasn't, > > > > but the low order bits should provide proof. > > > > jak > From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 13 13:09:17 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25086 for ; Mon, 13 Aug 2001 13:09: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 KAA07642; Mon, 13 Aug 2001 10:10: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 KAA20826; Mon, 13 Aug 2001 10:09:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7DH8GI02649 for mobile-ip-dist; Mon, 13 Aug 2001 10:08:16 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7DH8DD02642 for ; Mon, 13 Aug 2001 10:08:13 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA09943 for ; Mon, 13 Aug 2001 10:08:23 -0700 (PDT) Received: from zrc2s03g.us.nortel.com (zrc2s03g.nortelnetworks.com [47.103.122.66]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA00269 for ; Mon, 13 Aug 2001 11:08:20 -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 MAA08751 for ; Mon, 13 Aug 2001 12:08:17 -0500 (CDT) Received: from zrchb200.us.nortel.com by smtprch1.nortel.com; Mon, 13 Aug 2001 12:08:11 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 13 Aug 2001 12:07:42 -0500 Message-ID: <85AA7486A2C1D411BCA20000F8073E430318C260@crchy271.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Piggybacking Date: Mon, 13 Aug 2001 12:07:33 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1241A.719CDDE0" Sender: owner-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_01C1241A.719CDDE0 Content-Type: text/plain; charset="iso-8859-1" I believe I have already sufficiently answered Alper's implementation complexity arguments on it. As for ICMP, I doubt anyone wants to hear my opinion at this time on the security and/or privacy threats it has and how it should be changed especially with the recent network hammering that is still happening; nevertheless, I don't see the relationship of your argument. What is your goal in trying to get rid of the piggybacking: 1> rock the boat marketing 2> nuke MIPv6 down to MIPv4 3> use IPSEC and don't change IPSEC I find it quite odd that you are bringing up the IKE++ thing especially when you have been such an ardent Kerberos proponent. Please explain? It seems to me that if you value IPSEC so much - change it to do the job. People have even gone so far as to make some suggestions on how to do it. There is nothing wrong with the BU piggybacking. It aint broke - don't fix it or nuke it; although it may have been more appropriate to make it a routing header, IMO. I'm a little pieved that I'm the one standing up for something I didn't even suggest in the first place. Since we are all expressing our personal opinions today. I'll also add that I believe the binding updates functions should be a MUST for ALL CNs - at least then you will have some form of mobility "built in" IP. I'll make a deal with you - you get this changed to a MUST and I might seriously consider getting rid of piggybacking. That will stick mobility right down the 3GPP mobile vendors' "kinda - sort of" IPv6 (without mobility) throat. This is such lovely "design by committee" comprimise work - isn't it. These vendors claim they can't to MIP but they propose huge SIP compression dictionaries - ahhhh right - talk to the hand - I really need some big waders at this point. In hindsite, perhaps the mobility should have been part of the IPng WG. I suspect it would be done by now - no offense intended to the MIP WG chairs or authors. It is just that the focus would likely have been greater as well as the influence and communication on IPSEC. I'll let you or others express their opinions. No more time for this stuff. I'm hope this was an enjoyable read for many. Glenn ------------------ Previous snip ------- Fine. On 10bT ethernet the marginal gains in bandwidth efficiency are not worth the added complexity in the stack, both for normal IP processing as Alper pointed out, path MTU considerations, as well as the complexities that arise from things that have to deal with 5-tuple processing like IPsec and RSVP. If you don't believe that, then why shouldn't we piggyback ICMP messages on TCP connections? Mike ------_=_NextPart_001_01C1241A.719CDDE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Piggybacking

I believe I have already sufficiently answered = Alper's implementation complexity arguments on it.

As for ICMP, I doubt anyone wants to hear my opinion = at this time on the security and/or privacy threats it has and how it = should be changed especially with the recent network hammering that is = still happening; nevertheless, I don't see the relationship of your = argument. 

What is your goal in trying to get rid of the = piggybacking:

1> rock the boat marketing
2> nuke MIPv6 down to MIPv4
3> use IPSEC and don't change IPSEC

I find it quite odd that you are bringing up the = IKE++ thing especially when you have been such an ardent Kerberos = proponent. Please explain?

It seems to me that if you value IPSEC so much - = change it to do the job. People have even gone so far as to make some = suggestions on how to do it. There is nothing wrong with the BU = piggybacking. It aint broke - don't fix it or nuke it; although it may = have been more appropriate to make it a routing header, IMO.

 I'm a little pieved that I'm the one standing = up for something I didn't even suggest in the first place.

Since we are all expressing our personal opinions = today. I'll also add that I believe the binding updates functions = should be a MUST for ALL CNs - at least then you will have some form of = mobility "built in" IP. I'll make a deal with you - you get = this changed to a MUST and I might seriously consider getting rid of = piggybacking.

That will stick mobility right down the 3GPP mobile = vendors' "kinda - sort of" IPv6 (without mobility) throat. = This is such lovely "design by committee" comprimise work - = isn't it. These vendors claim they can't to MIP but they propose huge = SIP compression dictionaries - ahhhh right - talk to the hand - I = really need some big waders at this point.

In hindsite, perhaps the mobility should have been = part of the IPng WG. I suspect it would be done by now - no offense = intended to the MIP WG chairs or authors. It is just that the focus = would likely have been greater as well as the influence and = communication on IPSEC.

I'll let you or others express their opinions. No = more time for this stuff. I'm hope this was an enjoyable read for = many.

Glenn
 

------------------ Previous snip -------

   Fine. On 10bT ethernet the marginal = gains in
   bandwidth efficiency are not worth the = added
   complexity in the stack, both for = normal IP
   processing as Alper pointed out, path = MTU
   considerations, as well as the = complexities
   that arise from things that have to = deal with
   5-tuple processing like IPsec and RSVP. = If
   you don't believe that, then why = shouldn't
   we piggyback ICMP messages on TCP = connections?

        =         Mike

------_=_NextPart_001_01C1241A.719CDDE0-- From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 13 13:40:47 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25784 for ; Mon, 13 Aug 2001 13:40: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 KAA24864; Mon, 13 Aug 2001 10:41:45 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA28297; Mon, 13 Aug 2001 10:41:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7DHe7I02813 for mobile-ip-dist; Mon, 13 Aug 2001 10:40:07 -0700 (PDT) Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.179.15]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7DHe2D02806 for ; Mon, 13 Aug 2001 10:40:03 -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 f7DHe5213993; Mon, 13 Aug 2001 19:40:05 +0200 (MET DST) Date: Mon, 13 Aug 2001 19:37:25 +0200 (CEST) From: Erik Nordmark Subject: Re: [mobile-ip] Mobile Routers support without optimization To: Mattias Pettersson Cc: mobile-ip@sunroof.eng.sun.com, "T.J. Kniveton" In-Reply-To: "Your message with ID" <3B77E391.1E9A5D34@era.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > This is exactly what I pointed out to Thierry a while ago. If routing is > consistent and transparent with regards to this home link, I also think > that this is the ideal solution. > > However, Mobile IPv6 fails to be fully transparent when it comes to > link-local addresses. Are you concerned about the link-local addresses used e.g. by OSPF to communicate with the routers on the home link, or some other use of link locals? Given the current specification, which says that the HA must not tunnel link locals to the MN, I think the only solution is to make the MR, when away from home, have a router adjacency with the HA i.e. it will be two hops away from the other routers on the home link. This might mean that when moving to or from the home link all the adjacencies will be torn down and new ones created. Or it could choose to always maintain a tunneled adjacency with the HA - even when at home. > Unfortunately, we couldn't make an agreement on how nodes would > function. It is obviously implementation dependent whether the home > agent will do binding cache lookup and routing table lookup in the > correct order to allow this. > > I pointed out that a BSD home agent could probably work like described > above, but Thierry shows in the draft that INRIA's MIPv6 code would not. > > > > > > Thus the PAN router will continue to exchange reachability information > > with the routers on home network using the routing protocol (e.g. OSPF). > > All packets will be tunneled in both directions. The nodes in my PAN > > will not notice that they are moving. > > Routing protocols use link-local addresses, so this would fail (at least > with today's specification of Mobile IPv6 and routing protocols). > > Maybe Mobile IPv6 should be changed to tunnel *all* packets. But that means that the MN will see e.g. all mulicast ND packets which might not be that good use of bandwidth. From an architectural perspective this would make the HA an L2 bridge instead of a L3 router. If there are different links the thing that connects them is a router and link-locals don't cross between links. Erik From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 13 13:45:11 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25901 for ; Mon, 13 Aug 2001 13:45:11 -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 KAA27312; Mon, 13 Aug 2001 10:46: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 KAA29486; Mon, 13 Aug 2001 10:45:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7DHivC02879 for mobile-ip-dist; Mon, 13 Aug 2001 10:44:58 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7DHisD02872 for ; Mon, 13 Aug 2001 10:44:54 -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 KAA18288 for ; Mon, 13 Aug 2001 10:45:05 -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 LAA00929 for ; Mon, 13 Aug 2001 11:45:01 -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 f7DHjKT07348 for ; Mon, 13 Aug 2001 10:45: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 ACO02035; Mon, 13 Aug 2001 10:45:01 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA17166; Mon, 13 Aug 2001 10:45:01 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15224.4637.30885.840984@thomasm-u1.cisco.com> Date: Mon, 13 Aug 2001 10:45:01 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Piggybacking In-Reply-To: <85AA7486A2C1D411BCA20000F8073E430318C260@crchy271.us.nortel.com> References: <85AA7486A2C1D411BCA20000F8073E430318C260@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: > What is your goal in trying to get rid of the piggybacking: > > 1> rock the boat marketing > 2> nuke MIPv6 down to MIPv4 > 3> use IPSEC and don't change IPSEC 3. I'm not convinced that IPsec is what was to blame here. MIPv6 was trying to use it in a way that wasn't really appropriate and there seems to be pretty simple workarounds to use IPsec the way it was intended to be used. Given that the work arounds seems to mostly neutral depending on your view of piggybacking, I'd much rather not have to take on the task of either: 1) changing IPsec selectors 2) changing IKE and/or counting on something new Piggybacking is the casualty; so be it. Nice idea, but not worth the trouble. > I find it quite odd that you are bringing up the IKE++ thing especially when > you have been such an ardent Kerberos proponent. Please explain? It's actually not contradictory. I think that IKE with certificates has scaling problems in certain though common cases; the cost of DH/RSA signatures is considerable when you are talking about high fanout servers/routers. Restart avalanches are a large problem, with restart times measured in the many, many minutes range. That said, IKE is here, it works, and warts and all is the only workable solution for peer keying we have. Other keying schemes MAY eventually replace IKE where something else is more appropriate, but given the long and difficult development cycle for IKE, it would be foolish to not hedge bets to some degree by being able to drop in what is at least known to work. > It seems to me that if you value IPSEC so much - change it to do the job. > People have even gone so far as to make some suggestions on how to do it. > There is nothing wrong with the BU piggybacking. It aint broke - don't fix > it or nuke it; although it may have been more appropriate to make it a > routing header, IMO. But there is something wrong with it: it breaks the intended use of IPsec. Also: it's not even clear that a routing update should be carried as an option which is normally handled by the kernel. Indeed, if you don't have access to the kernel, having BU's as a UDP or IP proto would allow an external daemon to camp on the port and add the necessary routing updates which is almost certainly infeasible as a DO. Mike From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 13 13:54:37 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26099 for ; Mon, 13 Aug 2001 13:54:36 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA02268; Mon, 13 Aug 2001 10:55: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 KAA23460; Mon, 13 Aug 2001 10:55:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7DHsIN02988 for mobile-ip-dist; Mon, 13 Aug 2001 10:54:18 -0700 (PDT) Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.179.15]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7DHsDD02981 for ; Mon, 13 Aug 2001 10:54:14 -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 f7DHs8215080; Mon, 13 Aug 2001 19:54:09 +0200 (MET DST) Date: Mon, 13 Aug 2001 19:51:28 +0200 (CEST) From: Erik Nordmark Subject: Re: [mobile-ip] Mobile Routers support without optimization To: Michael Thomas Cc: mobile-ip@sunroof.eng.sun.com, "T.J. Kniveton" In-Reply-To: "Your message with ID" <15223.60162.967362.605180@thomasm-u1.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > Sure. All you've done is managed to avoid the hard > problem which is route optimization :-) I think my note had "basic" in there :-) If you want something more signifant to think about then there is the train case with different adminstrations and a different HA for the MR (HA1) and a for a particular MN on the train (HA2). In order to illustrate the route optimization choices let's look at a possible way to approach this problem: Without route optimization that case works as follows: MR updates HA1 with its current topological location as the train moves. When MN arrives on the train it uses addrconf to get an address under MR's prefix. Create co-located COA. It updates HA2 with this as the COA. CN looks up MN in DNS. Sends packet to that are intercepted by HA2. HA2 tunnels packets towards MR thuse the packets are routed towards HA1. HA1 in turn tunnels the packets to MR's COA. MR decapsulated and sends the singly-tunneled packets to MN's COA. For the forward path there are two HAs that can be optimized out. Depending on traffic patterns and relative movement speed at the two attachment points (MN attaching to MR, and MR attaching to some access router along the train track) all 4 possibilities of optimization might make sense - optimize out both HAs - optimize out HA2 (if MN stays on the train for a long time) - optimize out HA1 (as long as MR doesn't get handed off too often) - optimize out none So just like in the simple mobile node case there are tradeoffs between the signalling involved in doing route optimizations and savings from more efficient routing, but in the MR case there are more variants on what to optimize. Erik From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 13 14:07:09 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26341 for ; Mon, 13 Aug 2001 14:07: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 MAA19881; Mon, 13 Aug 2001 12:08: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 LAA26283; Mon, 13 Aug 2001 11:07:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7DI6et03078 for mobile-ip-dist; Mon, 13 Aug 2001 11:06:40 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7DI6bD03071 for ; Mon, 13 Aug 2001 11:06:37 -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 LAA25964 for ; Mon, 13 Aug 2001 11:06: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 LAA21279 for ; Mon, 13 Aug 2001 11:06: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 f7DI6pQ15737 for ; Mon, 13 Aug 2001 11:06: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 ACO02857; Mon, 13 Aug 2001 11:06:46 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA17169; Mon, 13 Aug 2001 11:06:46 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15224.5942.604055.197468@thomasm-u1.cisco.com> Date: Mon, 13 Aug 2001 11:06:46 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] About authorization and security policies In-Reply-To: <3B712FBB.607E428B@nomadiclab.com> References: <3B712FBB.607E428B@nomadiclab.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 Pekka Nikander writes: > Case A. IKE and AH/ESP > > Let us assume that AH (or ESP with integrity protection) is used to > protect the BUs. In that case, there must be an entry in the > IPsec SPD specifying at the receiving host (CN) that if the > BU is protected with the given SA, then the BU can be accepted > and the corresponding Binding Cache entry can be created. > Otherwise, if the SDP databased does not allow Binding Cache > entry creation, such an entry MUST NOT be created even if the > packet integrity and authenticity was correctly verified. > > In other words, the SPD makes sure that the SA is _authorized_ > to protect BUs for that specific Home Address. It is important > to note that it is _not_ enough that the BU is protected with > _some_ SA, but that the SA used for protection MUST be created > in such a way that it is known to be properly authorized. Pekka, This is really no different than saying that _ANY_ service which relies on IPsec layer integrity/confidentiality MUST cross check which credentials were supplied to create that SA to perform an authorization check. This is really no different than using transport/ESP for SIP traffic and then making the rash assumption that it will also protect you from forgery attacks in the inside payload (eg, IPsec says mat@cisco.com, but SIP From: gwb@whitehouse.gov). There are obviously other attacks (authorization attacks too), but what is pertinent is that the cross checking must be performed at upper layers as appropriate. > What is important to note here is that even if you use a (local) PKI > so that you know who your peer is, you DO have the danger of creating > not-properly-authorized SPD entries. That is, when running a key > management protocol and checking the certificates, you > > a) either must know (or at least believe) that all hosts > certified by your PKI are fully honest and competent, or > > b) your PKI must explicitly contain information specifying > the home addresses of the hosts. Correct. However, in a lot of situations (a) brings acceptible risks. In particular, enterprise like situations make all kinds of assumptions that insiders will be basically honest which greatly simplifies security policy (whether this is misguided is a different discussion). Also: even in situations where users are not fully trusted, policing may be able to provide an adequate risk if the penalty is high enough (ie, lose service if you hack, etc.) > Case C. IKE and -14 authentication > > If we want to use IKE with -14 authentication, we basically need > a new DOI (or extension to the Internet DOI), specifying how > authentication data for -14 BU authentication is created. > That is certainly some amount of work, but doable. Except for the fact that there's a long standing and now very public moratorium on new IKE development. > > Case D. BAKE and AH/ESP authentication > > There is no fundamental reason why BAKE could not be used for > creating AH or ESP SAs. The only restriction is that such > AH or ESP SA __MAY_NOT__ be used for any other purpose but > protecting BUs. I could be, but I would think that opportunistic encryption would be a better way to achieve the same ends. Mike From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 13 14:48:50 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26994 for ; Mon, 13 Aug 2001 14:48: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 LAA29552; Mon, 13 Aug 2001 11:48: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 LAA06095; Mon, 13 Aug 2001 11:47:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7DIkWI03215 for mobile-ip-dist; Mon, 13 Aug 2001 11:46:32 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7DIkSD03208 for ; Mon, 13 Aug 2001 11:46:28 -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 LAA21102 for ; Mon, 13 Aug 2001 11:46:33 -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 LAA04472 for ; Mon, 13 Aug 2001 11:46:30 -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 f7DIkeT22396 for ; Mon, 13 Aug 2001 11:46:40 -0700 (PDT) Received: (mchandra@localhost) by mchandra-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA12694 for mobile-ip@sunroof.eng.sun.com; Mon, 13 Aug 2001 14:46:01 -0400 (EDT) Date: Mon, 13 Aug 2001 14:46:01 -0400 From: "Madhavi W. Chandra" To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Re: mobile-ip] RFC2002bis Message-ID: <20010813144601.E12662@cisco.com> References: <3B748398.C5C27797@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: <3B748398.C5C27797@iprg.nokia.com>; from charliep@iprg.nokia.com on Fri, Aug 10, 2001 at 06:00:08PM -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: Charlie, On Fri, Aug 10, 2001 at 06:00:08PM -0700, Charlie Perkins wrote: > Hello folks, > > A new version of RFC2002bis has been prepared. According > to the most recent guidance given by the IESG, a change in > the mandated authentication algorithm has been strongly > suggested. Unfortunately, this will have the effect of > causing almost all previous implementations of Mobile IP > for IPv4 to become incompatible with the new specification. > > The working group chairs recently asked the working group, > by way of the mailing list, whether this incompatible > change would be acceptable. The discussion was quite > limited, somewhat to my surprise. This has been taken > as evidence that going with HMAC_MD5 is more-or-less > O.K. Thus, it has been decided to go ahead with the > change. On the other hand, it is conceivable that not > all interested parties have been notified of the possible > change, or have had time to reply. If there are dissenters > to this change, now would be the time to express that > opinion. A quick question...when this was discussed on the mailing list last month, Kent and Gopal raised the issue of making MD5 also a MUST in RFC2002bis. Discussion followed whether MD5 should be a MUST or a SHOULD for backwards compatibility...with the understanding that HMAC_MD5 would be a MUST. So, is the idea now not to even mention this use of MD5? Please clarify. Thanks, Madhavi > That is the most important point of this note. > > Another factor in the discussion concerns the acceptability > of RFC2002bis as a basis for moving Mobile IPv4 to Draft > Standard. I have been told that, contrary to my previous > understanding, a version of RFC2002bis could be promoted > to Draft Standard even if it is first published with > the several options which have not been tested for > interoperability. These options are: > 1. 'R' bit to the Agent Advertisement > 2. 'S' bit to Registration Request > 3. Prefix Lengths Extension to Agent Advertisement > 4. Possibly other options that may come under discussion > (I don't know of any in this class). > I'll call these the "unpromotable options" > > On the other hand, it is likely that the IESG will not > promote Mobile IPv4 to Draft Standard unless the authentication > algorithm has been changed to HMAC_MD5. > > Consideration of all these factors leads me to believe that > one of the following scenarios will happen. > > 1. New RFC2002bis goes to Proposed Standard with HMAC_MD5, > and is promoted to Draft Standard after the ordained amount > of time after the unpromotable options are excised. These > would then properly be re-published in another document > which would cycle at Proposed Standard. > > 2. New RFC2002bis goes to Proposed Standard with HMAC_MD5, > and activity occurs to exhibit interoperability for the > unpromotable options. Then, since the options would > become promotable, RFC2002bis could go to Draft Standard > without substantial revision. > > 3. (combination of 1 and 2): some of the unpromotable options, > but not all of them, are tested for interoperability. > Then fewer of the options would be excised, and the other > new document would be thinner. > > 4. The working group could decide that moving to HMAC_MD5 > was premature. Then RFC2002bis might possibly be published > with "envelope-mode" specified (as it is now). Then another > version of Mobile IPv4 would be published later with > HMAC_MD5 mandated instead of "envelope-mode" mandated. > The advantage of this approach is that it would be possible > to create correct and interoperable implementations of > Mobile IPv4. Up until now, all interoperable implementations > have had to handle the SPI field as part of the computation > of the authentication data in a way that was not clear from > RFC 2002. Fixing this problem was the most important > reason for embarking on RFC2002bis in the first place. > > I think that basically accounts for the most likely > possibilities, but maybe there are others that could happen. > However, it seems likely that HMAC_MD5 will be required by > the IESG as the mandated default algorithm in the Draft > Standard version of Mobile IPv4, because there has been > published work showing that envelope mode is vulnerable to > an attack that reduces its cryptographic strength. > > Following strategies 1-3 will mean that there is no RFC > which can be read to create new implementations of > Mobile IPv4 which are interoperable with existing versions > of Mobile IPv4. On the other hand, following 1-3 will > mean that RFC2002bis is a more likely candidate for > promotion to Draft Standard, avoiding the need for one > more revision to accomplish that purpose. > > Quick action is expected on the HMAC_MD5 version of RFC200bis, > so it is possible that any discussion about backwards > incompatibility will happen as part of IETF Last Call. > > Whatever people decide on these issues is fine with me. > As draft editor, I'll happily produce whatever documents > are indicated by near-term and Last Call discussions over > the next weeks. > > Regards, > Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 13 15:40:52 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27633 for ; Mon, 13 Aug 2001 15:40: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 NAA02353; Mon, 13 Aug 2001 13: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 MAA16463; Mon, 13 Aug 2001 12:40:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7DJcKg03381 for mobile-ip-dist; Mon, 13 Aug 2001 12:38:20 -0700 (PDT) Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.179.15]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7DJcGD03374 for ; Mon, 13 Aug 2001 12:38:16 -0700 (PDT) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f7DJcF221143; Mon, 13 Aug 2001 21:38:16 +0200 (MET DST) Date: Mon, 13 Aug 2001 21:34:51 +0200 (CEST) From: Erik Nordmark Subject: Re: [mobile-ip] About authorization and security policies To: Michael Thomas Cc: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <15224.5942.604055.197468@thomasm-u1.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > If we want to use IKE with -14 authentication, we basically need > > a new DOI (or extension to the Internet DOI), specifying how > > authentication data for -14 BU authentication is created. > > That is certainly some amount of work, but doable. > > Except for the fact that there's a long standing > and now very public moratorium on new IKE development. Before assuming that a new DOI is subject to the moratorium it would make sense to check with the security ADs - I don't know the answer. Erik From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 13 15:56:24 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27799 for ; Mon, 13 Aug 2001 15:56:23 -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 MAA29280; Mon, 13 Aug 2001 12: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 MAA19431; Mon, 13 Aug 2001 12:55:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7DJqSu03462 for mobile-ip-dist; Mon, 13 Aug 2001 12:52:28 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7DJqOD03455 for ; Mon, 13 Aug 2001 12:52: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 MAA23904 for ; Mon, 13 Aug 2001 12:52:34 -0700 (PDT) Message-Id: <200108131952.MAA23904@heliopolis.eng.sun.com> Date: Mon, 13 Aug 2001 12:52:26 -0700 (PDT) From: James Kempf Subject: Re: [mobile-ip] Heterogeneous Handover - where do i look To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: cqcKps89+a4sodTwCJx11A== 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: Doradla, My understanding is that although the GPRS standard specifies MIP for inter-GGSN handover, there has been very little effort to clarify exactly how this would work and how it would interact with GTP-based mobility, primarily, I'm told, due to lack of operator interest. I do not know if manufacturers are even building MIP into their terminals. So, prior to figuring out at the IP level how heterogeneous handover would work, there is a need to figure out in GPRS how MIP and GPRS will work together. jak >From: "Doradla, Anil" >To: "'mobile-ip@sunroof.eng.sun.com'" >Subject: [mobile-ip] Heterogeneous Handover - where do i look >Date: Fri, 10 Aug 2001 11:28:03 -0500 >All: > >Coming back to the question of handover across heterogeneous wireless >networks. Can anyone advise me as to where i should look at? >We are seeing a desire for handover between 802.11 and GPRS networks. Is >there any group looking at the feasibility of this ? > >Thanks in advance > >Anil Doradla >SBC- Technology Resources, Inc. >Austin, TX-78727 > > >-----Original Message----- >From: James Kempf [mailto:James.Kempf@sun.com] >Sent: Friday, August 10, 2001 3:57 AM >To: mobile-ip@sunroof.eng.sun.com; mobile-ip@sunroof.eng.sun.com >Cc: Peter.Dahl >Subject: RE: [mobile-ip] Heterogeneous Handover - How Would it Work? > > >Glenn, > >I think Raj is right on here, sorry. There are enough technical issues >involved in getting MIP to be deployable that the MIP group really >needs to focus on. An example is this NAT question. > >If there are any operational issues involved in handover between operators >that >need resolution, they should probably be handled in a separate working >group, like ROAMOPS. An example of such an issue might be advertising >access routers between operators using something like the Seamoby >CAR discovery protocol, which is just now getting off the ground. > > jak >>Raj, >> >>That's like saying that BGP doesn't deal with the routing policy related to >>business relationships between the owners of autonomous systems. You are >>shoe-holing the group into only dealing with an enterprise - not the >>Internet. >> >>-----Original Message----- >>From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com] >>Sent: Thursday, August 09, 2001 10:55 AM >>To: mobile-ip >>Cc: Peter.Dahl >>Subject: RE: [mobile-ip] Heterogeneous Handover - How Would it Work? >> >> >>Clearly, you are mixing roaming with seamless mobility across >>heterogeneous >>access types. The Mobile IP WG does not deal with aspects related to >>roaming >>agreements between operators or administrative domains. That is NOT what >>this WG is about. >> >>-Basavaraj >> >>> -----Original Message----- >>> From: ext Dahl, Peter [mailto:Peter.Dahl@VerizonWireless.com] >>> Sent: Wednesday, August 08, 2001 1:53 PM >>> To: 'mobile-ip@sunroof.eng.sun.com' >>> Subject: RE: [mobile-ip] Heterogeneous Handover - How Would it Work? >>> >>> >>> ...not forgetting cdma2000. I am not aware of any work in >>> 3GPP2 or IEEE, >>> perhaps 3GPP ? >>> >>> Pete >>> >>> -----Original Message----- >>> From: Brad Casemore [mailto:bcasemore@home.com] >>> Sent: Wednesday, August 08, 2001 11:29 AM >>> To: mobile-ip@sunroof.eng.sun.com >>> Subject: RE: [mobile-ip] Heterogeneous Handover - How Would it Work? >>> >>> >>> If that is the case, then WECA's WISPr is dedicated to >>> 802.11b roaming, >>> while the ETSI has assigned a group to address GPRS roaming. >>> Is there a >>> group anywhere that is looking into the technical issues >>> associated with >>> heterogeneous network roaming (such as between, theoretically, 802.11b >>> WLANs and GPRS)? >>> >>> Brad >>> >>> > -----Original Message----- >>> > From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile- >>> > ip@sunroof.eng.sun.com] On Behalf Of James Kempf >>> > Sent: Wednesday, August 08, 2001 2:19 AM >>> > To: mobile-ip@sunroof.eng.sun.com; mobile-ip@sunroof.eng.sun.com >>> > Subject: Re: [mobile-ip] Heterogeneous Handover - How Would it Work? >>> > >>> > Pat, >>> > >>> > I think they already have such a standard and I believe it >>> only works >>> > with GPRS. >>> > >>> > jak >>> > >>> > >Also, I believe that ETSI is working on a standard called GRX for >>> GSM<- >>> > >802.11 >>> > >roaming. >>> > > >>> > >PatC >>> > >On Tue, Aug 07, 2001 at 09:32:58AM -0700, Dahl, Peter wrote: >>> > >> FYI, the Wireless ISPs (WISPs) are already talking about such >>> roaming >>> > >> issues. >>> > >> >>> > >> There appear to be 2 emerging forums for these discussions, one >>> under >>> > the >>> > >> auspices of WECA (http://www.weca.net) known as the WISPr group >>> ('r' >>> > being >>> > >> for roaming), the other a yet to be finalized 'WISP Forum' the >>> prime >>> > mover >>> > >> for which is a company in Luxembourg (www.excilan.com). >>> > >> >>> > >> Regards >>> > >> >>> > >> -----Original Message----- >>> > >> From: James Kempf [mailto:James.Kempf@Sun.COM] >>> > >> Sent: Tuesday, August 07, 2001 8:58 AM >>> > >> To: mobile-ip@sunroof.eng.sun.com; mobile-ip@sunroof.eng.sun.com >>> > >> Subject: Re: [mobile-ip] Heterogeneous Handover - How Would it >>> Work? >>> > >> >>> > >> >>> > >> >On the other hand, the home address must belong to some >>> ISP/operator. >>> > >> >That ISP must provide a home agent and an ip address, and a CoA >>> when >>> > the >>> > >> >MN is connected to other than the home subnet. Other >>> ISPs that are >>> > used >>> > >> >are only access providers, and would give the MN its >>> CoA. This of >>> > course >>> > >> >would cause political problems. Who are the ISPs that >>> are willing >>> to >>> > be >>> > >> >access providers only, and who will be providing home agent and >>> home >>> > >> >address as well? >>> > >> > >>> > >> >>> > >> This is an issue. What happens if you have one access provider on >>> > >> one interface, say the wCDMA interface, and another on >>> another, say >>> > 802.11? >>> > >> There are now in the US a growing number of 802.11 access >>> providers, >>> > >> and I can imagine someone with a laptop having a wCDMA modem and >>> > >> an 802.11 card. >>> > >> >>> > >> Maybe something like the "roaming consortia" that have sprung up >>> > >> around ISP access might evolve, but the protocol >>> design/engineering >>> > >> issue is whether there is any additional work (such as the NAI in >>> > >> the roaming consortia example) needed to enable sharing of a home >>> > >> address among interfaces for which different ISPs are >>> responsible. >>> > >> >>> > >> Something like SUCV, that would allow an ISP to cryptographically >>> > identify >>> > >> to what other ISP an address belonged, might be useful in this >>> context. >>> > >> >>> > >> jak >>> > From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 13 16:03:41 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27893 for ; Mon, 13 Aug 2001 16:03: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 NAA02440; Mon, 13 Aug 2001 13:04: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 NAA21318; Mon, 13 Aug 2001 13:03:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7DK2Mb03554 for mobile-ip-dist; Mon, 13 Aug 2001 13:02:22 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7DK2JD03547 for ; Mon, 13 Aug 2001 13:02:19 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA21023 for ; Mon, 13 Aug 2001 13:02:28 -0700 (PDT) Received: from zrc2s03g.us.nortel.com (zrc2s03g.nortelnetworks.com [47.103.122.66]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA16558 for ; Mon, 13 Aug 2001 14:02:25 -0600 (MDT) Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id PAA23592 for ; Mon, 13 Aug 2001 15:02:01 -0500 (CDT) Received: from zrchb200.us.nortel.com by smtprch2.nortel.com; Mon, 13 Aug 2001 14:55:30 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 13 Aug 2001 15:01:38 -0500 Message-ID: <85AA7486A2C1D411BCA20000F8073E430318C4AC@crchy271.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Piggybacking Date: Mon, 13 Aug 2001 15:01:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C12432.C18EA3C0" 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_01C12432.C18EA3C0 Content-Type: text/plain; charset="iso-8859-1" Well I couldn't resist one last comment - Gosh - why doesn't RSVP use IPSEC? Apparently IPSEC isn't to blame for this either? I think we should force RSVP to use IPSEC based upon your logic. Hey - I guess we'll have to get rid of the router alert to get RSVP to work. Routing headers are O.K. though. Yeah - each router knows based upon the destination address in the routing header where to directly send the packet hop by hop or over tunnels - that's the ticket. RSVP would be too complex with the router alert in conjunction with IPSEC based upon your logic? RSVP needs to rely on IKE for distribution - it has to or the sky will fall out. I guess we can't use RSVP at all ever because it doesn't use IKE and IPSEC. I guess there is something inherently wrong with RSVP - it breaks IPSEC. We wouldn't be leveraging our bets if all routers and hosts which employ RSVP didn't use IKE for key distribution. Though these arguments above are quite ludicrous, it does hopefully point out the injustice in your reasoning. As I recall authors of MIP did have designs on IPSEC to handle the exact point we are discussing now and apparently their arguments for its definitition didn't make it in probably because wireless devices were a twinkle in most peoples' (wirehead) eyes at the time or they simply didn't understand the intent; nevertheless, here we are today. So blame is probably disputable. RSVP didn't use IPSEC because it wasn't designed to deal with that particular network service. To force IPSEC on MIP or take things away from it so it can use IPSEC would be pathetic. TLS/HTTPs don't use IPSEC. I don't see people standing up and yelling about that and the service seems to work just fine. It seems that IKE can be used in conjunction with TLS too - right? MIP could use IKE++ for key distribution without IPSEC. These are disjunct issues. As for the routing updates being handled by the kernal, I personally feel that per node routing updates belong in purpose built machines (routers) designed to handle the lookups of fairly large cached routing tables at the edge - not hosts. But that is an entirely different topic. I think when we finally get into more optimization issues in conjunction with other network based services such as multicast, VPNs, anycast, privacy and security threats, people will eventually change their tune. I suspect a few highly publicized civil cases involving the victims of stalkers or assassins will provide the impetus. The original BBNers seemed to take this purpose built machine thought into account. Perhaps I'm old school on this but I guess time will tell. The fact that there is no IPv6 checksum certainly eliminates a great deal of concern about the bundling of options and their removal before delivery to the upper layers or end-hosts irrespective of whether they contained routing information or not. :) -----Original Message----- From: Michael Thomas [mailto:mat@cisco.com] Sent: Monday, August 13, 2001 12:45 PM To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Piggybacking Glenn Morrow writes: > What is your goal in trying to get rid of the piggybacking: > > 1> rock the boat marketing > 2> nuke MIPv6 down to MIPv4 > 3> use IPSEC and don't change IPSEC 3. I'm not convinced that IPsec is what was to blame here. MIPv6 was trying to use it in a way that wasn't really appropriate and there seems to be pretty simple workarounds to use IPsec the way it was intended to be used. Given that the work arounds seems to mostly neutral depending on your view of piggybacking, I'd much rather not have to take on the task of either: 1) changing IPsec selectors 2) changing IKE and/or counting on something new Piggybacking is the casualty; so be it. Nice idea, but not worth the trouble. > I find it quite odd that you are bringing up the IKE++ thing especially when > you have been such an ardent Kerberos proponent. Please explain? It's actually not contradictory. I think that IKE with certificates has scaling problems in certain though common cases; the cost of DH/RSA signatures is considerable when you are talking about high fanout servers/routers. Restart avalanches are a large problem, with restart times measured in the many, many minutes range. That said, IKE is here, it works, and warts and all is the only workable solution for peer keying we have. Other keying schemes MAY eventually replace IKE where something else is more appropriate, but given the long and difficult development cycle for IKE, it would be foolish to not hedge bets to some degree by being able to drop in what is at least known to work. > It seems to me that if you value IPSEC so much - change it to do the job. > People have even gone so far as to make some suggestions on how to do it. > There is nothing wrong with the BU piggybacking. It aint broke - don't fix > it or nuke it; although it may have been more appropriate to make it a > routing header, IMO. But there is something wrong with it: it breaks the intended use of IPsec. Also: it's not even clear that a routing update should be carried as an option which is normally handled by the kernel. Indeed, if you don't have access to the kernel, having BU's as a UDP or IP proto would allow an external daemon to camp on the port and add the necessary routing updates which is almost certainly infeasible as a DO. Mike ------_=_NextPart_001_01C12432.C18EA3C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Piggybacking

Well I couldn't resist one last comment - Gosh  = - why doesn't RSVP use IPSEC?

Apparently IPSEC isn't to blame for this = either? 

I think we should force RSVP to use IPSEC based upon = your logic. Hey - I guess we'll have to get rid of the router alert to = get RSVP to work. Routing headers are O.K. though. Yeah - each router = knows based upon the destination address in the routing header where to = directly send the packet hop by hop or over tunnels - that's the = ticket.

RSVP would be too complex with the router alert in = conjunction with IPSEC based upon your logic? RSVP needs to rely on IKE = for distribution - it has to or the sky will fall out. I guess we can't = use RSVP at all ever because it doesn't use IKE and IPSEC. I guess = there is something inherently wrong with RSVP - it breaks IPSEC. We = wouldn't be leveraging our bets if all routers and hosts which employ = RSVP didn't use IKE for key distribution.

Though these arguments above are quite ludicrous, it = does hopefully point out the injustice in your reasoning.

As I recall authors of MIP did have designs on IPSEC = to handle the exact point we are discussing now and apparently their = arguments for its definitition didn't make it in probably because = wireless devices were a twinkle in most peoples' (wirehead) eyes at the = time or they simply didn't understand the intent; nevertheless, here we = are today. So blame is probably disputable.


RSVP didn't use IPSEC because it wasn't designed to = deal with that particular network service. To force IPSEC on MIP or = take things away from it so it can use IPSEC would be pathetic. = TLS/HTTPs don't use IPSEC. I don't see people standing up and yelling = about that and the service seems to work just fine. It seems that IKE = can be used in conjunction with TLS too - right? MIP could use IKE++ = for key distribution without IPSEC. These are disjunct = issues.

As for the routing updates being handled by the = kernal, I personally feel that per node routing updates belong in = purpose built machines (routers) designed to handle the lookups of = fairly large cached routing tables at the edge - not hosts. But that is = an entirely different topic. I think when we finally get into more = optimization issues in conjunction with other network based services = such as multicast, VPNs, anycast, privacy and security threats, people = will eventually change their tune. I suspect a few highly publicized = civil cases involving the victims of stalkers or assassins will provide = the impetus.

The original BBNers seemed to take this purpose built = machine thought into account. Perhaps I'm old school on this but I = guess time will tell. The fact that there is no IPv6 checksum certainly = eliminates a great deal of concern about the bundling of options and = their removal before delivery to the upper layers or end-hosts = irrespective of whether they contained routing information or = not.

:)

-----Original Message-----
From: Michael Thomas [mailto:mat@cisco.com]
Sent: Monday, August 13, 2001 12:45 PM
To: mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] Piggybacking


Glenn Morrow writes:
 > What is your goal in trying to get rid of = the piggybacking:
 >
 > 1> rock the boat marketing
 > 2> nuke MIPv6 down to MIPv4
 > 3> use IPSEC and don't change = IPSEC

3. I'm not convinced that IPsec is what was to
blame here. MIPv6 was trying to use it in a = way
that wasn't really appropriate and there = seems
to be pretty simple workarounds to use IPsec = the
way it was intended to be used. Given that = the
work arounds seems to mostly neutral = depending
on your view of piggybacking, I'd much rather
not have to take on the task of either:

1) changing IPsec selectors
2) changing IKE and/or counting on something = new

Piggybacking is the casualty; so be it. Nice
idea, but not worth the trouble.

 > I find it quite odd that you are bringing = up the IKE++ thing especially when
 > you have been such an ardent Kerberos = proponent. Please explain?

It's actually not contradictory. I think that = IKE
with certificates has scaling problems in = certain
though common cases; the cost of DH/RSA = signatures
is considerable when you are talking about = high
fanout servers/routers. Restart avalanches are = a
large problem, with restart times measured in = the
many, many minutes range.

That said, IKE is here, it works, and warts = and
all is the only workable solution for peer = keying
we have. Other keying schemes MAY eventually
replace IKE where something else is more
appropriate, but given the long and difficult
development cycle for IKE, it would be foolish = to
not hedge bets to some degree by being able = to
drop in what is at least known to work.


 > It seems to me that if you value IPSEC so = much - change it to do the job.
 > People have even gone so far as to make = some suggestions on how to do it.
 > There is nothing wrong with the BU = piggybacking. It aint broke - don't fix
 > it or nuke it; although it may have been = more appropriate to make it a
 > routing header, IMO.

But there is something wrong with it: it = breaks
the intended use of IPsec. Also: it's not = even
clear that a routing update should be carried =
as an option which is normally handled by the
kernel. Indeed, if you don't have access to = the
kernel, having BU's as a UDP or IP proto = would
allow an external daemon to camp on the port
and add the necessary routing updates which = is
almost certainly infeasible as a DO.


        =             Mike

------_=_NextPart_001_01C12432.C18EA3C0-- From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 13 16:04:26 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27919 for ; Mon, 13 Aug 2001 16:04: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 OAA19112; Mon, 13 Aug 2001 14:05: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 NAA21715; Mon, 13 Aug 2001 13:05:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7DK3wJ03584 for mobile-ip-dist; Mon, 13 Aug 2001 13:03:58 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7DK3sD03577 for ; Mon, 13 Aug 2001 13:03:54 -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 NAA18374 for ; Mon, 13 Aug 2001 13:04:04 -0700 (PDT) Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA17956 for ; Mon, 13 Aug 2001 14:04:01 -0600 (MDT) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by hoemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f7DK42c10044 for ; Mon, 13 Aug 2001 16:04:02 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Mon, 13 Aug 2001 21:04:01 +0100 Message-ID: <976F7C55E3B2D111A0720008C728549C097CCA48@en0060exch001u.uk.lucent.com> From: "Casati, Alessio (Alessio)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Heterogeneous Handover - where do i look Date: Mon, 13 Aug 2001 21:04:00 +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: It is feasible and 3G TS 29.061 and 3G TS 23.060 tell at a high level how to do that. This is an optional feature of UMTS and GPRS systems. alessio *>From: "Doradla, Anil" *>To: "'mobile-ip@sunroof.eng.sun.com'" *>Subject: [mobile-ip] Heterogeneous Handover - where do i look *>Date: Fri, 10 Aug 2001 11:28:03 -0500 *>All: *> *>Coming back to the question of handover across heterogeneous wireless *>networks. Can anyone advise me as to where i should look at? *>We are seeing a desire for handover between 802.11 and GPRS *networks. Is *>there any group looking at the feasibility of this ? *> *>Thanks in advance *> *>Anil Doradla *>SBC- Technology Resources, Inc. *>Austin, TX-78727 *> *> *>-----Original Message----- *>From: James Kempf [mailto:James.Kempf@sun.com] *>Sent: Friday, August 10, 2001 3:57 AM *>To: mobile-ip@sunroof.eng.sun.com; mobile-ip@sunroof.eng.sun.com *>Cc: Peter.Dahl *>Subject: RE: [mobile-ip] Heterogeneous Handover - How Would it Work? *> *> *>Glenn, *> *>I think Raj is right on here, sorry. There are enough technical issues *>involved in getting MIP to be deployable that the MIP group really *>needs to focus on. An example is this NAT question. *> *>If there are any operational issues involved in handover *between operators *>that *>need resolution, they should probably be handled in a separate working *>group, like ROAMOPS. An example of such an issue might be advertising *>access routers between operators using something like the Seamoby *>CAR discovery protocol, which is just now getting off the ground. *> *> jak *>>Raj, *>> *>>That's like saying that BGP doesn't deal with the routing *policy related to *>>business relationships between the owners of autonomous *systems. You are *>>shoe-holing the group into only dealing with an enterprise - not the *>>Internet. *>> *>>-----Original Message----- *>>From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com] *>>Sent: Thursday, August 09, 2001 10:55 AM *>>To: mobile-ip *>>Cc: Peter.Dahl *>>Subject: RE: [mobile-ip] Heterogeneous Handover - How Would it Work? *>> *>> *>>Clearly, you are mixing roaming with seamless mobility across *>>heterogeneous *>>access types. The Mobile IP WG does not deal with aspects related to *>>roaming *>>agreements between operators or administrative domains. That *is NOT what *>>this WG is about. *>> *>>-Basavaraj *>> *>>> -----Original Message----- *>>> From: ext Dahl, Peter [mailto:Peter.Dahl@VerizonWireless.com] *>>> Sent: Wednesday, August 08, 2001 1:53 PM *>>> To: 'mobile-ip@sunroof.eng.sun.com' *>>> Subject: RE: [mobile-ip] Heterogeneous Handover - How *Would it Work? *>>> *>>> *>>> ...not forgetting cdma2000. I am not aware of any work in *>>> 3GPP2 or IEEE, *>>> perhaps 3GPP ? *>>> *>>> Pete *>>> *>>> -----Original Message----- *>>> From: Brad Casemore [mailto:bcasemore@home.com] *>>> Sent: Wednesday, August 08, 2001 11:29 AM *>>> To: mobile-ip@sunroof.eng.sun.com *>>> Subject: RE: [mobile-ip] Heterogeneous Handover - How *Would it Work? *>>> *>>> *>>> If that is the case, then WECA's WISPr is dedicated to *>>> 802.11b roaming, *>>> while the ETSI has assigned a group to address GPRS roaming. *>>> Is there a *>>> group anywhere that is looking into the technical issues *>>> associated with *>>> heterogeneous network roaming (such as between, *theoretically, 802.11b *>>> WLANs and GPRS)? *>>> *>>> Brad *>>> *>>> > -----Original Message----- *>>> > From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile- *>>> > ip@sunroof.eng.sun.com] On Behalf Of James Kempf *>>> > Sent: Wednesday, August 08, 2001 2:19 AM *>>> > To: mobile-ip@sunroof.eng.sun.com; mobile-ip@sunroof.eng.sun.com *>>> > Subject: Re: [mobile-ip] Heterogeneous Handover - How *Would it Work? *>>> > *>>> > Pat, *>>> > *>>> > I think they already have such a standard and I believe it *>>> only works *>>> > with GPRS. *>>> > *>>> > jak *>>> > *>>> > >Also, I believe that ETSI is working on a standard *called GRX for *>>> GSM<- *>>> > >802.11 *>>> > >roaming. *>>> > > *>>> > >PatC *>>> > >On Tue, Aug 07, 2001 at 09:32:58AM -0700, Dahl, Peter wrote: *>>> > >> FYI, the Wireless ISPs (WISPs) are already talking about such *>>> roaming *>>> > >> issues. *>>> > >> *>>> > >> There appear to be 2 emerging forums for these *discussions, one *>>> under *>>> > the *>>> > >> auspices of WECA (http://www.weca.net) known as the *WISPr group *>>> ('r' *>>> > being *>>> > >> for roaming), the other a yet to be finalized 'WISP Forum' the *>>> prime *>>> > mover *>>> > >> for which is a company in Luxembourg (www.excilan.com). *>>> > >> *>>> > >> Regards *>>> > >> *>>> > >> -----Original Message----- *>>> > >> From: James Kempf [mailto:James.Kempf@Sun.COM] *>>> > >> Sent: Tuesday, August 07, 2001 8:58 AM *>>> > >> To: mobile-ip@sunroof.eng.sun.com; *mobile-ip@sunroof.eng.sun.com *>>> > >> Subject: Re: [mobile-ip] Heterogeneous Handover - How Would it *>>> Work? *>>> > >> *>>> > >> *>>> > >> >On the other hand, the home address must belong to some *>>> ISP/operator. *>>> > >> >That ISP must provide a home agent and an ip *address, and a CoA *>>> when *>>> > the *>>> > >> >MN is connected to other than the home subnet. Other *>>> ISPs that are *>>> > used *>>> > >> >are only access providers, and would give the MN its *>>> CoA. This of *>>> > course *>>> > >> >would cause political problems. Who are the ISPs that *>>> are willing *>>> to *>>> > be *>>> > >> >access providers only, and who will be providing *home agent and *>>> home *>>> > >> >address as well? *>>> > >> > *>>> > >> *>>> > >> This is an issue. What happens if you have one access *provider on *>>> > >> one interface, say the wCDMA interface, and another on *>>> another, say *>>> > 802.11? *>>> > >> There are now in the US a growing number of 802.11 access *>>> providers, *>>> > >> and I can imagine someone with a laptop having a *wCDMA modem and *>>> > >> an 802.11 card. *>>> > >> *>>> > >> Maybe something like the "roaming consortia" that *have sprung up *>>> > >> around ISP access might evolve, but the protocol *>>> design/engineering *>>> > >> issue is whether there is any additional work (such *as the NAI in *>>> > >> the roaming consortia example) needed to enable *sharing of a home *>>> > >> address among interfaces for which different ISPs are *>>> responsible. *>>> > >> *>>> > >> Something like SUCV, that would allow an ISP to *cryptographically *>>> > identify *>>> > >> to what other ISP an address belonged, might be useful in this *>>> context. *>>> > >> *>>> > >> jak *>>> *> * From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 13 16:47:36 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28455 for ; Mon, 13 Aug 2001 16:47: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 OAA20378; Mon, 13 Aug 2001 14:48: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 NAA16265; Mon, 13 Aug 2001 13:48:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7DKkqc03783 for mobile-ip-dist; Mon, 13 Aug 2001 13:46: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+Sun/8.11.5) with ESMTP id f7DKknD03776 for ; Mon, 13 Aug 2001 13:46: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 NAA26578 for ; Mon, 13 Aug 2001 13:46:59 -0700 (PDT) Message-Id: <200108132046.NAA26578@heliopolis.eng.sun.com> Date: Mon, 13 Aug 2001 13:46:51 -0700 (PDT) From: James Kempf Subject: Re: [mobile-ip] Heterogeneous Handover - How Would it Work? To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: cvQ0hYtIAWBdNZb1OsFBsw== 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, This sounds like an excellent idea. I hope we can get some 3GPP WISP representation, since there seems to be a particular need in this area for defining wireless roaming interoperability. jak >Date: Mon, 13 Aug 2001 08:57:19 -0700 >From: Pat Calhoun >To: mobile-ip@sunroof.eng.sun.com >Subject: Re: [mobile-ip] Heterogeneous Handover - How Would it Work? >Content-Disposition: inline >User-Agent: Mutt/1.2.5i > >Since ROAMOPS was specifically looking at the dial-up market, perhaps it is time >to revive the WG to look at wireless roaming implications. > >Does this make sense? > >PatC > >On Mon, Aug 13, 2001 at 10:50:18AM -0500, Glenn Morrow wrote: >> Charlie, >> >> I'm not sure it will always work for interdomain mobility on handoff. The >> communication between the source and target administrative domains during a >> handoff might need to be enhanced in order to convey the addresses of routes >> (FAs, ARs) that are appropriate for handoff. >> >> This is what I trying to convey. I don't want to see the name changed. We >> should understand that under certain situations the addresses for the source >> and target routers may not even be known across autonomous systems. Defining >> and solving these issues seems to fit into the MIP WG. They are related to >> roaming agreements in a manner. I see ROAMOPS as subscription management - >> not routing. >> >> Glenn >> >> >> >> -----Original Message----- >> From: Charlie Perkins [mailto:charliep@iprg.nokia.com] >> Sent: Friday, August 10, 2001 7:53 PM >> To: mobile-ip@sunroof.eng.sun.com >> Subject: Re: [mobile-ip] Heterogeneous Handover - How Would it Work? >> >> >> Hello Glenn, >> >> Since Mobile IP should work for intradomain mobility, I don't >> see why this would be a good idea. >> >> Regards, >> Charlie P. >> >> >> Glenn Morrow wrote: >> >> > Let's change the description of the MIP WG then: >> > >> > Stick an "Interdomain" before the Routing for Mobile/Wireless Hosts >> > >> > -----Original Message----- >> > From: James Kempf [mailto:James.Kempf@Sun.COM] >> > Sent: Friday, August 10, 2001 4:11 AM >> > To: mobile-ip; mobile-ip >> > Subject: Re: [mobile-ip] Heterogeneous Handover - How Would it Work? >> > >> > >> Something like SUCV, that would allow an ISP to cryptographically >> > identify >> > >> to what other ISP an address belonged, might be useful in this >> > context. >> > > >> > >I didn't read the above in the SUCV draft. SUCV allows nodes to >> > challenge >> > >the node with an SUCV address to show indicate that they have the >> > private >> > >key corresponding to the address. This doesn't identify the ISP as >> > far >> > >as I can tell. >> > >Or do you intend to infer the identity of the ISP from the high-order >> > >> > >bits in the IPv6 address? >> > > >> > >> > Right, the high order bits identify the ISP, the low order identify >> > the mobile node. >> > >> > I suppose there is an issue here in that a mobile node could >> > manufacture >> > the high order bits and thus claim it was from an ISV that it wasn't, >> > >> > but the low order bits should provide proof. >> > >> > jak >> From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 13 17:56:10 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29294 for ; Mon, 13 Aug 2001 17:56:09 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA08530; Mon, 13 Aug 2001 15:57:09 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA01332; Mon, 13 Aug 2001 14:55:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7DLsNe03985 for mobile-ip-dist; Mon, 13 Aug 2001 14:54:23 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7DLsKD03978 for ; Mon, 13 Aug 2001 14:54:20 -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 OAA20843 for ; Mon, 13 Aug 2001 14:54:31 -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 OAA00113 for ; Mon, 13 Aug 2001 14:54:29 -0700 (PDT) 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 f7DLsVi21041 for ; Mon, 13 Aug 2001 16:54:31 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Mon, 13 Aug 2001 16:54:21 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.1600); Mon, 13 Aug 2001 16:54:25 -0500 content-class: urn:content-classes:message Subject: RE: [mobile-ip] Re: mobile-ip] RFC2002bis Date: Mon, 13 Aug 2001 16:54:21 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF441E8419@daebe007.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [mobile-ip] Re: mobile-ip] RFC2002bis X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 Thread-Index: AcEkKxUFpqh995AcEdWxLgAIx6TWeAAF3LKw To: Cc: X-OriginalArrivalTime: 13 Aug 2001 21:54:25.0102 (UTC) FILETIME=[84694EE0:01C12442] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f7DLsKD03979 Sender: owner-mobile-ip@sunroof.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, >> >> The working group chairs recently asked the working group, >> by way of the mailing list, whether this incompatible >> change would be acceptable. The discussion was quite >> limited, somewhat to my surprise. This has been taken >> as evidence that going with HMAC_MD5 is more-or-less >> O.K. Thus, it has been decided to go ahead with the >> change. On the other hand, it is conceivable that not >> all interested parties have been notified of the possible >> change, or have had time to reply. If there are dissenters >> to this change, now would be the time to express that >> opinion. > >A quick question...when this was discussed on the mailing list last >month, Kent and Gopal raised the issue of making MD5 also a MUST >in RFC2002bis. Discussion followed whether MD5 should be a MUST >or a SHOULD for backwards compatibility...with the understanding that >HMAC_MD5 would be a MUST. So, is the idea now not to even mention this >use of MD5? Please clarify. > The intent is to have HMAC-MD5 as the MUST for the authentication algorithm. But MD5 will still be mentioned in the updated I-D. >Thanks, >Madhavi -Basavaraj From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 13 18:05:03 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29445 for ; Mon, 13 Aug 2001 18:05:02 -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 QAA14809; Mon, 13 Aug 2001 16:06:03 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA03704; Mon, 13 Aug 2001 15:05:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7DM4QV04094 for mobile-ip-dist; Mon, 13 Aug 2001 15:04:26 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7DM4MD04087 for ; Mon, 13 Aug 2001 15:04: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 PAA03425 for ; Mon, 13 Aug 2001 15:04:33 -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 QAA13681 for ; Mon, 13 Aug 2001 16:04:30 -0600 (MDT) 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 f7DM4lT09988; Mon, 13 Aug 2001 15:04:47 -0700 (PDT) Received: (mchandra@localhost) by mchandra-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id SAA12776; Mon, 13 Aug 2001 18:04:08 -0400 (EDT) Date: Mon, 13 Aug 2001 18:04:08 -0400 From: "Madhavi W. Chandra" To: Basavaraj.Patil@nokia.com Cc: mobile-ip@sunroof.eng.sun.com, mchandra@cisco.com Subject: [mobile-ip] Re: mobile-ip] Re: mobile-ip] RFC2002bis Message-ID: <20010813180408.C12760@cisco.com> References: <697DAA22C5004B4596E033803A7CEF441E8419@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: <697DAA22C5004B4596E033803A7CEF441E8419@daebe007.NOE.Nokia.com>; from Basavaraj.Patil@nokia.com on Mon, Aug 13, 2001 at 04:54:21PM -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 Mon, Aug 13, 2001 at 04:54:21PM -0500, Basavaraj.Patil@nokia.com wrote: > Hi, > > >> > >> The working group chairs recently asked the working group, > >> by way of the mailing list, whether this incompatible > >> change would be acceptable. The discussion was quite > >> limited, somewhat to my surprise. This has been taken > >> as evidence that going with HMAC_MD5 is more-or-less > >> O.K. Thus, it has been decided to go ahead with the > >> change. On the other hand, it is conceivable that not > >> all interested parties have been notified of the possible > >> change, or have had time to reply. If there are dissenters > >> to this change, now would be the time to express that > >> opinion. > > > >A quick question...when this was discussed on the mailing list last > >month, Kent and Gopal raised the issue of making MD5 also a MUST > >in RFC2002bis. Discussion followed whether MD5 should be a MUST > >or a SHOULD for backwards compatibility...with the understanding that > >HMAC_MD5 would be a MUST. So, is the idea now not to even mention this > > >use of MD5? Please clarify. > > > > The intent is to have HMAC-MD5 as the MUST for the authentication > algorithm. But MD5 will still be mentioned in the updated I-D. OK...but, mentioned HOW? MUST or SHOULD? The issue is that even though IESG advised on HMAC_MD5 as default, we need to ensure backwards compatibility. And I am still unclear on the ramifications that Charlie outlined. Bottom line...breaking backwards compatibility is not acceptable or advisable, especially since there are MIP deployments out there. Thanks, Madhavi > > >Thanks, > >Madhavi > > -Basavaraj From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 13 18:23:07 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29604 for ; Mon, 13 Aug 2001 18:23:06 -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 PAA05041; Mon, 13 Aug 2001 15:24: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 PAA07130; Mon, 13 Aug 2001 15:23:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7DMMED04217 for mobile-ip-dist; Mon, 13 Aug 2001 15:22:14 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7DMMBD04210 for ; Mon, 13 Aug 2001 15:22: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 PAA21168 for ; Mon, 13 Aug 2001 15:22:22 -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 PAA16764 for ; Mon, 13 Aug 2001 15:22:21 -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 f7DMNGI09212 for ; Mon, 13 Aug 2001 17:23:16 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Mon, 13 Aug 2001 17:22:12 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.1600); Mon, 13 Aug 2001 17:22:09 -0500 content-class: urn:content-classes:message Subject: [mobile-ip] RE: mobile-ip] Re: mobile-ip] RFC2002bis Date: Mon, 13 Aug 2001 17:22:08 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF441E841D@daebe007.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: mobile-ip] Re: mobile-ip] RFC2002bis X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 Thread-Index: AcEkQ/DlCXo+WpA0EdWrxAAIx6S5QwAAiBDw To: Cc: X-OriginalArrivalTime: 13 Aug 2001 22:22:09.0056 (UTC) FILETIME=[64348A00:01C12446] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f7DMMBD04211 Sender: owner-mobile-ip@sunroof.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 Okay here's the proposed text in the I-D : " 5.1. Message Authentication Codes Home agents and mobile nodes MUST be able to perform authentication. The default algorithm is HMAC-MD5 [23], 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 [40] 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. More authentication algorithms, algorithm modes, key distribution methods, and key sizes MAY also be supported for all of these extensions. " I realize your concern about backwards compatibility, but as Pat mentioned earlier the 2002 spec itself had a bug and since we are in the process of fixing that, we can also fix the security vulnerabiltiy. -Basavaraj > > On Mon, Aug 13, 2001 at 04:54:21PM -0500, > Basavaraj.Patil@nokia.com wrote: > > Hi, > > > > >> > > >> The working group chairs recently asked the working group, > > >> by way of the mailing list, whether this incompatible > > >> change would be acceptable. The discussion was quite > > >> limited, somewhat to my surprise. This has been taken > > >> as evidence that going with HMAC_MD5 is more-or-less > > >> O.K. Thus, it has been decided to go ahead with the > > >> change. On the other hand, it is conceivable that not > > >> all interested parties have been notified of the possible > > >> change, or have had time to reply. If there are dissenters > > >> to this change, now would be the time to express that > > >> opinion. > > > > > >A quick question...when this was discussed on the mailing list last > > >month, Kent and Gopal raised the issue of making MD5 also a MUST > > >in RFC2002bis. Discussion followed whether MD5 should be a MUST > > >or a SHOULD for backwards compatibility...with the > understanding that > > >HMAC_MD5 would be a MUST. So, is the idea now not to even > mention this > > > > >use of MD5? Please clarify. > > > > > > > The intent is to have HMAC-MD5 as the MUST for the authentication > > algorithm. But MD5 will still be mentioned in the updated I-D. > > OK...but, mentioned HOW? MUST or SHOULD? The issue is that > even though IESG advised on HMAC_MD5 as default, we need to ensure > backwards compatibility. And I am still unclear on the ramifications > that Charlie outlined. > > Bottom line...breaking backwards compatibility is not acceptable or > advisable, especially since there are MIP deployments out there. > > Thanks, > Madhavi > > > > > >Thanks, > > >Madhavi > > > > -Basavaraj > From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 13 18:28:14 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29664 for ; Mon, 13 Aug 2001 18:28: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 QAA29924; Mon, 13 Aug 2001 16:29: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 PAA08144; Mon, 13 Aug 2001 15:28:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7DMS2w04310 for mobile-ip-dist; Mon, 13 Aug 2001 15:28:02 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7DMRwD04299 for ; Mon, 13 Aug 2001 15:27:58 -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 PAA22239 for ; Mon, 13 Aug 2001 15:28: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 QAA29158 for ; Mon, 13 Aug 2001 16:28:04 -0600 (MDT) Received: (qmail 9097 invoked by uid 500); 13 Aug 2001 22:16:31 -0000 Date: Mon, 13 Aug 2001 15:16:31 -0700 From: Pat Calhoun To: mobile-ip@sunroof.eng.sun.com Cc: Basavaraj.Patil@nokia.com, mchandra@cisco.com Subject: Re: [mobile-ip] Re: mobile-ip] Re: mobile-ip] RFC2002bis Message-ID: <20010813151631.A9046@charizard.diameter.org> References: <697DAA22C5004B4596E033803A7CEF441E8419@daebe007.NOE.Nokia.com> <20010813180408.C12760@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: <20010813180408.C12760@cisco.com>; from mchandra@cisco.com on Mon, Aug 13, 2001 at 06:04:08PM -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: > OK...but, mentioned HOW? MUST or SHOULD? The issue is that > even though IESG advised on HMAC_MD5 as default, we need to ensure > backwards compatibility. And I am still unclear on the ramifications > that Charlie outlined. As a SHOULD > > Bottom line...breaking backwards compatibility is not acceptable or > advisable, especially since there are MIP deployments out there. But wouldn't it be irresponsible for us to tell folks to use something that is known to be cryptographically weak? Do we really want another WEP fiasco? As I've mentioned before, the fact that is a SHOULD will lead people to add a switch to allow admins to turn it on/off. That's all we want. People that care, and want to make money, will support both modes. Further, shipping products based on a proposed standard has always been risky, since things can change when moving to Draft Standard (and believe me, I've been on the receiving side more than once). PatC From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 13 21:38:02 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02427 for ; Mon, 13 Aug 2001 21:38: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 TAA05322; Mon, 13 Aug 2001 19:38: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 SAA27328; Mon, 13 Aug 2001 18:38:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7E1XZ104867 for mobile-ip-dist; Mon, 13 Aug 2001 18:33:35 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7E1XWD04860 for ; Mon, 13 Aug 2001 18:33:32 -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 SAA19134 for ; Mon, 13 Aug 2001 18:33:43 -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 SAA20692 for ; Mon, 13 Aug 2001 18:33: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 f7E1XxT00513 for ; Mon, 13 Aug 2001 18:33: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 ACP12167; Mon, 13 Aug 2001 18:33:40 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id SAA17209; Mon, 13 Aug 2001 18:33:40 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15224.32756.650477.37989@thomasm-u1.cisco.com> Date: Mon, 13 Aug 2001 18:33:40 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Piggybacking In-Reply-To: <85AA7486A2C1D411BCA20000F8073E430318C4AC@crchy271.us.nortel.com> References: <85AA7486A2C1D411BCA20000F8073E430318C4AC@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 I'm not really sure what this outburst is about, but it doesn't seem to have much to do with the merits of piggybacking so I'll bow out. Mike Glenn Morrow writes: > Well I couldn't resist one last comment - Gosh - why doesn't RSVP use > IPSEC? > > Apparently IPSEC isn't to blame for this either? > > I think we should force RSVP to use IPSEC based upon your logic. Hey - I > guess we'll have to get rid of the router alert to get RSVP to work. Routing > headers are O.K. though. Yeah - each router knows based upon the destination > address in the routing header where to directly send the packet hop by hop > or over tunnels - that's the ticket. > > RSVP would be too complex with the router alert in conjunction with IPSEC > based upon your logic? RSVP needs to rely on IKE for distribution - it has > to or the sky will fall out. I guess we can't use RSVP at all ever because > it doesn't use IKE and IPSEC. I guess there is something inherently wrong > with RSVP - it breaks IPSEC. We wouldn't be leveraging our bets if all > routers and hosts which employ RSVP didn't use IKE for key distribution. > > Though these arguments above are quite ludicrous, it does hopefully point > out the injustice in your reasoning. > > As I recall authors of MIP did have designs on IPSEC to handle the exact > point we are discussing now and apparently their arguments for its > definitition didn't make it in probably because wireless devices were a > twinkle in most peoples' (wirehead) eyes at the time or they simply didn't > understand the intent; nevertheless, here we are today. So blame is probably > disputable. > > > RSVP didn't use IPSEC because it wasn't designed to deal with that > particular network service. To force IPSEC on MIP or take things away from > it so it can use IPSEC would be pathetic. TLS/HTTPs don't use IPSEC. I don't > see people standing up and yelling about that and the service seems to work > just fine. It seems that IKE can be used in conjunction with TLS too - > right? MIP could use IKE++ for key distribution without IPSEC. These are > disjunct issues. > > As for the routing updates being handled by the kernal, I personally feel > that per node routing updates belong in purpose built machines (routers) > designed to handle the lookups of fairly large cached routing tables at the > edge - not hosts. But that is an entirely different topic. I think when we > finally get into more optimization issues in conjunction with other network > based services such as multicast, VPNs, anycast, privacy and security > threats, people will eventually change their tune. I suspect a few highly > publicized civil cases involving the victims of stalkers or assassins will > provide the impetus. > > The original BBNers seemed to take this purpose built machine thought into > account. Perhaps I'm old school on this but I guess time will tell. The fact > that there is no IPv6 checksum certainly eliminates a great deal of concern > about the bundling of options and their removal before delivery to the upper > layers or end-hosts irrespective of whether they contained routing > information or not. > > :) > > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Monday, August 13, 2001 12:45 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: RE: [mobile-ip] Piggybacking > > > Glenn Morrow writes: > > What is your goal in trying to get rid of the piggybacking: > > > > 1> rock the boat marketing > > 2> nuke MIPv6 down to MIPv4 > > 3> use IPSEC and don't change IPSEC > > 3. I'm not convinced that IPsec is what was to > blame here. MIPv6 was trying to use it in a way > that wasn't really appropriate and there seems > to be pretty simple workarounds to use IPsec the > way it was intended to be used. Given that the > work arounds seems to mostly neutral depending > on your view of piggybacking, I'd much rather > not have to take on the task of either: > > 1) changing IPsec selectors > 2) changing IKE and/or counting on something new > > Piggybacking is the casualty; so be it. Nice > idea, but not worth the trouble. > > > I find it quite odd that you are bringing up the IKE++ thing especially > when > > you have been such an ardent Kerberos proponent. Please explain? > > It's actually not contradictory. I think that IKE > with certificates has scaling problems in certain > though common cases; the cost of DH/RSA signatures > is considerable when you are talking about high > fanout servers/routers. Restart avalanches are a > large problem, with restart times measured in the > many, many minutes range. > > That said, IKE is here, it works, and warts and > all is the only workable solution for peer keying > we have. Other keying schemes MAY eventually > replace IKE where something else is more > appropriate, but given the long and difficult > development cycle for IKE, it would be foolish to > not hedge bets to some degree by being able to > drop in what is at least known to work. > > > > It seems to me that if you value IPSEC so much - change it to do the job. > > People have even gone so far as to make some suggestions on how to do it. > > There is nothing wrong with the BU piggybacking. It aint broke - don't > fix > > it or nuke it; although it may have been more appropriate to make it a > > routing header, IMO. > > But there is something wrong with it: it breaks > the intended use of IPsec. Also: it's not even > clear that a routing update should be carried > as an option which is normally handled by the > kernel. Indeed, if you don't have access to the > kernel, having BU's as a UDP or IP proto would > allow an external daemon to camp on the port > and add the necessary routing updates which is > almost certainly infeasible as a DO. > > > Mike > > > > > > RE: [mobile-ip] Piggybacking > > > >

Well I couldn't resist one last comment - Gosh  - why doesn't RSVP use IPSEC? >

> >

Apparently IPSEC isn't to blame for this either?  >

> >

I think we should force RSVP to use IPSEC based upon your logic. Hey - I guess we'll have to get rid of the router alert to get RSVP to work. Routing headers are O.K. though. Yeah - each router knows based upon the destination address in the routing header where to directly send the packet hop by hop or over tunnels - that's the ticket.

> >

RSVP would be too complex with the router alert in conjunction with IPSEC based upon your logic? RSVP needs to rely on IKE for distribution - it has to or the sky will fall out. I guess we can't use RSVP at all ever because it doesn't use IKE and IPSEC. I guess there is something inherently wrong with RSVP - it breaks IPSEC. We wouldn't be leveraging our bets if all routers and hosts which employ RSVP didn't use IKE for key distribution.

> >

Though these arguments above are quite ludicrous, it does hopefully point out the injustice in your reasoning. >

> >

As I recall authors of MIP did have designs on IPSEC to handle the exact point we are discussing now and apparently their arguments for its definitition didn't make it in probably because wireless devices were a twinkle in most peoples' (wirehead) eyes at the time or they simply didn't understand the intent; nevertheless, here we are today. So blame is probably disputable.

>
> >

RSVP didn't use IPSEC because it wasn't designed to deal with that particular network service. To force IPSEC on MIP or take things away from it so it can use IPSEC would be pathetic. TLS/HTTPs don't use IPSEC. I don't see people standing up and yelling about that and the service seems to work just fine. It seems that IKE can be used in conjunction with TLS too - right? MIP could use IKE++ for key distribution without IPSEC. These are disjunct issues.

> >

As for the routing updates being handled by the kernal, I personally feel that per node routing updates belong in purpose built machines (routers) designed to handle the lookups of fairly large cached routing tables at the edge - not hosts. But that is an entirely different topic. I think when we finally get into more optimization issues in conjunction with other network based services such as multicast, VPNs, anycast, privacy and security threats, people will eventually change their tune. I suspect a few highly publicized civil cases involving the victims of stalkers or assassins will provide the impetus.

> >

The original BBNers seemed to take this purpose built machine thought into account. Perhaps I'm old school on this but I guess time will tell. The fact that there is no IPv6 checksum certainly eliminates a great deal of concern about the bundling of options and their removal before delivery to the upper layers or end-hosts irrespective of whether they contained routing information or not.

> >

:) >

> >

-----Original Message----- >
From: Michael Thomas [mailto:mat@cisco.com] >
Sent: Monday, August 13, 2001 12:45 PM >
To: mobile-ip@sunroof.eng.sun.com >
Subject: RE: [mobile-ip] Piggybacking >

>
> >

Glenn Morrow writes: >
 > What is your goal in trying to get rid of the piggybacking: >
 > >
 > 1> rock the boat marketing >
 > 2> nuke MIPv6 down to MIPv4 >
 > 3> use IPSEC and don't change IPSEC >

> >

3. I'm not convinced that IPsec is what was to >
blame here. MIPv6 was trying to use it in a way >
that wasn't really appropriate and there seems >
to be pretty simple workarounds to use IPsec the >
way it was intended to be used. Given that the >
work arounds seems to mostly neutral depending >
on your view of piggybacking, I'd much rather >
not have to take on the task of either: >

> >

1) changing IPsec selectors >
2) changing IKE and/or counting on something new >

> >

Piggybacking is the casualty; so be it. Nice >
idea, but not worth the trouble. >

> >

 > I find it quite odd that you are bringing up the IKE++ thing especially when >
 > you have been such an ardent Kerberos proponent. Please explain? >

> >

It's actually not contradictory. I think that IKE >
with certificates has scaling problems in certain >
though common cases; the cost of DH/RSA signatures >
is considerable when you are talking about high >
fanout servers/routers. Restart avalanches are a >
large problem, with restart times measured in the >
many, many minutes range. >

> >

That said, IKE is here, it works, and warts and >
all is the only workable solution for peer keying >
we have. Other keying schemes MAY eventually >
replace IKE where something else is more >
appropriate, but given the long and difficult >
development cycle for IKE, it would be foolish to >
not hedge bets to some degree by being able to >
drop in what is at least known to work. >

>
> >

 > It seems to me that if you value IPSEC so much - change it to do the job. >
 > People have even gone so far as to make some suggestions on how to do it. >
 > There is nothing wrong with the BU piggybacking. It aint broke - don't fix >
 > it or nuke it; although it may have been more appropriate to make it a >
 > routing header, IMO. >

> >

But there is something wrong with it: it breaks >
the intended use of IPsec. Also: it's not even >
clear that a routing update should be carried >
as an option which is normally handled by the >
kernel. Indeed, if you don't have access to the >
kernel, having BU's as a UDP or IP proto would >
allow an external daemon to camp on the port >
and add the necessary routing updates which is >
almost certainly infeasible as a DO. >

>
> >

                    Mike >

> > > From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 13 22:36:35 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03901 for ; Mon, 13 Aug 2001 22:36: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 TAA12340; Mon, 13 Aug 2001 19:37: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 TAA24872; Mon, 13 Aug 2001 19:37:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7E2Zn005114 for mobile-ip-dist; Mon, 13 Aug 2001 19:35:49 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7E2ZkD05107 for ; Mon, 13 Aug 2001 19:35:46 -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 TAA13175 for ; Mon, 13 Aug 2001 19:35:55 -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 UAA25296 for ; Mon, 13 Aug 2001 20:35:50 -0600 (MDT) Received: from cychong (a22416 [165.213.224.16]) by telecom.samsung.co.kr (8.9.3/8.9.3) with SMTP id LAA07394 for ; Tue, 14 Aug 2001 11:38:33 +0900 (KST) Message-ID: <000801c1246a$71d45a40$10e0d5a5@cychong> From: "Chae-yong Chong" To: References: <697DAA22C5004B4596E033803A7CEF440861F0@daebe007.NOE.Nokia.com> Subject: Re: [mobile-ip] RFC2002bis Date: Tue, 14 Aug 2001 11:40:12 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.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 f7E2ZkD05108 Sender: owner-mobile-ip@sunroof.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 mean that they - operators in Korea - have already deployed the product for Mobile IP service such as PDSN/FA and HA. However I have not heard that there are commercial or free software for Mobile Node. We tested that Mobility with the software which works in Linux. You know Linux software is not easy to be a commercial product :-) What I want to say is that the system working well for Mobile IP. But I think there is no subscriber who is using the Mobile IP service. Regards Chae-yong ----- Original Message ----- From: To: Cc: Sent: Monday, August 13, 2001 5:49 PM Subject: RE: [mobile-ip] RFC2002bis > Hi. > > > >This is just an information for you. > > > > Thanks for the update. > > >The IS-835 network is already deployed in Korea on a commercial basis. > >If you asked that how many subscribers are using Mobile IP service, I > am > >sorry not to give you an exact answer. That answer could be given by > >some guys of Operators, SK Telecom ro KTF :-) > >I think you all just consider the situation of North American. :-( > > > > Not necessarily. We are equally aware of developments in other > regions :) > > >As far as I know, there is no commercial product for > >Mobile Node software. Okay. I agree that you could assume that > > You mentioned above that the network is already operational. Yet there > are no commercial products (terminals supporting MN software)? Can you > elaborate what you mean by "commercial product for Mobile Node > software"? > > >the current deployment in Korea could be regarded to a nothing. > >(If the number of Mobile IP service subscriber is just trivial) > >I just write this message to let you know that IS-835 is ALREADY > >deployed somewhere :-) > > > >Chae-yong > > > > -Basavaraj > > >> The IS-835 network is not yet deployed on a commercial basis. And you > >> seem to agree that the above fixes would be good for the spec. Would > >> make sense to consider making these changes now than later when it is > >> deployed. > >> > >> >----------------------------------- > >> >Marcello (Wandering through France) > >> > > >> > >> -Basavaraj > >> > > From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 13 22:53:45 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04356 for ; Mon, 13 Aug 2001 22:53: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 UAA01807; Mon, 13 Aug 2001 20:54:44 -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 TAA00051; Mon, 13 Aug 2001 19:54:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7E2rR305257 for mobile-ip-dist; Mon, 13 Aug 2001 19:53:27 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7E2rND05250 for ; Mon, 13 Aug 2001 19:53:23 -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 TAA26331 for ; Mon, 13 Aug 2001 19:53:32 -0700 (PDT) Received: from tailor.sailpix.com (ns1.sailpix.com [155.53.1.250]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA28327 for ; Mon, 13 Aug 2001 20:53:43 -0600 (MDT) Received: from atty.lounge.org (tycho-205-179-127-181.tychonet.com [205.179.127.181]) by tailor.sailpix.com (Postfix) with ESMTP id 2364F54C48 for ; Mon, 13 Aug 2001 19:53:31 -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 f7E2qLn00537 for ; Mon, 13 Aug 2001 19:52:22 -0700 (PDT) (envelope-from dharkins@lounge.org) Message-Id: <200108140252.f7E2qLn00537@dharkins@lounge.orgatty.lounge.org> To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] About authorization and security policies In-Reply-To: Your message of "Wed, 08 Aug 2001 13:25:31 BST." <3B712FBB.607E428B@nomadiclab.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <534.997757541.1@lounge.org> Date: Mon, 13 Aug 2001 19:52:21 -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: On Wed, 08 Aug 2001 13:25:31 BST you wrote > > Case C. IKE and -14 authentication > > If we want to use IKE with -14 authentication, we basically need > a new DOI (or extension to the Internet DOI), specifying how > authentication data for -14 BU authentication is created. Why? The DOI does not specify how authentication data is created. That is done in AH (2402) or ESP (2406) RFC. Dan. From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 14 01:46:39 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12187 for ; Tue, 14 Aug 2001 01:46:38 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA00145; Mon, 13 Aug 2001 23:47: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 WAA14762; Mon, 13 Aug 2001 22:47:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7E5k3I05482 for mobile-ip-dist; Mon, 13 Aug 2001 22:46:03 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7E5k0D05475 for ; Mon, 13 Aug 2001 22:46: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 WAA11123 for ; Mon, 13 Aug 2001 22:46:11 -0700 (PDT) From: john.loughney@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA18702 for ; Mon, 13 Aug 2001 22:46:09 -0700 (PDT) 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 f7E5kX303434 for ; Tue, 14 Aug 2001 08:46:33 +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, 14 Aug 2001 08:46:08 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MSVSG3Y>; Tue, 14 Aug 2001 08:46:08 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF094139@esebe004.NOE.Nokia.com> To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Heterogeneous Handover - How Would it Work? Date: Tue, 14 Aug 2001 08:45:57 +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 Pat, > Since ROAMOPS was specifically looking at the dial-up market, > perhaps it is time to revive the WG to look at wireless roaming > implications. > > Does this make sense? I had hoped that this would be something addressable in (B)URP ... Or am I totally off base? John From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 14 02:34:42 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22944 for ; Tue, 14 Aug 2001 02:34: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 AAA17844; Tue, 14 Aug 2001 00:35:41 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA18737; Mon, 13 Aug 2001 23:35:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7E6YTe05650 for mobile-ip-dist; Mon, 13 Aug 2001 23:34:29 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7E6YPD05643 for ; Mon, 13 Aug 2001 23:34:25 -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 XAA03331 for ; Mon, 13 Aug 2001 23:34:37 -0700 (PDT) Received: from ws2.piuha.net (ws2.piuha.net [195.165.196.2]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA09500 for ; Mon, 13 Aug 2001 23:34:36 -0700 (PDT) Received: from piuha.net (ws4.piuha.net [195.165.196.4]) by ws2.piuha.net (Postfix) with ESMTP id D0D106A904 for ; Tue, 14 Aug 2001 09:34:19 +0300 (EEST) Message-ID: <3B78C788.1040609@piuha.net> Date: Tue, 14 Aug 2001 09:39:04 +0300 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.3-ipsec i686; en-US; m18) Gecko/20001107 Netscape6/6.0 X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] About authorization and security policies References: <200108140252.f7E2qLn00537@dharkins@lounge.orgatty.lounge.org> 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 Dan Harkins wrote: >> If we want to use IKE with -14 authentication, we basically need >> a new DOI (or extension to the Internet DOI), specifying how >> authentication data for -14 BU authentication is created. > > Why? The DOI does not specify how authentication data is created. > That is done in AH (2402) or ESP (2406) RFC. The use of IKE with -14 authentication doesn't require a full DoI. It requires an _extension_ to the current DoI. Such extensions are regurlarly done to add algorithms. This extension would be a bit bigger perhaps -- adding a new protocol -- but still basically a number allocation in some defined place. However, one drawback of using IKE with -14 authentication is that other key management protocols would have to be updated also. For instance, the possible Son-of-IKE protocol would also be affected. (It may be that all these protocols share the same DoI and algorithm numbers, but I'm not sure if this would be the case always.) Jari From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 14 05:53:05 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25189 for ; Tue, 14 Aug 2001 05:53:04 -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 CAA11653; Tue, 14 Aug 2001 02:54: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 CAA29951; Tue, 14 Aug 2001 02:53:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7E9pmf05996 for mobile-ip-dist; Tue, 14 Aug 2001 02:51:48 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7E9pjD05989 for ; Tue, 14 Aug 2001 02:51:45 -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 CAA03545; Tue, 14 Aug 2001 02:51:56 -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 CAA09421; Tue, 14 Aug 2001 02:51:55 -0700 (PDT) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f7E9psN29167; Tue, 14 Aug 2001 11:51:54 +0200 (MEST) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id LAA15544; Tue, 14 Aug 2001 11:51:53 +0200 Message-ID: <3B78F44F.FDDE08B7@era.ericsson.se> Date: Tue, 14 Aug 2001 11:50:07 +0200 From: Mattias Pettersson Organization: Ericsson Research X-Mailer: Mozilla 4.77 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Erik Nordmark CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile Routers support without optimization 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 [Dropped T.J. from CC list since I believe he's on mobile-ip anyway] Erik Nordmark wrote: > Are you concerned about the link-local addresses used e.g. by OSPF to > communicate with the routers on the home link, or some other use of > link locals? That's right. Routing protocols such as OSPF or RIP uses link-local addresses, both for communication and of course identifies adjacent routers by their link-local addresses. > > Given the current specification, which says that the HA must not tunnel > link locals to the MN, I think the only solution is > to make the MR, when away from home, have a router adjacency with the HA > i.e. it will be two hops away from the other routers on the home link. > This might mean that when moving to or from the home link all > the adjacencies will be torn down and new ones created. > Or it could choose to always maintain a tunneled adjacency with the HA - even > when at home. Both sounds reasonable. But home agents are routers, and if you want redundancy or load sharing by using multiple home agents on the home link, you would anyway end up with multiple routers adjacent to the MR. Unless you explicitly choose one of the HAs, also when you are at home. Regarding your first proposal to have MR adjacent to all routers on the home link when it is home, and then make it reachable behind the HA when not at home: how fast can routing protocols reflect this change? If the other routers are not updated quickly when the MR moves away, they will keep sending packets to MR's link-local address (according to routing protocol). The HA has sent proxy NA for MR's link-local address, and the packets will end up at the HA, which will tunnel them to the MR. This way will work. Soon after MR has moved away it will now send routing protocol updates through the bi-directional tunnel to the HA. Routers on the home link will know the mobile network is behind HA. They will now send packets to the HA's link-local address. When the MR returns home, MR will de-register with HA. Still, the routers have the HA's link-local address as gateway for the mobile network, until the MR sends new routing protocol updates on the link. During this interval, packets will be lost. The HA itself doesn't know where to send the packets that the routers keep sending to it. Either, synchronize the BUs with the routing protocol updates, or use a tunnel to the HA, also when the MR is at home. > > > Maybe Mobile IPv6 should be changed to tunnel *all* packets. > > But that means that the MN will see e.g. all mulicast ND packets which might > not be that good use of bandwidth. From an architectural perspective this > would make the HA an L2 bridge instead of a L3 router. > If there are different links the thing that connects them is a router > and link-locals don't cross between links. > Ok. Or maybe ND packets can be filtered out. /Mattias From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 14 08:09:23 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28512 for ; Tue, 14 Aug 2001 08:09: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 FAA13366; Tue, 14 Aug 2001 05:10:12 -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 FAA09241; Tue, 14 Aug 2001 05:09:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7EC8Lj06268 for mobile-ip-dist; Tue, 14 Aug 2001 05:08:21 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7EC8ID06261 for ; Tue, 14 Aug 2001 05:08:18 -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 FAA27776 for ; Tue, 14 Aug 2001 05:08:19 -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 GAA28556 for ; Tue, 14 Aug 2001 06:08:27 -0600 (MDT) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate4.mot.com (motgate4 2.1) with ESMTP id FAA19805 for ; Tue, 14 Aug 2001 05:08:17 -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 FAA15601 for ; Tue, 14 Aug 2001 05:08:16 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r4.mot.com with ESMTP for mobile-ip@sunroof.eng.sun.com; Tue, 14 Aug 2001 07:08:16 -0500 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id A54782ED1A for ; Mon, 13 Aug 2001 16:26:02 +0200 (CEST) To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile Routers support without optimization References: From: Alexandru Petrescu Date: 13 Aug 2001 16:26:18 +0200 In-Reply-To: Message-Id: Lines: 21 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: Erik Nordmark writes: [...] > But, what problem are we really trying to solve by being able to > send a BU for a whole prefix? This seems like optimizing something > which is close to a non-problem. Yes, I would also like to see it more clearly. As I understand it from Thierry's works: -avoid that every MN sends a BU when the entire subnet changes the attachment point. Send only one BU covering all MN's. -avoid maintaining "per-host tunnels" in the HA for every MN in the mobile subnet. Use routing features instead, only one entry in the HA's binding cache for all MN's in the mobile subnet. -the MN's in the mobile network are not aware of mobility. We should probably evaluate how much of the above items are non-problems and how much of them are true problems. Cheers, Alex From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 14 08:09:28 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28534 for ; Tue, 14 Aug 2001 08:09: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 GAA17761; Tue, 14 Aug 2001 06:10: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 FAA09240; Tue, 14 Aug 2001 05:09:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7EC8Pb06277 for mobile-ip-dist; Tue, 14 Aug 2001 05:08:25 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7EC8LD06270 for ; Tue, 14 Aug 2001 05:08: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 FAA27780 for ; Tue, 14 Aug 2001 05:08:22 -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 GAA28607 for ; Tue, 14 Aug 2001 06:08:31 -0600 (MDT) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate4.mot.com (motgate4 2.1) with ESMTP id FAA19874 for ; Tue, 14 Aug 2001 05:08:21 -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 FAA03674 for ; Tue, 14 Aug 2001 05:00:26 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r4.mot.com with ESMTP for mobile-ip@sunroof.eng.sun.com; Tue, 14 Aug 2001 07:08:15 -0500 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id AF6242ED26 for ; Mon, 13 Aug 2001 16:46:41 +0200 (CEST) To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile Routers support without optimization References: From: Alexandru Petrescu Date: 13 Aug 2001 16:46:57 +0200 In-Reply-To: Message-Id: Lines: 41 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: Erik Nordmark writes: > When I'm at home the PAN router has adjancencies with other routers attached > to the home link which it uses to exchange routing information about the > subnet prefixes assigned to my PAN. > > When I move away from home it is sufficient for the PAN router to > - send a binding update for its own address (which the other routers > have as the nexthop in the routing tables). This BU will > have the R-bit set so that NUD works. > - tunnel all traffic from the PAN back to the home network. There's at least one thing that won't work in this scenario: when HA defends MR's Home Address it has an entry in the Binding Cache containing MR's CoA and MR's Home Address, but not the MNN's Home Address. Thus it can't relate an incoming packet for that MNN to that MNN's Home Address. Unless more clarification is added to how the Binding Cache is searched. Quoting from -13: "- The home address of the mobile node for which this is the Binding Cache entry. This field is used as the key for searching the Binding Cache for the destination address of a packet being sent. If the destination address of the packet matches the home address in the Binding Cache entry, this entry SHOULD be used in routing that packet." "- The care-of address for the mobile node indicated by the home address field in this Binding Cache entry. If the destination address of a packet being routed by a node matches the home address in this entry, the packet SHOULD be routed to this care-of address, as described in Section 8.9, for packets originated by this node, or in Section 9.6, if this node is the mobile node's home agent and the packet was intercepted by it on the home link." Having said this, I know there'll be change on how and where this subject will be treated, I'll adapt accordingly later. Alex From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 14 08:09:28 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28535 for ; Tue, 14 Aug 2001 08:09:28 -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 FAA13369; Tue, 14 Aug 2001 05:10: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 FAA09239; Tue, 14 Aug 2001 05:09:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7EC8eK06286 for mobile-ip-dist; Tue, 14 Aug 2001 05:08:40 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7EC8aD06279 for ; Tue, 14 Aug 2001 05:08:36 -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 FAA12107 for ; Tue, 14 Aug 2001 05:08:37 -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 FAA00420 for ; Tue, 14 Aug 2001 05:08:36 -0700 (PDT) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate4.mot.com (motgate4 2.1) with ESMTP id FAA19976 for ; Tue, 14 Aug 2001 05:08:36 -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 FAA03864 for ; Tue, 14 Aug 2001 05:00:46 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r4.mot.com with ESMTP for mobile-ip@sunroof.eng.sun.com; Tue, 14 Aug 2001 07:08:35 -0500 Received: from crm.mot.com (nero.crm.mot.com [140.101.173.36]) by thorgal.crm.mot.com (Postfix) with ESMTP id 79BB32ED20 for ; Mon, 13 Aug 2001 16:33:35 +0200 (CEST) Message-Id: <3B77E54C.689ECF35@crm.mot.com> Date: Mon, 13 Aug 2001 16:33:48 +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 Subject: Re: [mobile-ip] Mobile Routers support without optimization References: Content-Type: multipart/mixed; boundary="------------3988FC29DDCA5932DCBA156A" Sender: owner-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. --------------3988FC29DDCA5932DCBA156A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Erik Nordmark wrote: > > > Actually Binding Updates for prefixes do not disable route optimization > > feature. Clearly, the authorization process is trickier. It can however > > be performed provided that it makes use of the knowledge the HA has > > about the binding 'Mobile Prefix' / 'Mobile Router'. HA can then be > > asked by the CN before CN updates its Binding Cache upon receiption of a > > prefix BU. > > I don't understand how the CN checking with the HA solves the trust issue > for using BUs to redirect whole prefixes. > > Example: I run a MN and a HA . My MN sends a BU for a /3 to a CN > the fact that my MN says "yes" when the CN asks if the binding is ok. First I think you mean " HA says 'yes' " (?) A part of your text seem to have disappeared here... In my understanding you have a malicious Mobile Router _and_ a malicious Home Agent, the former counting on the latter to validate faked Binding Updates. Now when CN sends a 'question message' to MR's Home Address, malicious HA should not discard the message but continue the process. Well... but the question is: why would the home address be routed towards your attacking Home Agent? Do you mean you have also managed to remotely configure routing tables of the target Home Network? Then you are not limited to a faked BU attack and can envision large scale DoS against the Home Network... > The redirection of a prefix must be related to the routing for that whole > prefix going to the HA. In general you can't verify that this is the case > for a prefix without actually sending packets to all IP addresses in the > prefix and seeing that you get a response back from the HA. Correct me if I am wrong: you mean that BAKE is secure in the sense that the reachability of the MN is verfied. For a MR we should then verify the reachability of all nodes the MR serves. I do not think it is the only means. In the solution we propose, we use the same process to make sure that we can reach the MR via its Home Address (so should be each node below, provided that MR does not lie). BUT in addition to that basic verification, HA is required to check the prefix the MR sent a BU for (check the binding [MR H@ / Mobile prefix]). Thus we guarantee that any node served by MR will be reachable through the new MR Care-of Address. Alexis. --------------3988FC29DDCA5932DCBA156A 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 --------------3988FC29DDCA5932DCBA156A-- From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 14 08:19:43 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29199 for ; Tue, 14 Aug 2001 08:19: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 FAA16311; Tue, 14 Aug 2001 05:20: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 FAA10528; Tue, 14 Aug 2001 05:20:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7ECJ9J06553 for mobile-ip-dist; Tue, 14 Aug 2001 05:19:09 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7ECJ5D06542 for ; Tue, 14 Aug 2001 05:19:06 -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 FAA10356 for ; Tue, 14 Aug 2001 05:19:07 -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 FAA21503 for ; Tue, 14 Aug 2001 05:19:06 -0700 (PDT) Received: from inrialpes.fr (galibier.inrialpes.fr [194.199.24.97]) by ebene.inrialpes.fr (8.11.3/8.11.3) with ESMTP id f7ECFub19364 for ; Tue, 14 Aug 2001 14:15:56 +0200 (MEST) Message-ID: <3B791712.402C5195@inrialpes.fr> Date: Tue, 14 Aug 2001 14:18:26 +0200 From: Thierry Ernst Organization: INRIA Rhone-Alpes X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile Routers support without optimization References: <3B77E391.1E9A5D34@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 Mattias Pettersson wrote: > > When I move away from home it is sufficient for the PAN router to > > - send a binding update for its own address (which the other routers > > have as the nexthop in the routing tables). This BU will > > have the R-bit set so that NUD works. > > - tunnel all traffic from the PAN back to the home network. > > This is exactly what I pointed out to Thierry a while ago. If routing is > consistent and transparent with regards to this home link, I also think > that this is the ideal solution. I am not sure. I may have missed something here. I agree with you in the simplest case where the "Mobile Network Prefix" is the same as the "home link prefix" with a longer prefix, otherwise I am kind of sceptical. > However, Mobile IPv6 fails to be fully transparent when it comes to > link-local addresses. > > Unfortunately, we couldn't make an agreement on how nodes would > function. It is obviously implementation dependent whether the home > agent will do binding cache lookup and routing table lookup in the > correct order to allow this. > > I pointed out that a BSD home agent could probably work like described > above, but Thierry shows in the draft that INRIA's MIPv6 code would not. INRIA MIPv6 is actually FreeBSD. If distinct implementations lead to distinct results, this means that the MIPv6 specification needs a word about it. It is not clear if the HA is able to tunnel packets intended to the other devices behind the mobile router. The processing of the R-bit by the HA needs clarification. > Routing protocols use link-local addresses, so this would fail (at least > with today's specification of Mobile IPv6 and routing protocols). Exact... > Maybe Mobile IPv6 should be changed to tunnel *all* packets. ... and this would introduce other issues. What I am saying here is that things get more complicated for a mobile node which is also router. There are many issues to care about, and this cannot be solved as easily as one would think. 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 Tue Aug 14 08:25:32 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29548 for ; Tue, 14 Aug 2001 08:25: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 GAA26676; Tue, 14 Aug 2001 06:26: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 FAA11298; Tue, 14 Aug 2001 05:26:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7ECPae06681 for mobile-ip-dist; Tue, 14 Aug 2001 05:25:36 -0700 (PDT) Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.179.15]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7ECPWD06674 for ; Tue, 14 Aug 2001 05:25:32 -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 f7ECPQ201532; Tue, 14 Aug 2001 14:25:26 +0200 (MET DST) Date: Tue, 14 Aug 2001 14:22:44 +0200 (CEST) From: Erik Nordmark Subject: Re: [mobile-ip] Mobile Routers support without optimization To: Alexis Olivereau Cc: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3B77E54C.689ECF35@crm.mot.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: > > Example: I run a MN and a HA . My MN sends a BU for a /3 to a CN > > the fact that my MN says "yes" when the CN asks if the binding is ok. > > First I think you mean " HA says 'yes' " (?) A part of your text seem to > have disappeared here... Yes that was what I meant to say. > In my understanding you have a malicious Mobile Router _and_ a malicious > Home Agent, the former counting on the latter to validate faked Binding > Updates. Correct. > Now when CN sends a 'question message' to MR's Home Address, malicious > HA should not discard the message but continue the process. Well... but > the question is: why would the home address be routed towards your > attacking Home Agent? Do you mean you have also managed to remotely > configure routing tables of the target Home Network? Then you are not > limited to a faked BU attack and can envision large scale DoS against > the Home Network... No - no attack is needed on the routing system. I have a home address (X/128) which is routed towards my HA. That part is legimtimate. But this doesn't mean I have authority to affect routing for e.g. the X/3 prefix. How can a CN tell whether a given HA+MR is allowed to affect routing for a given prefix? That is the core of the authorization issue. > > The redirection of a prefix must be related to the routing for that whole > > prefix going to the HA. In general you can't verify that this is the case > > for a prefix without actually sending packets to all IP addresses in the > > prefix and seeing that you get a response back from the HA. > Correct me if I am wrong: you mean that BAKE is secure in the sense that > the reachability of the MN is verfied. For a MR we should then verify > the reachability of all nodes the MR serves. I do not think it is the > only means. In the solution we propose, we use the same process to make > sure that we can reach the MR via its Home Address (so should be each > node below, provided that MR does not lie). BUT in addition to that > basic verification, HA is required to check the prefix the MR sent a BU > for (check the binding [MR H@ / Mobile prefix]). Thus we guarantee that > any node served by MR will be reachable through the new MR Care-of > Address. So how do you handle the case I'm trying to explain above? Erik From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 14 08: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 ESMTP id IAA00182 for ; Tue, 14 Aug 2001 08:35: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 FAA21880; Tue, 14 Aug 2001 05:37: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 FAA12449; Tue, 14 Aug 2001 05:36:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7ECZXR06799 for mobile-ip-dist; Tue, 14 Aug 2001 05:35:33 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7ECZUD06792 for ; Tue, 14 Aug 2001 05:35:30 -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 FAA12354 for ; Tue, 14 Aug 2001 05:35:31 -0700 (PDT) Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA01553 for ; Tue, 14 Aug 2001 06:35:27 -0600 (MDT) Received: from inrialpes.fr (galibier.inrialpes.fr [194.199.24.97]) by ebene.inrialpes.fr (8.11.3/8.11.3) with ESMTP id f7ECWLb19633 for ; Tue, 14 Aug 2001 14:32:21 +0200 (MEST) Message-ID: <3B791AEB.655F8118@inrialpes.fr> Date: Tue, 14 Aug 2001 14:34:51 +0200 From: Thierry Ernst Organization: INRIA Rhone-Alpes X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile Routers support without optimization 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 think my note had "basic" in there :-) By basic, you mean "no routing optimization". I advocate that providing routing optimization is a requirement. You also demonstrate a need to support VMNs; at the same time this also highlights an even more important need for routing optimization. > If you want something more signifant to think about then there is > the train case with different adminstrations and a different HA for > the MR (HA1) and a for a particular MN on the train (HA2). Nested mobility. > In order to illustrate the route optimization choices let's look at > a possible way to approach this problem: > > Without route optimization that case works as follows: > MR updates HA1 with its current topological location as the train > moves. What do you mean by "current topological location" ? You probably want to say "its current COA". > When MN arrives on the train it uses addrconf to get an address under MR's > prefix. Create co-located COA. It updates HA2 with this as the COA. > > CN looks up MN in DNS. Sends packet to that are intercepted by HA2. > HA2 tunnels packets towards MR thuse the packets are routed towards HA1. > HA1 in turn tunnels the packets to MR's COA. > > MR decapsulated and sends the singly-tunneled packets to MN's COA. Double dog-leg routing, and double encapsulation on the wireless link. Something we should definitely avoid. > For the forward path there are two HAs that can be optimized out. > Depending on traffic patterns and relative movement speed at the > two attachment points (MN attaching to MR, and MR attaching to some > access router along the train track) all 4 possibilities of optimization might > make sense > - optimize out both HAs > - optimize out HA2 (if MN stays on the train for a long time) > - optimize out HA1 (as long as MR doesn't get handed off too often) > - optimize out none > So just like in the simple mobile node case there are tradeoffs between > the signalling involved in doing route optimizations and savings from > more efficient routing, but in the MR case there are more variants > on what to optimize. 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 Tue Aug 14 08:46:48 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01008 for ; Tue, 14 Aug 2001 08:46: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 GAA07824; Tue, 14 Aug 2001 06:47: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 FAA13341; Tue, 14 Aug 2001 05:47:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7ECk6j06898 for mobile-ip-dist; Tue, 14 Aug 2001 05:46:06 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7ECk2D06891 for ; Tue, 14 Aug 2001 05:46:02 -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 FAA01229 for ; Tue, 14 Aug 2001 05:46:04 -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 FAA17283 for ; Tue, 14 Aug 2001 05:45:58 -0700 (PDT) Received: from inrialpes.fr (galibier.inrialpes.fr [194.199.24.97]) by ebene.inrialpes.fr (8.11.3/8.11.3) with ESMTP id f7ECgmb19831 for ; Tue, 14 Aug 2001 14:42:48 +0200 (MEST) Message-ID: <3B791D5F.18C9D39F@inrialpes.fr> Date: Tue, 14 Aug 2001 14:45:19 +0200 From: Thierry Ernst Organization: INRIA Rhone-Alpes X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile Routers support without optimization References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Erik Nordmark wrote: > > Now when CN sends a 'question message' to MR's Home Address, malicious > > HA should not discard the message but continue the process. Well... but > > the question is: why would the home address be routed towards your > > attacking Home Agent? Do you mean you have also managed to remotely > > configure routing tables of the target Home Network? Then you are not > > limited to a faked BU attack and can envision large scale DoS against > > the Home Network... > > No - no attack is needed on the routing system. > > I have a home address (X/128) which is routed towards my HA. > That part is legimtimate. > > But this doesn't mean I have authority to affect routing for e.g. > the X/3 prefix. > How can a CN tell whether a given HA+MR is allowed to affect routing > for a given prefix? That is the core of the authorization issue. A /3 is not a really a good instance of a prefix. I would rather say a /48. What we need: - first, the MR must "own" the prefix /P. This means that whatever prefix longer than P belongs to MR. - second, a means to certify that prefix /P is effectively owned by MR. > > > The redirection of a prefix must be related to the routing for that whole > > > prefix going to the HA. In general you can't verify that this is the case > > > for a prefix without actually sending packets to all IP addresses in the > > > prefix and seeing that you get a response back from the HA. > > Correct me if I am wrong: you mean that BAKE is secure in the sense that > > the reachability of the MN is verfied. For a MR we should then verify > > the reachability of all nodes the MR serves. I do not think it is the > > only means. In the solution we propose, we use the same process to make > > sure that we can reach the MR via its Home Address (so should be each > > node below, provided that MR does not lie). BUT in addition to that > > basic verification, HA is required to check the prefix the MR sent a BU > > for (check the binding [MR H@ / Mobile prefix]). Thus we guarantee that > > any node served by MR will be reachable through the new MR Care-of > > Address. > > So how do you handle the case I'm trying to explain above? draft-ernst-mobileip-v6-network-02.txt section 5. 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 Tue Aug 14 08:52:11 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01425 for ; Tue, 14 Aug 2001 08:52:10 -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 GAA11131; Tue, 14 Aug 2001 06:53: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 FAA01841; Tue, 14 Aug 2001 05:52:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7ECqAo07002 for mobile-ip-dist; Tue, 14 Aug 2001 05:52:10 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7ECq6D06995 for ; Tue, 14 Aug 2001 05:52: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 FAA13784 for ; Tue, 14 Aug 2001 05:52:08 -0700 (PDT) Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA10500 for ; Tue, 14 Aug 2001 06:52:04 -0600 (MDT) Received: from inrialpes.fr (galibier.inrialpes.fr [194.199.24.97]) by ebene.inrialpes.fr (8.11.3/8.11.3) with ESMTP id f7ECmwb19887 for ; Tue, 14 Aug 2001 14:48:58 +0200 (MEST) Message-ID: <3B791ED0.1E29C273@inrialpes.fr> Date: Tue, 14 Aug 2001 14:51:28 +0200 From: Thierry Ernst Organization: INRIA Rhone-Alpes X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile Routers support without optimization References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Erik Nordmark wrote: > But, what problem are we really trying to solve by being able to send > a BU for a whole prefix? Routing optimization. > This seems like optimizing something which is close to a non-problem. -- * 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 Tue Aug 14 08: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 ESMTP id IAA01767 for ; Tue, 14 Aug 2001 08:56:34 -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 GAA14023; Tue, 14 Aug 2001 06:57: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 FAA02310; Tue, 14 Aug 2001 05:57:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7ECuJ507079 for mobile-ip-dist; Tue, 14 Aug 2001 05:56:19 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7ECuGD07072 for ; Tue, 14 Aug 2001 05:56: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 FAA19503 for ; Tue, 14 Aug 2001 05:56:17 -0700 (PDT) Received: from idcpa4.pa.interdigital.com ([12.32.197.142]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA18260 for ; Tue, 14 Aug 2001 06:56:28 -0600 (MDT) Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19) id ; Tue, 14 Aug 2001 08:55:03 -0400 Message-ID: From: "Shaheen, Kamel M." To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Heterogeneous Handover - where do i look Date: Tue, 14 Aug 2001 08:55:03 -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: GPRS standards (i.e., 23.060) do not specify MIP for inter-GGSN handover. -----Original Message----- From: James Kempf [mailto:James.Kempf@Sun.COM] Sent: Monday, August 13, 2001 3:52 PM To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Heterogeneous Handover - where do i look Doradla, My understanding is that although the GPRS standard specifies MIP for inter-GGSN handover, there has been very little effort to clarify exactly how this would work and how it would interact with GTP-based mobility, primarily, I'm told, due to lack of operator interest. I do not know if manufacturers are even building MIP into their terminals. So, prior to figuring out at the IP level how heterogeneous handover would work, there is a need to figure out in GPRS how MIP and GPRS will work together. jak >From: "Doradla, Anil" >To: "'mobile-ip@sunroof.eng.sun.com'" >Subject: [mobile-ip] Heterogeneous Handover - where do i look >Date: Fri, 10 Aug 2001 11:28:03 -0500 >All: > >Coming back to the question of handover across heterogeneous wireless >networks. Can anyone advise me as to where i should look at? >We are seeing a desire for handover between 802.11 and GPRS networks. Is >there any group looking at the feasibility of this ? > >Thanks in advance > >Anil Doradla >SBC- Technology Resources, Inc. >Austin, TX-78727 > > >-----Original Message----- >From: James Kempf [mailto:James.Kempf@sun.com] >Sent: Friday, August 10, 2001 3:57 AM >To: mobile-ip@sunroof.eng.sun.com; mobile-ip@sunroof.eng.sun.com >Cc: Peter.Dahl >Subject: RE: [mobile-ip] Heterogeneous Handover - How Would it Work? > > >Glenn, > >I think Raj is right on here, sorry. There are enough technical issues >involved in getting MIP to be deployable that the MIP group really >needs to focus on. An example is this NAT question. > >If there are any operational issues involved in handover between operators >that >need resolution, they should probably be handled in a separate working >group, like ROAMOPS. An example of such an issue might be advertising >access routers between operators using something like the Seamoby >CAR discovery protocol, which is just now getting off the ground. > > jak >>Raj, >> >>That's like saying that BGP doesn't deal with the routing policy related to >>business relationships between the owners of autonomous systems. You are >>shoe-holing the group into only dealing with an enterprise - not the >>Internet. >> >>-----Original Message----- >>From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com] >>Sent: Thursday, August 09, 2001 10:55 AM >>To: mobile-ip >>Cc: Peter.Dahl >>Subject: RE: [mobile-ip] Heterogeneous Handover - How Would it Work? >> >> >>Clearly, you are mixing roaming with seamless mobility across >>heterogeneous >>access types. The Mobile IP WG does not deal with aspects related to >>roaming >>agreements between operators or administrative domains. That is NOT what >>this WG is about. >> >>-Basavaraj >> >>> -----Original Message----- >>> From: ext Dahl, Peter [mailto:Peter.Dahl@VerizonWireless.com] >>> Sent: Wednesday, August 08, 2001 1:53 PM >>> To: 'mobile-ip@sunroof.eng.sun.com' >>> Subject: RE: [mobile-ip] Heterogeneous Handover - How Would it Work? >>> >>> >>> ...not forgetting cdma2000. I am not aware of any work in >>> 3GPP2 or IEEE, >>> perhaps 3GPP ? >>> >>> Pete >>> >>> -----Original Message----- >>> From: Brad Casemore [mailto:bcasemore@home.com] >>> Sent: Wednesday, August 08, 2001 11:29 AM >>> To: mobile-ip@sunroof.eng.sun.com >>> Subject: RE: [mobile-ip] Heterogeneous Handover - How Would it Work? >>> >>> >>> If that is the case, then WECA's WISPr is dedicated to >>> 802.11b roaming, >>> while the ETSI has assigned a group to address GPRS roaming. >>> Is there a >>> group anywhere that is looking into the technical issues >>> associated with >>> heterogeneous network roaming (such as between, theoretically, 802.11b >>> WLANs and GPRS)? >>> >>> Brad >>> >>> > -----Original Message----- >>> > From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile- >>> > ip@sunroof.eng.sun.com] On Behalf Of James Kempf >>> > Sent: Wednesday, August 08, 2001 2:19 AM >>> > To: mobile-ip@sunroof.eng.sun.com; mobile-ip@sunroof.eng.sun.com >>> > Subject: Re: [mobile-ip] Heterogeneous Handover - How Would it Work? >>> > >>> > Pat, >>> > >>> > I think they already have such a standard and I believe it >>> only works >>> > with GPRS. >>> > >>> > jak >>> > >>> > >Also, I believe that ETSI is working on a standard called GRX for >>> GSM<- >>> > >802.11 >>> > >roaming. >>> > > >>> > >PatC >>> > >On Tue, Aug 07, 2001 at 09:32:58AM -0700, Dahl, Peter wrote: >>> > >> FYI, the Wireless ISPs (WISPs) are already talking about such >>> roaming >>> > >> issues. >>> > >> >>> > >> There appear to be 2 emerging forums for these discussions, one >>> under >>> > the >>> > >> auspices of WECA (http://www.weca.net) known as the WISPr group >>> ('r' >>> > being >>> > >> for roaming), the other a yet to be finalized 'WISP Forum' the >>> prime >>> > mover >>> > >> for which is a company in Luxembourg (www.excilan.com). >>> > >> >>> > >> Regards >>> > >> >>> > >> -----Original Message----- >>> > >> From: James Kempf [mailto:James.Kempf@Sun.COM] >>> > >> Sent: Tuesday, August 07, 2001 8:58 AM >>> > >> To: mobile-ip@sunroof.eng.sun.com; mobile-ip@sunroof.eng.sun.com >>> > >> Subject: Re: [mobile-ip] Heterogeneous Handover - How Would it >>> Work? >>> > >> >>> > >> >>> > >> >On the other hand, the home address must belong to some >>> ISP/operator. >>> > >> >That ISP must provide a home agent and an ip address, and a CoA >>> when >>> > the >>> > >> >MN is connected to other than the home subnet. Other >>> ISPs that are >>> > used >>> > >> >are only access providers, and would give the MN its >>> CoA. This of >>> > course >>> > >> >would cause political problems. Who are the ISPs that >>> are willing >>> to >>> > be >>> > >> >access providers only, and who will be providing home agent and >>> home >>> > >> >address as well? >>> > >> > >>> > >> >>> > >> This is an issue. What happens if you have one access provider on >>> > >> one interface, say the wCDMA interface, and another on >>> another, say >>> > 802.11? >>> > >> There are now in the US a growing number of 802.11 access >>> providers, >>> > >> and I can imagine someone with a laptop having a wCDMA modem and >>> > >> an 802.11 card. >>> > >> >>> > >> Maybe something like the "roaming consortia" that have sprung up >>> > >> around ISP access might evolve, but the protocol >>> design/engineering >>> > >> issue is whether there is any additional work (such as the NAI in >>> > >> the roaming consortia example) needed to enable sharing of a home >>> > >> address among interfaces for which different ISPs are >>> responsible. >>> > >> >>> > >> Something like SUCV, that would allow an ISP to cryptographically >>> > identify >>> > >> to what other ISP an address belonged, might be useful in this >>> context. >>> > >> >>> > >> jak >>> > From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 14 09:16:45 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03108 for ; Tue, 14 Aug 2001 09:16: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 GAA05348; Tue, 14 Aug 2001 06:17: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 GAA04386; Tue, 14 Aug 2001 06:16:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7EDEna07262 for mobile-ip-dist; Tue, 14 Aug 2001 06:14:49 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7EDEjD07255 for ; Tue, 14 Aug 2001 06:14: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 GAA17775 for ; Tue, 14 Aug 2001 06:14:47 -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 HAA27980 for ; Tue, 14 Aug 2001 07:14:56 -0600 (MDT) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f7EDEgN20983 for ; Tue, 14 Aug 2001 15:14:42 +0200 (MEST) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id PAA21107; Tue, 14 Aug 2001 15:14:42 +0200 Message-ID: <3B7923D6.B231F8D3@era.ericsson.se> Date: Tue, 14 Aug 2001 15:12:54 +0200 From: Mattias Pettersson Organization: Ericsson Research X-Mailer: Mozilla 4.77 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile Routers support without optimization 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 Alexandru Petrescu wrote: > > Erik Nordmark writes: > > When I'm at home the PAN router has adjancencies with other routers attached > > to the home link which it uses to exchange routing information about the > > subnet prefixes assigned to my PAN. > > > > When I move away from home it is sufficient for the PAN router to > > - send a binding update for its own address (which the other routers > > have as the nexthop in the routing tables). This BU will > > have the R-bit set so that NUD works. > > - tunnel all traffic from the PAN back to the home network. > > There's at least one thing that won't work in this scenario: when HA > defends MR's Home Address it has an entry in the Binding Cache > containing MR's CoA and MR's Home Address, but not the MNN's Home > Address. Thus it can't relate an incoming packet for that MNN to that > MNN's Home Address. Unless more clarification is added to how the > Binding Cache is searched. > We had a discussion on this earlier this year. Anyway, the I-Ds are not explicit about packet handling, mostly because it is up to the implementor. This is also a source of misunderstanding. I proposed (and Erik means the same, I think) to do a mapping between the MR's home address and its CoA in the HA. A binding for the mobile prefix (that MNNs belong to) is not needed, since the HA _should already have_ one in its routing table. This entry is created from routing protocols between the MR and the home link routers, including the HA. That entry simply tells the HA to route traffic to the mobile prefix to the gateway address of the MR. [Ok, this introduces another problem. The gateway address should be a link-local address, since routing protocols use that. Mobile IPv6 does not suggest forwarding of packets destined to a link-local addresses, but the destination in the packets are e.g. global, since its the MNN. However, the HA will first have to do a lookup on the destination address (MNN), and it will see that it should use MR's link-local address. Next, it should consult its Binding Cache to find that this packet should be forwarded to the MR's CoA by using a tunnel. The special order in which routing table and binding cache lookups needs to be done is far from common practice, and I don't think this will work smoothly with all implementations out there.] /Mattias From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 14 09:38:28 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04214 for ; Tue, 14 Aug 2001 09:38: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 HAA10052; Tue, 14 Aug 2001 07:39: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 GAA06690; Tue, 14 Aug 2001 06:39:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7EDc4Q07427 for mobile-ip-dist; Tue, 14 Aug 2001 06:38:04 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7EDc1D07420 for ; Tue, 14 Aug 2001 06:38:01 -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 GAA20044 for ; Tue, 14 Aug 2001 06:38: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 GAA12513 for ; Tue, 14 Aug 2001 06:38:01 -0700 (PDT) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f7EDc0N07020 for ; Tue, 14 Aug 2001 15:38:00 +0200 (MEST) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id PAA21762; Tue, 14 Aug 2001 15:37:59 +0200 Message-ID: <3B79294B.EE96B225@era.ericsson.se> Date: Tue, 14 Aug 2001 15:36:11 +0200 From: Mattias Pettersson Organization: Ericsson Research X-Mailer: Mozilla 4.77 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile Routers support without optimization References: <3B77E391.1E9A5D34@era.ericsson.se> <3B791712.402C5195@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 Thierry Ernst wrote: > > Mattias Pettersson wrote: > > > When I move away from home it is sufficient for the PAN router to > > > - send a binding update for its own address (which the other routers > > > have as the nexthop in the routing tables). This BU will > > > have the R-bit set so that NUD works. > > > - tunnel all traffic from the PAN back to the home network. > > > > This is exactly what I pointed out to Thierry a while ago. If routing is > > consistent and transparent with regards to this home link, I also think > > that this is the ideal solution. > > I am not sure. I may have missed something here. I agree with you in > the simplest case where the "Mobile Network Prefix" is the same as the > "home link prefix" with a longer prefix, otherwise I am kind of > sceptical. But the Mobile Network Prefix can't be a subset of the home link prefix. They should be parallel and both have /64. Or am I wrong? Don't you want ordinary hosts on the home link as well? > > > However, Mobile IPv6 fails to be fully transparent when it comes to > > link-local addresses. > > > > Unfortunately, we couldn't make an agreement on how nodes would > > function. It is obviously implementation dependent whether the home > > agent will do binding cache lookup and routing table lookup in the > > correct order to allow this. > > > > I pointed out that a BSD home agent could probably work like described > > above, but Thierry shows in the draft that INRIA's MIPv6 code would not. > > INRIA MIPv6 is actually FreeBSD. I know. My feeling with the example in your draft is to support your prefix BU. Perhaps INRIA's implementation could be made to work like I described, without use of of prefix BU. Not without modification, but anyway. > If distinct implementations lead to distinct results, this means that > the MIPv6 specification needs a word about it. It is not clear if the > HA is able to tunnel packets intended to the other devices behind the > mobile router. The processing of the R-bit by the HA needs > clarification. Good point. > What I am saying here is that things get more complicated for a mobile > node which is also router. There are many issues to care about, and > this cannot be solved as easily as one would think. > I agree. This is not so easy at all. Mobile IP as a general vision could probably seem to work fine for both hosts and routers. But with all work currently done with MIPv6, ND and so on is to support mobile hosts only. In the detailed design work, only hosts have been considered. Nobody really thought on the routers, until now. /Mattias From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 14 09:50:49 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04823 for ; Tue, 14 Aug 2001 09:50: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 GAA17889; Tue, 14 Aug 2001 06:51: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 GAA19685; Tue, 14 Aug 2001 06:51:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7EDoG207590 for mobile-ip-dist; Tue, 14 Aug 2001 06:50:16 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7EDoDD07583 for ; Tue, 14 Aug 2001 06:50:13 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA19557 for ; Tue, 14 Aug 2001 06:50:15 -0700 (PDT) Received: from howler.tri.sbc.com (howler.tri.sbc.com [205.173.58.4]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA17054 for ; Tue, 14 Aug 2001 07:50:05 -0600 (MDT) Received: from sbctri.tri.sbc.com (sbctri [144.60.1.10]) by howler.tri.sbc.com (8.11.0/8.11.0) with ESMTP id f7EDokj16972 for ; Tue, 14 Aug 2001 08:50:46 -0500 (CDT) Received: from trimail2.tri.sbc.com (localhost [127.0.0.1]) by sbctri.tri.sbc.com (8.11.0/8.9.3) with ESMTP id f7EDnr621091 for ; Tue, 14 Aug 2001 08:49:53 -0500 (CDT) Received: by trimail2.tri.sbc.com with Internet Mail Service (5.5.2653.19) id ; Tue, 14 Aug 2001 08:50:00 -0500 Message-ID: <4D45BA2A58A7D3119E050008C7E69E29F79481@trimail2.tri.sbc.com> From: "Doradla, Anil" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Heterogeneous Handover - where do i look Date: Tue, 14 Aug 2001 08:49: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: Thanks for replying to my enquiry. I have looked at the 3GPP documents. MIP has been incorporated as an option for mobility management (i think it is document 3GPP TS 29.023??). Basically, there were three options laied out. They are: 1. Incorporating MIP totally in a 3GPP core 2. Incorporate MIP and GTP together 3. Make enhancements to GTP for mobility management. You do bring up a good point that we need to understand how vendors are implementing MIP in GPRS networks. My 2 cents is that present GPRS networks that are being deployed across the world do not incorporate MIP. As far as handsets are concered, we have not looked at them closely. BTW, do you have any references that you can lead me on to ?? Thanaks a lot Anil ---------------------------------------------------------------------------- ------------ Wireless Communications Division SBC Technology Resources, Inc. 9505 Arboretum Blvd Austin, TX-78759 (512) 372-5805 FAX: (512) 372-5891 This e-mail and any files transmitted with it are the property of SBC, are confidential, and are intended solely for the use of the individual or entity to whom this e-mail is addressed. If you are not one of the named recipient(s) or otherwise have reason to believe that you have received this message in error, please notify the sender at 512 372-5805 and delete this message immediately from your computer. Any other use, retention, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. -----Original Message----- From: Shaheen, Kamel M. [mailto:Kamel.Shaheen@interdigital.com] Sent: Tuesday, August 14, 2001 7:55 AM To: 'mobile-ip@sunroof.eng.sun.com' Subject: RE: [mobile-ip] Heterogeneous Handover - where do i look GPRS standards (i.e., 23.060) do not specify MIP for inter-GGSN handover. -----Original Message----- From: James Kempf [mailto:James.Kempf@Sun.COM] Sent: Monday, August 13, 2001 3:52 PM To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Heterogeneous Handover - where do i look Doradla, My understanding is that although the GPRS standard specifies MIP for inter-GGSN handover, there has been very little effort to clarify exactly how this would work and how it would interact with GTP-based mobility, primarily, I'm told, due to lack of operator interest. I do not know if manufacturers are even building MIP into their terminals. So, prior to figuring out at the IP level how heterogeneous handover would work, there is a need to figure out in GPRS how MIP and GPRS will work together. jak >From: "Doradla, Anil" >To: "'mobile-ip@sunroof.eng.sun.com'" >Subject: [mobile-ip] Heterogeneous Handover - where do i look >Date: Fri, 10 Aug 2001 11:28:03 -0500 >All: > >Coming back to the question of handover across heterogeneous wireless >networks. Can anyone advise me as to where i should look at? >We are seeing a desire for handover between 802.11 and GPRS networks. Is >there any group looking at the feasibility of this ? > >Thanks in advance > >Anil Doradla >SBC- Technology Resources, Inc. >Austin, TX-78727 > > >-----Original Message----- >From: James Kempf [mailto:James.Kempf@sun.com] >Sent: Friday, August 10, 2001 3:57 AM >To: mobile-ip@sunroof.eng.sun.com; mobile-ip@sunroof.eng.sun.com >Cc: Peter.Dahl >Subject: RE: [mobile-ip] Heterogeneous Handover - How Would it Work? > > >Glenn, > >I think Raj is right on here, sorry. There are enough technical issues >involved in getting MIP to be deployable that the MIP group really >needs to focus on. An example is this NAT question. > >If there are any operational issues involved in handover between operators >that >need resolution, they should probably be handled in a separate working >group, like ROAMOPS. An example of such an issue might be advertising >access routers between operators using something like the Seamoby >CAR discovery protocol, which is just now getting off the ground. > > jak >>Raj, >> >>That's like saying that BGP doesn't deal with the routing policy related to >>business relationships between the owners of autonomous systems. You are >>shoe-holing the group into only dealing with an enterprise - not the >>Internet. >> >>-----Original Message----- >>From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com] >>Sent: Thursday, August 09, 2001 10:55 AM >>To: mobile-ip >>Cc: Peter.Dahl >>Subject: RE: [mobile-ip] Heterogeneous Handover - How Would it Work? >> >> >>Clearly, you are mixing roaming with seamless mobility across >>heterogeneous >>access types. The Mobile IP WG does not deal with aspects related to >>roaming >>agreements between operators or administrative domains. That is NOT what >>this WG is about. >> >>-Basavaraj >> >>> -----Original Message----- >>> From: ext Dahl, Peter [mailto:Peter.Dahl@VerizonWireless.com] >>> Sent: Wednesday, August 08, 2001 1:53 PM >>> To: 'mobile-ip@sunroof.eng.sun.com' >>> Subject: RE: [mobile-ip] Heterogeneous Handover - How Would it Work? >>> >>> >>> ...not forgetting cdma2000. I am not aware of any work in >>> 3GPP2 or IEEE, >>> perhaps 3GPP ? >>> >>> Pete >>> >>> -----Original Message----- >>> From: Brad Casemore [mailto:bcasemore@home.com] >>> Sent: Wednesday, August 08, 2001 11:29 AM >>> To: mobile-ip@sunroof.eng.sun.com >>> Subject: RE: [mobile-ip] Heterogeneous Handover - How Would it Work? >>> >>> >>> If that is the case, then WECA's WISPr is dedicated to >>> 802.11b roaming, >>> while the ETSI has assigned a group to address GPRS roaming. >>> Is there a >>> group anywhere that is looking into the technical issues >>> associated with >>> heterogeneous network roaming (such as between, theoretically, 802.11b >>> WLANs and GPRS)? >>> >>> Brad >>> >>> > -----Original Message----- >>> > From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile- >>> > ip@sunroof.eng.sun.com] On Behalf Of James Kempf >>> > Sent: Wednesday, August 08, 2001 2:19 AM >>> > To: mobile-ip@sunroof.eng.sun.com; mobile-ip@sunroof.eng.sun.com >>> > Subject: Re: [mobile-ip] Heterogeneous Handover - How Would it Work? >>> > >>> > Pat, >>> > >>> > I think they already have such a standard and I believe it >>> only works >>> > with GPRS. >>> > >>> > jak >>> > >>> > >Also, I believe that ETSI is working on a standard called GRX for >>> GSM<- >>> > >802.11 >>> > >roaming. >>> > > >>> > >PatC >>> > >On Tue, Aug 07, 2001 at 09:32:58AM -0700, Dahl, Peter wrote: >>> > >> FYI, the Wireless ISPs (WISPs) are already talking about such >>> roaming >>> > >> issues. >>> > >> >>> > >> There appear to be 2 emerging forums for these discussions, one >>> under >>> > the >>> > >> auspices of WECA (http://www.weca.net) known as the WISPr group >>> ('r' >>> > being >>> > >> for roaming), the other a yet to be finalized 'WISP Forum' the >>> prime >>> > mover >>> > >> for which is a company in Luxembourg (www.excilan.com). >>> > >> >>> > >> Regards >>> > >> >>> > >> -----Original Message----- >>> > >> From: James Kempf [mailto:James.Kempf@Sun.COM] >>> > >> Sent: Tuesday, August 07, 2001 8:58 AM >>> > >> To: mobile-ip@sunroof.eng.sun.com; mobile-ip@sunroof.eng.sun.com >>> > >> Subject: Re: [mobile-ip] Heterogeneous Handover - How Would it >>> Work? >>> > >> >>> > >> >>> > >> >On the other hand, the home address must belong to some >>> ISP/operator. >>> > >> >That ISP must provide a home agent and an ip address, and a CoA >>> when >>> > the >>> > >> >MN is connected to other than the home subnet. Other >>> ISPs that are >>> > used >>> > >> >are only access providers, and would give the MN its >>> CoA. This of >>> > course >>> > >> >would cause political problems. Who are the ISPs that >>> are willing >>> to >>> > be >>> > >> >access providers only, and who will be providing home agent and >>> home >>> > >> >address as well? >>> > >> > >>> > >> >>> > >> This is an issue. What happens if you have one access provider on >>> > >> one interface, say the wCDMA interface, and another on >>> another, say >>> > 802.11? >>> > >> There are now in the US a growing number of 802.11 access >>> providers, >>> > >> and I can imagine someone with a laptop having a wCDMA modem and >>> > >> an 802.11 card. >>> > >> >>> > >> Maybe something like the "roaming consortia" that have sprung up >>> > >> around ISP access might evolve, but the protocol >>> design/engineering >>> > >> issue is whether there is any additional work (such as the NAI in >>> > >> the roaming consortia example) needed to enable sharing of a home >>> > >> address among interfaces for which different ISPs are >>> responsible. >>> > >> >>> > >> Something like SUCV, that would allow an ISP to cryptographically >>> > identify >>> > >> to what other ISP an address belonged, might be useful in this >>> context. >>> > >> >>> > >> jak >>> > From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 14 10:06:33 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05297 for ; Tue, 14 Aug 2001 10:06: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 IAA00322; Tue, 14 Aug 2001 08:07: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 HAA21417; Tue, 14 Aug 2001 07:07:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7EE5Xw07699 for mobile-ip-dist; Tue, 14 Aug 2001 07:05:33 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7EE5TD07692 for ; Tue, 14 Aug 2001 07:05:29 -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 HAA21211 for ; Tue, 14 Aug 2001 07:05:32 -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 HAA00276 for ; Tue, 14 Aug 2001 07:05:31 -0700 (PDT) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate.mot.com (motgate 2.1) with ESMTP id HAA05419 for ; Tue, 14 Aug 2001 07:05:30 -0700 (MST)] Received: [from test9.crm.mot.com (zfr24-sr2-04.corp.mot.com [140.101.145.4]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id GAA29159 for ; Tue, 14 Aug 2001 06:57:37 -0700 (MST)] Received: from test9.crm.mot.com.crm.mot.com (localhost [127.0.0.1]) by test9.crm.mot.com (8.9.3/8.9.3) with ESMTP id QAA01195 for ; Tue, 14 Aug 2001 16:04:34 +0200 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile Routers support without optimization References: <3B7923D6.B231F8D3@era.ericsson.se> From: Alexandru Petrescu Date: 14 Aug 2001 15:57:41 +0200 In-Reply-To: <3B7923D6.B231F8D3@era.ericsson.se> 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: 46 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Mattias Pettersson writes: > I proposed (and Erik means the same, I think) to do a mapping between > the MR's home address and its CoA in the HA. A binding for the mobile > prefix (that MNNs belong to) is not needed, since the HA _should already > have_ one in its routing table. This entry is created from routing > protocols between the MR and the home link routers, including the HA. > That entry simply tells the HA to route traffic to the mobile prefix to > the gateway address of the MR. Is HA necessarily located in the BR (Thierry's border router)? Is HA necessarily running a routing protocol? Is HA necessarily participating in route exchanges if it's not a router? I need to understand this. > [Ok, this introduces another problem. The gateway address should be a > link-local address, since routing protocols use that. Mobile IPv6 does > not suggest forwarding of packets destined to a link-local > addresses... I agree with the link-local reasoning. In fact I also pointed it to Thierry late last year. Hopefully it will make it into future versions of the draft. > However, the HA will first have to do a lookup on the destination > address (MNN), and it will see that it should use MR's link-local > address. This works fine if HA has a route to MR's subnet. > Next, it should consult its Binding Cache to find that this packet > should be forwarded to the MR's CoA by using a tunnel. The special > order in which routing table and binding cache lookups needs to be > done is far from common practice, and I don't think this will work > smoothly with all implementations out there.] An alternative to coupled binding cache/route table lookups would be to extend the binding cache entry with a third address: the network prefix behind the respective home address. This way the HA is not required to participate in route maintenance (route maintenance is done not only for subnets behind MR's but also all other fixed routers on same home link). This alternative is different from Thierry's draft as well as from the short lived -14. Alex From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 14 10:08:24 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05348 for ; Tue, 14 Aug 2001 10:08: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 HAA25916; Tue, 14 Aug 2001 07:09:22 -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 HAA21815; Tue, 14 Aug 2001 07:09:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7EE8Co07741 for mobile-ip-dist; Tue, 14 Aug 2001 07:08:12 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7EE89D07734 for ; Tue, 14 Aug 2001 07:08:09 -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 HAA21573 for ; Tue, 14 Aug 2001 07:08:10 -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 HAA29163 for ; Tue, 14 Aug 2001 07:08:09 -0700 (PDT) Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19) id ; Tue, 14 Aug 2001 10:06:56 -0400 Message-ID: From: "Shaheen, Kamel M." To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Heterogeneous Handover - where do i look Date: Tue, 14 Aug 2001 10:06: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: I searched for 29.023 but did not find a document under this number in R99, R4, nor R5. Would you kindly refer me to where this document can be found. The working document for GPRS is 23.060. It has all related procedures including mobility management. One thing I am sure is not there is Inter-GGSN handoff (Hand-over) procedures. Further, If my memory serves me well, I recall reading that this issue is out of the scope of this document. If this issue is to come up, I believe 3GPP SA2 will be the place to raise this issue. Regards, Kamel -----Original Message----- From: Doradla, Anil [mailto:doradla@tri.sbc.com] Sent: Tuesday, August 14, 2001 9:50 AM To: 'mobile-ip@sunroof.eng.sun.com' Subject: RE: [mobile-ip] Heterogeneous Handover - where do i look Thanks for replying to my enquiry. I have looked at the 3GPP documents. MIP has been incorporated as an option for mobility management (i think it is document 3GPP TS 29.023??). Basically, there were three options laied out. They are: 1. Incorporating MIP totally in a 3GPP core 2. Incorporate MIP and GTP together 3. Make enhancements to GTP for mobility management. You do bring up a good point that we need to understand how vendors are implementing MIP in GPRS networks. My 2 cents is that present GPRS networks that are being deployed across the world do not incorporate MIP. As far as handsets are concered, we have not looked at them closely. BTW, do you have any references that you can lead me on to ?? Thanaks a lot Anil ---------------------------------------------------------------------------- ------------ Wireless Communications Division SBC Technology Resources, Inc. 9505 Arboretum Blvd Austin, TX-78759 (512) 372-5805 FAX: (512) 372-5891 This e-mail and any files transmitted with it are the property of SBC, are confidential, and are intended solely for the use of the individual or entity to whom this e-mail is addressed. If you are not one of the named recipient(s) or otherwise have reason to believe that you have received this message in error, please notify the sender at 512 372-5805 and delete this message immediately from your computer. Any other use, retention, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. -----Original Message----- From: Shaheen, Kamel M. [mailto:Kamel.Shaheen@interdigital.com] Sent: Tuesday, August 14, 2001 7:55 AM To: 'mobile-ip@sunroof.eng.sun.com' Subject: RE: [mobile-ip] Heterogeneous Handover - where do i look GPRS standards (i.e., 23.060) do not specify MIP for inter-GGSN handover. -----Original Message----- From: James Kempf [mailto:James.Kempf@Sun.COM] Sent: Monday, August 13, 2001 3:52 PM To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Heterogeneous Handover - where do i look Doradla, My understanding is that although the GPRS standard specifies MIP for inter-GGSN handover, there has been very little effort to clarify exactly how this would work and how it would interact with GTP-based mobility, primarily, I'm told, due to lack of operator interest. I do not know if manufacturers are even building MIP into their terminals. So, prior to figuring out at the IP level how heterogeneous handover would work, there is a need to figure out in GPRS how MIP and GPRS will work together. jak >From: "Doradla, Anil" >To: "'mobile-ip@sunroof.eng.sun.com'" >Subject: [mobile-ip] Heterogeneous Handover - where do i look >Date: Fri, 10 Aug 2001 11:28:03 -0500 >All: > >Coming back to the question of handover across heterogeneous wireless >networks. Can anyone advise me as to where i should look at? >We are seeing a desire for handover between 802.11 and GPRS networks. Is >there any group looking at the feasibility of this ? > >Thanks in advance > >Anil Doradla >SBC- Technology Resources, Inc. >Austin, TX-78727 > > >-----Original Message----- >From: James Kempf [mailto:James.Kempf@sun.com] >Sent: Friday, August 10, 2001 3:57 AM >To: mobile-ip@sunroof.eng.sun.com; mobile-ip@sunroof.eng.sun.com >Cc: Peter.Dahl >Subject: RE: [mobile-ip] Heterogeneous Handover - How Would it Work? > > >Glenn, > >I think Raj is right on here, sorry. There are enough technical issues >involved in getting MIP to be deployable that the MIP group really >needs to focus on. An example is this NAT question. > >If there are any operational issues involved in handover between operators >that >need resolution, they should probably be handled in a separate working >group, like ROAMOPS. An example of such an issue might be advertising >access routers between operators using something like the Seamoby >CAR discovery protocol, which is just now getting off the ground. > > jak >>Raj, >> >>That's like saying that BGP doesn't deal with the routing policy related to >>business relationships between the owners of autonomous systems. You are >>shoe-holing the group into only dealing with an enterprise - not the >>Internet. >> >>-----Original Message----- >>From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com] >>Sent: Thursday, August 09, 2001 10:55 AM >>To: mobile-ip >>Cc: Peter.Dahl >>Subject: RE: [mobile-ip] Heterogeneous Handover - How Would it Work? >> >> >>Clearly, you are mixing roaming with seamless mobility across >>heterogeneous >>access types. The Mobile IP WG does not deal with aspects related to >>roaming >>agreements between operators or administrative domains. That is NOT what >>this WG is about. >> >>-Basavaraj >> >>> -----Original Message----- >>> From: ext Dahl, Peter [mailto:Peter.Dahl@VerizonWireless.com] >>> Sent: Wednesday, August 08, 2001 1:53 PM >>> To: 'mobile-ip@sunroof.eng.sun.com' >>> Subject: RE: [mobile-ip] Heterogeneous Handover - How Would it Work? >>> >>> >>> ...not forgetting cdma2000. I am not aware of any work in >>> 3GPP2 or IEEE, >>> perhaps 3GPP ? >>> >>> Pete >>> >>> -----Original Message----- >>> From: Brad Casemore [mailto:bcasemore@home.com] >>> Sent: Wednesday, August 08, 2001 11:29 AM >>> To: mobile-ip@sunroof.eng.sun.com >>> Subject: RE: [mobile-ip] Heterogeneous Handover - How Would it Work? >>> >>> >>> If that is the case, then WECA's WISPr is dedicated to >>> 802.11b roaming, >>> while the ETSI has assigned a group to address GPRS roaming. >>> Is there a >>> group anywhere that is looking into the technical issues >>> associated with >>> heterogeneous network roaming (such as between, theoretically, 802.11b >>> WLANs and GPRS)? >>> >>> Brad >>> >>> > -----Original Message----- >>> > From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile- >>> > ip@sunroof.eng.sun.com] On Behalf Of James Kempf >>> > Sent: Wednesday, August 08, 2001 2:19 AM >>> > To: mobile-ip@sunroof.eng.sun.com; mobile-ip@sunroof.eng.sun.com >>> > Subject: Re: [mobile-ip] Heterogeneous Handover - How Would it Work? >>> > >>> > Pat, >>> > >>> > I think they already have such a standard and I believe it >>> only works >>> > with GPRS. >>> > >>> > jak >>> > >>> > >Also, I believe that ETSI is working on a standard called GRX for >>> GSM<- >>> > >802.11 >>> > >roaming. >>> > > >>> > >PatC >>> > >On Tue, Aug 07, 2001 at 09:32:58AM -0700, Dahl, Peter wrote: >>> > >> FYI, the Wireless ISPs (WISPs) are already talking about such >>> roaming >>> > >> issues. >>> > >> >>> > >> There appear to be 2 emerging forums for these discussions, one >>> under >>> > the >>> > >> auspices of WECA (http://www.weca.net) known as the WISPr group >>> ('r' >>> > being >>> > >> for roaming), the other a yet to be finalized 'WISP Forum' the >>> prime >>> > mover >>> > >> for which is a company in Luxembourg (www.excilan.com). >>> > >> >>> > >> Regards >>> > >> >>> > >> -----Original Message----- >>> > >> From: James Kempf [mailto:James.Kempf@Sun.COM] >>> > >> Sent: Tuesday, August 07, 2001 8:58 AM >>> > >> To: mobile-ip@sunroof.eng.sun.com; mobile-ip@sunroof.eng.sun.com >>> > >> Subject: Re: [mobile-ip] Heterogeneous Handover - How Would it >>> Work? >>> > >> >>> > >> >>> > >> >On the other hand, the home address must belong to some >>> ISP/operator. >>> > >> >That ISP must provide a home agent and an ip address, and a CoA >>> when >>> > the >>> > >> >MN is connected to other than the home subnet. Other >>> ISPs that are >>> > used >>> > >> >are only access providers, and would give the MN its >>> CoA. This of >>> > course >>> > >> >would cause political problems. Who are the ISPs that >>> are willing >>> to >>> > be >>> > >> >access providers only, and who will be providing home agent and >>> home >>> > >> >address as well? >>> > >> > >>> > >> >>> > >> This is an issue. What happens if you have one access provider on >>> > >> one interface, say the wCDMA interface, and another on >>> another, say >>> > 802.11? >>> > >> There are now in the US a growing number of 802.11 access >>> providers, >>> > >> and I can imagine someone with a laptop having a wCDMA modem and >>> > >> an 802.11 card. >>> > >> >>> > >> Maybe something like the "roaming consortia" that have sprung up >>> > >> around ISP access might evolve, but the protocol >>> design/engineering >>> > >> issue is whether there is any additional work (such as the NAI in >>> > >> the roaming consortia example) needed to enable sharing of a home >>> > >> address among interfaces for which different ISPs are >>> responsible. >>> > >> >>> > >> Something like SUCV, that would allow an ISP to cryptographically >>> > identify >>> > >> to what other ISP an address belonged, might be useful in this >>> context. >>> > >> >>> > >> jak >>> > From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 14 10:14:32 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05498 for ; Tue, 14 Aug 2001 10:14: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 HAA28491; Tue, 14 Aug 2001 07:15: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 HAA22572; Tue, 14 Aug 2001 07:15:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7EEEQn07900 for mobile-ip-dist; Tue, 14 Aug 2001 07:14:26 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7EEEMD07893 for ; Tue, 14 Aug 2001 07:14: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 HAA13802 for ; Tue, 14 Aug 2001 07:14:12 -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 HAA03135 for ; Tue, 14 Aug 2001 07:14:11 -0700 (PDT) Received: from inrialpes.fr (galibier.inrialpes.fr [194.199.24.97]) by ebene.inrialpes.fr (8.11.3/8.11.3) with ESMTP id f7EEB1b21165 for ; Tue, 14 Aug 2001 16:11:01 +0200 (MEST) Message-ID: <3B79320E.837B04A5@inrialpes.fr> Date: Tue, 14 Aug 2001 16:13:34 +0200 From: Thierry Ernst Organization: INRIA Rhone-Alpes X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile Routers support without optimization References: <3B77E391.1E9A5D34@era.ericsson.se> <3B791712.402C5195@inrialpes.fr> <3B79294B.EE96B225@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 Mattias Pettersson wrote: > > I am not sure. I may have missed something here. I agree with you in > > the simplest case where the "Mobile Network Prefix" is the same as the > > "home link prefix" with a longer prefix, otherwise I am kind of > > sceptical. > > But the Mobile Network Prefix can't be a subset of the home link prefix. > They should be parallel and both have /64. Or am I wrong? Don't you want > ordinary hosts on the home link as well? Indeed, I wouldn't exclude this case. What do you mean by "If routing is consistent and transparent with regards to this home link, I also think that this is the ideal solution. " in a previous mail ? You just want to say that MR does not need to carry the Mobile Network Prefix in order to register with the HA ? > > > However, Mobile IPv6 fails to be fully transparent when it comes to > > > link-local addresses. > > > > > > Unfortunately, we couldn't make an agreement on how nodes would > > > function. It is obviously implementation dependent whether the home > > > agent will do binding cache lookup and routing table lookup in the > > > correct order to allow this. > > > > > > I pointed out that a BSD home agent could probably work like described > > > above, but Thierry shows in the draft that INRIA's MIPv6 code would not. > > > > INRIA MIPv6 is actually FreeBSD. > > I know. My feeling with the example in your draft is to support your > prefix BU. Perhaps INRIA's implementation could be made to work like I > described, without use of of prefix BU. Not without modification, but > anyway. I could only agree with you as far as you don't want routing optimization. But an important aim of my draft is to allow optimal routing, and the prefix is needed for that. This is the justification. Do you disagree with that ? > > If distinct implementations lead to distinct results, this means that > > the MIPv6 specification needs a word about it. It is not clear if the > > HA is able to tunnel packets intended to the other devices behind the > > mobile router. The processing of the R-bit by the HA needs > > clarification. > > Good point. > > > What I am saying here is that things get more complicated for a mobile > > node which is also router. There are many issues to care about, and > > this cannot be solved as easily as one would think. > > > > I agree. This is not so easy at all. Mobile IP as a general vision could > probably seem to work fine for both hosts and routers. But with all work > currently done with MIPv6, ND and so on is to support mobile hosts only. > In the detailed design work, only hosts have been considered. Nobody > really thought on the routers, until now. Yes. Then, the conclusion would be that we should add something like the following in the MIPv6 spec: "MIPv6 is a solution to support mobile nodes. It does not support nodes behind a mobile router". Dot. I don't remember who, but someone said that we have to insure that what is in the mipv6 draft does not pretend to support mobile networks. Then, mobile networks will be addressed in an other spec. I think that we had consensus on this at last MIP WG meeting. 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 Tue Aug 14 10:36:46 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06005 for ; Tue, 14 Aug 2001 10:36: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 HAA07591; Tue, 14 Aug 2001 07:37:40 -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 HAA02671; Tue, 14 Aug 2001 07:37:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7EEaXY08077 for mobile-ip-dist; Tue, 14 Aug 2001 07:36:33 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7EEaTD08070 for ; Tue, 14 Aug 2001 07:36:29 -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 HAA17651 for ; Tue, 14 Aug 2001 07:36:30 -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 HAA14993 for ; Tue, 14 Aug 2001 07:36:30 -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 JAA17317 for ; Tue, 14 Aug 2001 09:36:29 -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 f7EEaT915086 for ; Tue, 14 Aug 2001 09:36:29 -0500 (CDT) Message-ID: <3B795267.651462F8@usa.alcatel.com> Date: Tue, 14 Aug 2001 09:31:35 -0700 From: Xiaofeng Xu 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] Heterogeneous Handover - where do i look 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 TR 29.023 v3.0.0 is a Technical Report, not a TS. You may find it here: http://www.3gpp.org/ftp/Specs/2001-03/R1999/23_series/ GGSN is the anchor point of a registered PDP context, no handover is needed if MS stays in the GPRS network. Regards, Xiaofeng "Shaheen, Kamel M." wrote: > I searched for 29.023 but did not find a document under this number in R99, > R4, nor R5. > Would you kindly refer me to where this document can be found. > > The working document for GPRS is 23.060. It has all related procedures > including mobility management. > One thing I am sure is not there is Inter-GGSN handoff (Hand-over) > procedures. > > Further, If my memory serves me well, I recall reading that this issue is > out of the scope of this document. > > If this issue is to come up, I believe 3GPP SA2 will be the place to raise > this issue. > > Regards, > > Kamel > -----Original Message----- > From: Doradla, Anil [mailto:doradla@tri.sbc.com] > Sent: Tuesday, August 14, 2001 9:50 AM > To: 'mobile-ip@sunroof.eng.sun.com' > Subject: RE: [mobile-ip] Heterogeneous Handover - where do i look > > Thanks for replying to my enquiry. I have looked at the 3GPP documents. MIP > has been incorporated as an option for mobility management (i think it is > document 3GPP TS 29.023??). Basically, there were three options laied out. > They are: > 1. Incorporating MIP totally in a 3GPP core > 2. Incorporate MIP and GTP together > 3. Make enhancements to GTP for mobility management. > > You do bring up a good point that we need to understand how vendors are > implementing MIP in GPRS networks. My 2 cents is that present GPRS networks > that are being deployed across the world do not incorporate MIP. > As far as handsets are concered, we have not looked at them closely. > BTW, do you have any references that you can lead me on to ?? > > Thanaks a lot > > Anil > > ---------------------------------------------------------------------------- > ------------ > Wireless Communications Division > SBC Technology Resources, Inc. > 9505 Arboretum Blvd > Austin, TX-78759 > (512) 372-5805 > FAX: (512) 372-5891 > > This e-mail and any files transmitted with it are the property of SBC, are > confidential, and are intended solely for the use of the individual or > entity to whom this e-mail is addressed. If you are not one of the named > recipient(s) or otherwise have reason to believe that you have received this > message in error, please notify the sender at 512 372-5805 and delete this > message immediately from your computer. Any other use, retention, > dissemination, forwarding, printing, or copying of this e-mail is strictly > prohibited. > > -----Original Message----- > From: Shaheen, Kamel M. [mailto:Kamel.Shaheen@interdigital.com] > Sent: Tuesday, August 14, 2001 7:55 AM > To: 'mobile-ip@sunroof.eng.sun.com' > Subject: RE: [mobile-ip] Heterogeneous Handover - where do i look > > GPRS standards (i.e., 23.060) do not specify MIP for inter-GGSN handover. > > -----Original Message----- > From: James Kempf [mailto:James.Kempf@Sun.COM] > Sent: Monday, August 13, 2001 3:52 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Heterogeneous Handover - where do i look > > Doradla, > > My understanding is that although the GPRS standard specifies MIP > for inter-GGSN handover, there has been very little effort to clarify > exactly how this would work and how it would interact with GTP-based > mobility, primarily, I'm told, due to lack of operator interest. > I do not know if manufacturers are even building MIP into their terminals. > So, prior to figuring out at the IP level how heterogeneous handover > would work, there is a need to figure out in GPRS how MIP and GPRS > will work together. > > jak > > >From: "Doradla, Anil" > >To: "'mobile-ip@sunroof.eng.sun.com'" > >Subject: [mobile-ip] Heterogeneous Handover - where do i look > >Date: Fri, 10 Aug 2001 11:28:03 -0500 > >All: > > > >Coming back to the question of handover across heterogeneous wireless > >networks. Can anyone advise me as to where i should look at? > >We are seeing a desire for handover between 802.11 and GPRS networks. Is > >there any group looking at the feasibility of this ? > > > >Thanks in advance > > > >Anil Doradla > >SBC- Technology Resources, Inc. > >Austin, TX-78727 > > > > > >-----Original Message----- > >From: James Kempf [mailto:James.Kempf@sun.com] > >Sent: Friday, August 10, 2001 3:57 AM > >To: mobile-ip@sunroof.eng.sun.com; mobile-ip@sunroof.eng.sun.com > >Cc: Peter.Dahl > >Subject: RE: [mobile-ip] Heterogeneous Handover - How Would it Work? > > > > > >Glenn, > > > >I think Raj is right on here, sorry. There are enough technical issues > >involved in getting MIP to be deployable that the MIP group really > >needs to focus on. An example is this NAT question. > > > >If there are any operational issues involved in handover between operators > >that > >need resolution, they should probably be handled in a separate working > >group, like ROAMOPS. An example of such an issue might be advertising > >access routers between operators using something like the Seamoby > >CAR discovery protocol, which is just now getting off the ground. > > > > jak > >>Raj, > >> > >>That's like saying that BGP doesn't deal with the routing policy related > to > >>business relationships between the owners of autonomous systems. You are > >>shoe-holing the group into only dealing with an enterprise - not the > >>Internet. > >> > >>-----Original Message----- > >>From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com] > >>Sent: Thursday, August 09, 2001 10:55 AM > >>To: mobile-ip > >>Cc: Peter.Dahl > >>Subject: RE: [mobile-ip] Heterogeneous Handover - How Would it Work? > >> > >> > >>Clearly, you are mixing roaming with seamless mobility across > >>heterogeneous > >>access types. The Mobile IP WG does not deal with aspects related to > >>roaming > >>agreements between operators or administrative domains. That is NOT what > >>this WG is about. > >> > >>-Basavaraj > >> > >>> -----Original Message----- > >>> From: ext Dahl, Peter [mailto:Peter.Dahl@VerizonWireless.com] > >>> Sent: Wednesday, August 08, 2001 1:53 PM > >>> To: 'mobile-ip@sunroof.eng.sun.com' > >>> Subject: RE: [mobile-ip] Heterogeneous Handover - How Would it Work? > >>> > >>> > >>> ...not forgetting cdma2000. I am not aware of any work in > >>> 3GPP2 or IEEE, > >>> perhaps 3GPP ? > >>> > >>> Pete > >>> > >>> -----Original Message----- > >>> From: Brad Casemore [mailto:bcasemore@home.com] > >>> Sent: Wednesday, August 08, 2001 11:29 AM > >>> To: mobile-ip@sunroof.eng.sun.com > >>> Subject: RE: [mobile-ip] Heterogeneous Handover - How Would it Work? > >>> > >>> > >>> If that is the case, then WECA's WISPr is dedicated to > >>> 802.11b roaming, > >>> while the ETSI has assigned a group to address GPRS roaming. > >>> Is there a > >>> group anywhere that is looking into the technical issues > >>> associated with > >>> heterogeneous network roaming (such as between, theoretically, 802.11b > >>> WLANs and GPRS)? > >>> > >>> Brad > >>> > >>> > -----Original Message----- > >>> > From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile- > >>> > ip@sunroof.eng.sun.com] On Behalf Of James Kempf > >>> > Sent: Wednesday, August 08, 2001 2:19 AM > >>> > To: mobile-ip@sunroof.eng.sun.com; mobile-ip@sunroof.eng.sun.com > >>> > Subject: Re: [mobile-ip] Heterogeneous Handover - How Would it Work? > >>> > > >>> > Pat, > >>> > > >>> > I think they already have such a standard and I believe it > >>> only works > >>> > with GPRS. > >>> > > >>> > jak > >>> > > >>> > >Also, I believe that ETSI is working on a standard called GRX for > >>> GSM<- > >>> > >802.11 > >>> > >roaming. > >>> > > > >>> > >PatC > >>> > >On Tue, Aug 07, 2001 at 09:32:58AM -0700, Dahl, Peter wrote: > >>> > >> FYI, the Wireless ISPs (WISPs) are already talking about such > >>> roaming > >>> > >> issues. > >>> > >> > >>> > >> There appear to be 2 emerging forums for these discussions, one > >>> under > >>> > the > >>> > >> auspices of WECA (http://www.weca.net) known as the WISPr group > >>> ('r' > >>> > being > >>> > >> for roaming), the other a yet to be finalized 'WISP Forum' the > >>> prime > >>> > mover > >>> > >> for which is a company in Luxembourg (www.excilan.com). > >>> > >> > >>> > >> Regards > >>> > >> > >>> > >> -----Original Message----- > >>> > >> From: James Kempf [mailto:James.Kempf@Sun.COM] > >>> > >> Sent: Tuesday, August 07, 2001 8:58 AM > >>> > >> To: mobile-ip@sunroof.eng.sun.com; mobile-ip@sunroof.eng.sun.com > >>> > >> Subject: Re: [mobile-ip] Heterogeneous Handover - How Would it > >>> Work? > >>> > >> > >>> > >> > >>> > >> >On the other hand, the home address must belong to some > >>> ISP/operator. > >>> > >> >That ISP must provide a home agent and an ip address, and a CoA > >>> when > >>> > the > >>> > >> >MN is connected to other than the home subnet. Other > >>> ISPs that are > >>> > used > >>> > >> >are only access providers, and would give the MN its > >>> CoA. This of > >>> > course > >>> > >> >would cause political problems. Who are the ISPs that > >>> are willing > >>> to > >>> > be > >>> > >> >access providers only, and who will be providing home agent and > >>> home > >>> > >> >address as well? > >>> > >> > > >>> > >> > >>> > >> This is an issue. What happens if you have one access provider on > >>> > >> one interface, say the wCDMA interface, and another on > >>> another, say > >>> > 802.11? > >>> > >> There are now in the US a growing number of 802.11 access > >>> providers, > >>> > >> and I can imagine someone with a laptop having a wCDMA modem and > >>> > >> an 802.11 card. > >>> > >> > >>> > >> Maybe something like the "roaming consortia" that have sprung up > >>> > >> around ISP access might evolve, but the protocol > >>> design/engineering > >>> > >> issue is whether there is any additional work (such as the NAI in > >>> > >> the roaming consortia example) needed to enable sharing of a home > >>> > >> address among interfaces for which different ISPs are > >>> responsible. > >>> > >> > >>> > >> Something like SUCV, that would allow an ISP to cryptographically > >>> > identify > >>> > >> to what other ISP an address belonged, might be useful in this > >>> context. > >>> > >> > >>> > >> jak > >>> > > From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 14 10:39:23 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06057 for ; Tue, 14 Aug 2001 10:39:23 -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 HAA08819; Tue, 14 Aug 2001 07:40: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 HAA03147; Tue, 14 Aug 2001 07:40:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7EEdQC08162 for mobile-ip-dist; Tue, 14 Aug 2001 07:39:26 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7EEdMD08155 for ; Tue, 14 Aug 2001 07:39: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 HAA28244 for ; Tue, 14 Aug 2001 07:39:23 -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 IAA25088 for ; Tue, 14 Aug 2001 08:39:18 -0600 (MDT) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f7EEdIN16831 for ; Tue, 14 Aug 2001 16:39:19 +0200 (MEST) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id QAA23548; Tue, 14 Aug 2001 16:39:18 +0200 Message-ID: <3B7937A9.840171E@era.ericsson.se> Date: Tue, 14 Aug 2001 16:37:29 +0200 From: Mattias Pettersson Organization: Ericsson Research X-Mailer: Mozilla 4.77 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile Routers support without optimization References: <3B7923D6.B231F8D3@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 Alexandru Petrescu wrote: > > Mattias Pettersson writes: > > I proposed (and Erik means the same, I think) to do a mapping between > > the MR's home address and its CoA in the HA. A binding for the mobile > > prefix (that MNNs belong to) is not needed, since the HA _should already > > have_ one in its routing table. This entry is created from routing > > protocols between the MR and the home link routers, including the HA. > > That entry simply tells the HA to route traffic to the mobile prefix to > > the gateway address of the MR. > > Is HA necessarily located in the BR (Thierry's border router)? No. > Is HA > necessarily running a routing protocol? Is HA necessarily > participating in route exchanges if it's not a router? I need to > understand this. > As I see it, HA is a router since it forwards traffic that is not destined to itself. It can have one physical interface (but maybe one additional virtual tunnel interface for each MN it serves). > > [Ok, this introduces another problem. The gateway address should be a > > link-local address, since routing protocols use that. Mobile IPv6 does > > not suggest forwarding of packets destined to a link-local > > addresses... > > I agree with the link-local reasoning. In fact I also pointed it to > Thierry late last year. Hopefully it will make it into future > versions of the draft. > > > However, the HA will first have to do a lookup on the destination > > address (MNN), and it will see that it should use MR's link-local > > address. > > This works fine if HA has a route to MR's subnet. > > > Next, it should consult its Binding Cache to find that this packet > > should be forwarded to the MR's CoA by using a tunnel. The special > > order in which routing table and binding cache lookups needs to be > > done is far from common practice, and I don't think this will work > > smoothly with all implementations out there.] > > An alternative to coupled binding cache/route table lookups would be > to extend the binding cache entry with a third address: the network > prefix behind the respective home address. This way the HA is not > required to participate in route maintenance (route maintenance is > done not only for subnets behind MR's but also all other fixed routers > on same home link). > Yeah, maybe. But I feel that we should try to make Mobile IPv6 with minimal inpact on other protocols. If HA is a standard router as well, should it have special handling of routes to some adjacent routers (i.e. MRs)? What if the MR is at home - should it now exchange routing info with the HA as a normal router would do? Or maybe we need restrictions on how home links are configured and what nodes we put there. /Mattias > This alternative is different from Thierry's draft as well as from the > short lived -14. > > Alex From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 14 10:42:12 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06237 for ; Tue, 14 Aug 2001 10:42: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 HAA10243; Tue, 14 Aug 2001 07:43: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 HAA03589; Tue, 14 Aug 2001 07:42:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7EEgBI08244 for mobile-ip-dist; Tue, 14 Aug 2001 07:42:11 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7EEg8D08237 for ; Tue, 14 Aug 2001 07:42: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 HAA27734 for ; Tue, 14 Aug 2001 07:42:09 -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 HAA17474 for ; Tue, 14 Aug 2001 07:42:09 -0700 (PDT) Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80]) by netmail.alcatel.com (8.9.1/8.9.1) with ESMTP id JAA20034 for ; Tue, 14 Aug 2001 09:42:08 -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 f7EEg8916236 for ; Tue, 14 Aug 2001 09:42:08 -0500 (CDT) Message-ID: <3B7953B9.E401516A@usa.alcatel.com> Date: Tue, 14 Aug 2001 09:37:13 -0700 From: Xiaofeng Xu 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] Heterogeneous Handover - where do i look References: <3B795267.651462F8@usa.alcatel.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 should be TR 23.923. Xiaofeng Xu wrote: > TR 29.023 v3.0.0 is a Technical Report, not a TS. You may find it here: > http://www.3gpp.org/ftp/Specs/2001-03/R1999/23_series/ > > GGSN is the anchor point of a registered PDP context, no handover is needed if > MS stays in the GPRS network. > > Regards, > Xiaofeng > > "Shaheen, Kamel M." wrote: > > > I searched for 29.023 but did not find a document under this number in R99, > > R4, nor R5. > > Would you kindly refer me to where this document can be found. > > > > The working document for GPRS is 23.060. It has all related procedures > > including mobility management. > > One thing I am sure is not there is Inter-GGSN handoff (Hand-over) > > procedures. > > > > Further, If my memory serves me well, I recall reading that this issue is > > out of the scope of this document. > > > > If this issue is to come up, I believe 3GPP SA2 will be the place to raise > > this issue. > > > > Regards, > > > > Kamel > > -----Original Message----- > > From: Doradla, Anil [mailto:doradla@tri.sbc.com] > > Sent: Tuesday, August 14, 2001 9:50 AM > > To: 'mobile-ip@sunroof.eng.sun.com' > > Subject: RE: [mobile-ip] Heterogeneous Handover - where do i look > > > > Thanks for replying to my enquiry. I have looked at the 3GPP documents. MIP > > has been incorporated as an option for mobility management (i think it is > > document 3GPP TS 29.023??). Basically, there were three options laied out. > > They are: > > 1. Incorporating MIP totally in a 3GPP core > > 2. Incorporate MIP and GTP together > > 3. Make enhancements to GTP for mobility management. > > > > You do bring up a good point that we need to understand how vendors are > > implementing MIP in GPRS networks. My 2 cents is that present GPRS networks > > that are being deployed across the world do not incorporate MIP. > > As far as handsets are concered, we have not looked at them closely. > > BTW, do you have any references that you can lead me on to ?? > > > > Thanaks a lot > > > > Anil > > > > ---------------------------------------------------------------------------- > > ------------ > > Wireless Communications Division > > SBC Technology Resources, Inc. > > 9505 Arboretum Blvd > > Austin, TX-78759 > > (512) 372-5805 > > FAX: (512) 372-5891 > > > > This e-mail and any files transmitted with it are the property of SBC, are > > confidential, and are intended solely for the use of the individual or > > entity to whom this e-mail is addressed. If you are not one of the named > > recipient(s) or otherwise have reason to believe that you have received this > > message in error, please notify the sender at 512 372-5805 and delete this > > message immediately from your computer. Any other use, retention, > > dissemination, forwarding, printing, or copying of this e-mail is strictly > > prohibited. > > > > -----Original Message----- > > From: Shaheen, Kamel M. [mailto:Kamel.Shaheen@interdigital.com] > > Sent: Tuesday, August 14, 2001 7:55 AM > > To: 'mobile-ip@sunroof.eng.sun.com' > > Subject: RE: [mobile-ip] Heterogeneous Handover - where do i look > > > > GPRS standards (i.e., 23.060) do not specify MIP for inter-GGSN handover. > > > > -----Original Message----- > > From: James Kempf [mailto:James.Kempf@Sun.COM] > > Sent: Monday, August 13, 2001 3:52 PM > > To: mobile-ip@sunroof.eng.sun.com > > Subject: Re: [mobile-ip] Heterogeneous Handover - where do i look > > > > Doradla, > > > > My understanding is that although the GPRS standard specifies MIP > > for inter-GGSN handover, there has been very little effort to clarify > > exactly how this would work and how it would interact with GTP-based > > mobility, primarily, I'm told, due to lack of operator interest. > > I do not know if manufacturers are even building MIP into their terminals. > > So, prior to figuring out at the IP level how heterogeneous handover > > would work, there is a need to figure out in GPRS how MIP and GPRS > > will work together. > > > > jak > > > > >From: "Doradla, Anil" > > >To: "'mobile-ip@sunroof.eng.sun.com'" > > >Subject: [mobile-ip] Heterogeneous Handover - where do i look > > >Date: Fri, 10 Aug 2001 11:28:03 -0500 > > >All: > > > > > >Coming back to the question of handover across heterogeneous wireless > > >networks. Can anyone advise me as to where i should look at? > > >We are seeing a desire for handover between 802.11 and GPRS networks. Is > > >there any group looking at the feasibility of this ? > > > > > >Thanks in advance > > > > > >Anil Doradla > > >SBC- Technology Resources, Inc. > > >Austin, TX-78727 > > > > > > > > >-----Original Message----- > > >From: James Kempf [mailto:James.Kempf@sun.com] > > >Sent: Friday, August 10, 2001 3:57 AM > > >To: mobile-ip@sunroof.eng.sun.com; mobile-ip@sunroof.eng.sun.com > > >Cc: Peter.Dahl > > >Subject: RE: [mobile-ip] Heterogeneous Handover - How Would it Work? > > > > > > > > >Glenn, > > > > > >I think Raj is right on here, sorry. There are enough technical issues > > >involved in getting MIP to be deployable that the MIP group really > > >needs to focus on. An example is this NAT question. > > > > > >If there are any operational issues involved in handover between operators > > >that > > >need resolution, they should probably be handled in a separate working > > >group, like ROAMOPS. An example of such an issue might be advertising > > >access routers between operators using something like the Seamoby > > >CAR discovery protocol, which is just now getting off the ground. > > > > > > jak > > >>Raj, > > >> > > >>That's like saying that BGP doesn't deal with the routing policy related > > to > > >>business relationships between the owners of autonomous systems. You are > > >>shoe-holing the group into only dealing with an enterprise - not the > > >>Internet. > > >> > > >>-----Original Message----- > > >>From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com] > > >>Sent: Thursday, August 09, 2001 10:55 AM > > >>To: mobile-ip > > >>Cc: Peter.Dahl > > >>Subject: RE: [mobile-ip] Heterogeneous Handover - How Would it Work? > > >> > > >> > > >>Clearly, you are mixing roaming with seamless mobility across > > >>heterogeneous > > >>access types. The Mobile IP WG does not deal with aspects related to > > >>roaming > > >>agreements between operators or administrative domains. That is NOT what > > >>this WG is about. > > >> > > >>-Basavaraj > > >> > > >>> -----Original Message----- > > >>> From: ext Dahl, Peter [mailto:Peter.Dahl@VerizonWireless.com] > > >>> Sent: Wednesday, August 08, 2001 1:53 PM > > >>> To: 'mobile-ip@sunroof.eng.sun.com' > > >>> Subject: RE: [mobile-ip] Heterogeneous Handover - How Would it Work? > > >>> > > >>> > > >>> ...not forgetting cdma2000. I am not aware of any work in > > >>> 3GPP2 or IEEE, > > >>> perhaps 3GPP ? > > >>> > > >>> Pete > > >>> > > >>> -----Original Message----- > > >>> From: Brad Casemore [mailto:bcasemore@home.com] > > >>> Sent: Wednesday, August 08, 2001 11:29 AM > > >>> To: mobile-ip@sunroof.eng.sun.com > > >>> Subject: RE: [mobile-ip] Heterogeneous Handover - How Would it Work? > > >>> > > >>> > > >>> If that is the case, then WECA's WISPr is dedicated to > > >>> 802.11b roaming, > > >>> while the ETSI has assigned a group to address GPRS roaming. > > >>> Is there a > > >>> group anywhere that is looking into the technical issues > > >>> associated with > > >>> heterogeneous network roaming (such as between, theoretically, 802.11b > > >>> WLANs and GPRS)? > > >>> > > >>> Brad > > >>> > > >>> > -----Original Message----- > > >>> > From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile- > > >>> > ip@sunroof.eng.sun.com] On Behalf Of James Kempf > > >>> > Sent: Wednesday, August 08, 2001 2:19 AM > > >>> > To: mobile-ip@sunroof.eng.sun.com; mobile-ip@sunroof.eng.sun.com > > >>> > Subject: Re: [mobile-ip] Heterogeneous Handover - How Would it Work? > > >>> > > > >>> > Pat, > > >>> > > > >>> > I think they already have such a standard and I believe it > > >>> only works > > >>> > with GPRS. > > >>> > > > >>> > jak > > >>> > > > >>> > >Also, I believe that ETSI is working on a standard called GRX for > > >>> GSM<- > > >>> > >802.11 > > >>> > >roaming. > > >>> > > > > >>> > >PatC > > >>> > >On Tue, Aug 07, 2001 at 09:32:58AM -0700, Dahl, Peter wrote: > > >>> > >> FYI, the Wireless ISPs (WISPs) are already talking about such > > >>> roaming > > >>> > >> issues. > > >>> > >> > > >>> > >> There appear to be 2 emerging forums for these discussions, one > > >>> under > > >>> > the > > >>> > >> auspices of WECA (http://www.weca.net) known as the WISPr group > > >>> ('r' > > >>> > being > > >>> > >> for roaming), the other a yet to be finalized 'WISP Forum' the > > >>> prime > > >>> > mover > > >>> > >> for which is a company in Luxembourg (www.excilan.com). > > >>> > >> > > >>> > >> Regards > > >>> > >> > > >>> > >> -----Original Message----- > > >>> > >> From: James Kempf [mailto:James.Kempf@Sun.COM] > > >>> > >> Sent: Tuesday, August 07, 2001 8:58 AM > > >>> > >> To: mobile-ip@sunroof.eng.sun.com; mobile-ip@sunroof.eng.sun.com > > >>> > >> Subject: Re: [mobile-ip] Heterogeneous Handover - How Would it > > >>> Work? > > >>> > >> > > >>> > >> > > >>> > >> >On the other hand, the home address must belong to some > > >>> ISP/operator. > > >>> > >> >That ISP must provide a home agent and an ip address, and a CoA > > >>> when > > >>> > the > > >>> > >> >MN is connected to other than the home subnet. Other > > >>> ISPs that are > > >>> > used > > >>> > >> >are only access providers, and would give the MN its > > >>> CoA. This of > > >>> > course > > >>> > >> >would cause political problems. Who are the ISPs that > > >>> are willing > > >>> to > > >>> > be > > >>> > >> >access providers only, and who will be providing home agent and > > >>> home > > >>> > >> >address as well? > > >>> > >> > > > >>> > >> > > >>> > >> This is an issue. What happens if you have one access provider on > > >>> > >> one interface, say the wCDMA interface, and another on > > >>> another, say > > >>> > 802.11? > > >>> > >> There are now in the US a growing number of 802.11 access > > >>> providers, > > >>> > >> and I can imagine someone with a laptop having a wCDMA modem and > > >>> > >> an 802.11 card. > > >>> > >> > > >>> > >> Maybe something like the "roaming consortia" that have sprung up > > >>> > >> around ISP access might evolve, but the protocol > > >>> design/engineering > > >>> > >> issue is whether there is any additional work (such as the NAI in > > >>> > >> the roaming consortia example) needed to enable sharing of a home > > >>> > >> address among interfaces for which different ISPs are > > >>> responsible. > > >>> > >> > > >>> > >> Something like SUCV, that would allow an ISP to cryptographically > > >>> > identify > > >>> > >> to what other ISP an address belonged, might be useful in this > > >>> context. > > >>> > >> > > >>> > >> jak > > >>> > > > From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 14 10:53:49 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06517 for ; Tue, 14 Aug 2001 10:53: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 HAA15184; Tue, 14 Aug 2001 07:54: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 HAA05201; Tue, 14 Aug 2001 07:53:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7EEr5j08422 for mobile-ip-dist; Tue, 14 Aug 2001 07:53:05 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7EEr1D08415 for ; Tue, 14 Aug 2001 07:53: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 HAA29074 for ; Tue, 14 Aug 2001 07:53:02 -0700 (PDT) Received: from idcpa4.pa.interdigital.com ([12.32.197.142]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA20770 for ; Tue, 14 Aug 2001 08:53:10 -0600 (MDT) Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19) id ; Tue, 14 Aug 2001 10:51:48 -0400 Message-ID: From: "Shaheen, Kamel M." To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Heterogeneous Handover - where do i look Date: Tue, 14 Aug 2001 10:51: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: Now it make sense! -----Original Message----- From: Xiaofeng Xu [mailto:xiaofeng.xu@usa.alcatel.com] Sent: Tuesday, August 14, 2001 12:37 PM To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Heterogeneous Handover - where do i look It should be TR 23.923. Xiaofeng Xu wrote: > TR 29.023 v3.0.0 is a Technical Report, not a TS. You may find it here: > http://www.3gpp.org/ftp/Specs/2001-03/R1999/23_series/ > > GGSN is the anchor point of a registered PDP context, no handover is needed if > MS stays in the GPRS network. > > Regards, > Xiaofeng > > "Shaheen, Kamel M." wrote: > > > I searched for 29.023 but did not find a document under this number in R99, > > R4, nor R5. > > Would you kindly refer me to where this document can be found. > > > > The working document for GPRS is 23.060. It has all related procedures > > including mobility management. > > One thing I am sure is not there is Inter-GGSN handoff (Hand-over) > > procedures. > > > > Further, If my memory serves me well, I recall reading that this issue is > > out of the scope of this document. > > > > If this issue is to come up, I believe 3GPP SA2 will be the place to raise > > this issue. > > > > Regards, > > > > Kamel > > -----Original Message----- > > From: Doradla, Anil [mailto:doradla@tri.sbc.com] > > Sent: Tuesday, August 14, 2001 9:50 AM > > To: 'mobile-ip@sunroof.eng.sun.com' > > Subject: RE: [mobile-ip] Heterogeneous Handover - where do i look > > > > Thanks for replying to my enquiry. I have looked at the 3GPP documents. MIP > > has been incorporated as an option for mobility management (i think it is > > document 3GPP TS 29.023??). Basically, there were three options laied out. > > They are: > > 1. Incorporating MIP totally in a 3GPP core > > 2. Incorporate MIP and GTP together > > 3. Make enhancements to GTP for mobility management. > > > > You do bring up a good point that we need to understand how vendors are > > implementing MIP in GPRS networks. My 2 cents is that present GPRS networks > > that are being deployed across the world do not incorporate MIP. > > As far as handsets are concered, we have not looked at them closely. > > BTW, do you have any references that you can lead me on to ?? > > > > Thanaks a lot > > > > Anil > > > > ---------------------------------------------------------------------------- > > ------------ > > Wireless Communications Division > > SBC Technology Resources, Inc. > > 9505 Arboretum Blvd > > Austin, TX-78759 > > (512) 372-5805 > > FAX: (512) 372-5891 > > > > This e-mail and any files transmitted with it are the property of SBC, are > > confidential, and are intended solely for the use of the individual or > > entity to whom this e-mail is addressed. If you are not one of the named > > recipient(s) or otherwise have reason to believe that you have received this > > message in error, please notify the sender at 512 372-5805 and delete this > > message immediately from your computer. Any other use, retention, > > dissemination, forwarding, printing, or copying of this e-mail is strictly > > prohibited. > > > > -----Original Message----- > > From: Shaheen, Kamel M. [mailto:Kamel.Shaheen@interdigital.com] > > Sent: Tuesday, August 14, 2001 7:55 AM > > To: 'mobile-ip@sunroof.eng.sun.com' > > Subject: RE: [mobile-ip] Heterogeneous Handover - where do i look > > > > GPRS standards (i.e., 23.060) do not specify MIP for inter-GGSN handover. > > > > -----Original Message----- > > From: James Kempf [mailto:James.Kempf@Sun.COM] > > Sent: Monday, August 13, 2001 3:52 PM > > To: mobile-ip@sunroof.eng.sun.com > > Subject: Re: [mobile-ip] Heterogeneous Handover - where do i look > > > > Doradla, > > > > My understanding is that although the GPRS standard specifies MIP > > for inter-GGSN handover, there has been very little effort to clarify > > exactly how this would work and how it would interact with GTP-based > > mobility, primarily, I'm told, due to lack of operator interest. > > I do not know if manufacturers are even building MIP into their terminals. > > So, prior to figuring out at the IP level how heterogeneous handover > > would work, there is a need to figure out in GPRS how MIP and GPRS > > will work together. > > > > jak > > > > >From: "Doradla, Anil" > > >To: "'mobile-ip@sunroof.eng.sun.com'" > > >Subject: [mobile-ip] Heterogeneous Handover - where do i look > > >Date: Fri, 10 Aug 2001 11:28:03 -0500 > > >All: > > > > > >Coming back to the question of handover across heterogeneous wireless > > >networks. Can anyone advise me as to where i should look at? > > >We are seeing a desire for handover between 802.11 and GPRS networks. Is > > >there any group looking at the feasibility of this ? > > > > > >Thanks in advance > > > > > >Anil Doradla > > >SBC- Technology Resources, Inc. > > >Austin, TX-78727 > > > > > > > > >-----Original Message----- > > >From: James Kempf [mailto:James.Kempf@sun.com] > > >Sent: Friday, August 10, 2001 3:57 AM > > >To: mobile-ip@sunroof.eng.sun.com; mobile-ip@sunroof.eng.sun.com > > >Cc: Peter.Dahl > > >Subject: RE: [mobile-ip] Heterogeneous Handover - How Would it Work? > > > > > > > > >Glenn, > > > > > >I think Raj is right on here, sorry. There are enough technical issues > > >involved in getting MIP to be deployable that the MIP group really > > >needs to focus on. An example is this NAT question. > > > > > >If there are any operational issues involved in handover between operators > > >that > > >need resolution, they should probably be handled in a separate working > > >group, like ROAMOPS. An example of such an issue might be advertising > > >access routers between operators using something like the Seamoby > > >CAR discovery protocol, which is just now getting off the ground. > > > > > > jak > > >>Raj, > > >> > > >>That's like saying that BGP doesn't deal with the routing policy related > > to > > >>business relationships between the owners of autonomous systems. You are > > >>shoe-holing the group into only dealing with an enterprise - not the > > >>Internet. > > >> > > >>-----Original Message----- > > >>From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com] > > >>Sent: Thursday, August 09, 2001 10:55 AM > > >>To: mobile-ip > > >>Cc: Peter.Dahl > > >>Subject: RE: [mobile-ip] Heterogeneous Handover - How Would it Work? > > >> > > >> > > >>Clearly, you are mixing roaming with seamless mobility across > > >>heterogeneous > > >>access types. The Mobile IP WG does not deal with aspects related to > > >>roaming > > >>agreements between operators or administrative domains. That is NOT what > > >>this WG is about. > > >> > > >>-Basavaraj > > >> > > >>> -----Original Message----- > > >>> From: ext Dahl, Peter [mailto:Peter.Dahl@VerizonWireless.com] > > >>> Sent: Wednesday, August 08, 2001 1:53 PM > > >>> To: 'mobile-ip@sunroof.eng.sun.com' > > >>> Subject: RE: [mobile-ip] Heterogeneous Handover - How Would it Work? > > >>> > > >>> > > >>> ...not forgetting cdma2000. I am not aware of any work in > > >>> 3GPP2 or IEEE, > > >>> perhaps 3GPP ? > > >>> > > >>> Pete > > >>> > > >>> -----Original Message----- > > >>> From: Brad Casemore [mailto:bcasemore@home.com] > > >>> Sent: Wednesday, August 08, 2001 11:29 AM > > >>> To: mobile-ip@sunroof.eng.sun.com > > >>> Subject: RE: [mobile-ip] Heterogeneous Handover - How Would it Work? > > >>> > > >>> > > >>> If that is the case, then WECA's WISPr is dedicated to > > >>> 802.11b roaming, > > >>> while the ETSI has assigned a group to address GPRS roaming. > > >>> Is there a > > >>> group anywhere that is looking into the technical issues > > >>> associated with > > >>> heterogeneous network roaming (such as between, theoretically, 802.11b > > >>> WLANs and GPRS)? > > >>> > > >>> Brad > > >>> > > >>> > -----Original Message----- > > >>> > From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile- > > >>> > ip@sunroof.eng.sun.com] On Behalf Of James Kempf > > >>> > Sent: Wednesday, August 08, 2001 2:19 AM > > >>> > To: mobile-ip@sunroof.eng.sun.com; mobile-ip@sunroof.eng.sun.com > > >>> > Subject: Re: [mobile-ip] Heterogeneous Handover - How Would it Work? > > >>> > > > >>> > Pat, > > >>> > > > >>> > I think they already have such a standard and I believe it > > >>> only works > > >>> > with GPRS. > > >>> > > > >>> > jak > > >>> > > > >>> > >Also, I believe that ETSI is working on a standard called GRX for > > >>> GSM<- > > >>> > >802.11 > > >>> > >roaming. > > >>> > > > > >>> > >PatC > > >>> > >On Tue, Aug 07, 2001 at 09:32:58AM -0700, Dahl, Peter wrote: > > >>> > >> FYI, the Wireless ISPs (WISPs) are already talking about such > > >>> roaming > > >>> > >> issues. > > >>> > >> > > >>> > >> There appear to be 2 emerging forums for these discussions, one > > >>> under > > >>> > the > > >>> > >> auspices of WECA (http://www.weca.net) known as the WISPr group > > >>> ('r' > > >>> > being > > >>> > >> for roaming), the other a yet to be finalized 'WISP Forum' the > > >>> prime > > >>> > mover > > >>> > >> for which is a company in Luxembourg (www.excilan.com). > > >>> > >> > > >>> > >> Regards > > >>> > >> > > >>> > >> -----Original Message----- > > >>> > >> From: James Kempf [mailto:James.Kempf@Sun.COM] > > >>> > >> Sent: Tuesday, August 07, 2001 8:58 AM > > >>> > >> To: mobile-ip@sunroof.eng.sun.com; mobile-ip@sunroof.eng.sun.com > > >>> > >> Subject: Re: [mobile-ip] Heterogeneous Handover - How Would it > > >>> Work? > > >>> > >> > > >>> > >> > > >>> > >> >On the other hand, the home address must belong to some > > >>> ISP/operator. > > >>> > >> >That ISP must provide a home agent and an ip address, and a CoA > > >>> when > > >>> > the > > >>> > >> >MN is connected to other than the home subnet. Other > > >>> ISPs that are > > >>> > used > > >>> > >> >are only access providers, and would give the MN its > > >>> CoA. This of > > >>> > course > > >>> > >> >would cause political problems. Who are the ISPs that > > >>> are willing > > >>> to > > >>> > be > > >>> > >> >access providers only, and who will be providing home agent and > > >>> home > > >>> > >> >address as well? > > >>> > >> > > > >>> > >> > > >>> > >> This is an issue. What happens if you have one access provider on > > >>> > >> one interface, say the wCDMA interface, and another on > > >>> another, say > > >>> > 802.11? > > >>> > >> There are now in the US a growing number of 802.11 access > > >>> providers, > > >>> > >> and I can imagine someone with a laptop having a wCDMA modem and > > >>> > >> an 802.11 card. > > >>> > >> > > >>> > >> Maybe something like the "roaming consortia" that have sprung up > > >>> > >> around ISP access might evolve, but the protocol > > >>> design/engineering > > >>> > >> issue is whether there is any additional work (such as the NAI in > > >>> > >> the roaming consortia example) needed to enable sharing of a home > > >>> > >> address among interfaces for which different ISPs are > > >>> responsible. > > >>> > >> > > >>> > >> Something like SUCV, that would allow an ISP to cryptographically > > >>> > identify > > >>> > >> to what other ISP an address belonged, might be useful in this > > >>> context. > > >>> > >> > > >>> > >> jak > > >>> > > > From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 14 10:58:16 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06657 for ; Tue, 14 Aug 2001 10:58: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 IAA12077; Tue, 14 Aug 2001 08:58: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 HAA05993; Tue, 14 Aug 2001 07:58:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7EEvqC08529 for mobile-ip-dist; Tue, 14 Aug 2001 07:57:52 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7EEvlD08520 for ; Tue, 14 Aug 2001 07:57:47 -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 HAA29953 for ; Tue, 14 Aug 2001 07:57:48 -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 HAA24790 for ; Tue, 14 Aug 2001 07:57:47 -0700 (PDT) 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 f7EEvkO04446 for ; Tue, 14 Aug 2001 16:57:46 +0200 (MEST) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id QAA24074; Tue, 14 Aug 2001 16:57:45 +0200 Message-ID: <3B793BFC.86D838B1@era.ericsson.se> Date: Tue, 14 Aug 2001 16:55:56 +0200 From: Mattias Pettersson Organization: Ericsson Research X-Mailer: Mozilla 4.77 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile Routers support without optimization References: <3B77E391.1E9A5D34@era.ericsson.se> <3B791712.402C5195@inrialpes.fr> <3B79294B.EE96B225@era.ericsson.se> <3B79320E.837B04A5@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 Thierry Ernst wrote: > > Mattias Pettersson wrote: > > > > I am not sure. I may have missed something here. I agree with you in > > > the simplest case where the "Mobile Network Prefix" is the same as the > > > "home link prefix" with a longer prefix, otherwise I am kind of > > > sceptical. > > > > But the Mobile Network Prefix can't be a subset of the home link prefix. > > They should be parallel and both have /64. Or am I wrong? Don't you want > > ordinary hosts on the home link as well? > > Indeed, I wouldn't exclude this case. > > What do you mean by "If routing is consistent and transparent with > regards to this home link, I also think that this is the ideal solution. > " in a previous mail ? You just want to say that MR does not need to > carry the Mobile Network Prefix in order to register with the HA ? First, I still can accept that we use prefix scoped BUs. For another reason, that is not part of this particular discussion, I suggested that each MNN takes care of its own home registration. It has pros and cons, but at least we don't need to check authorization of prefixes. The HA, when acting as a CN (i.e. initiating traffic itself), *then* it would need a prefix scoped BU. But when it is only intercepting and forwarding packets initiated by others, a standard entry in the binding cache plus a routing entry for the mobile network prefix would be sufficient. Back to your first question: I get the feeling that some original design ideas behind Mobile IP was to emulate that the MN is at home, even when it isn't. To do this, we need a helping hand (the HA), but we should make as little impact as possible. But with current Mobile IPv6 spec, somewhere a line is drawn which says that functions on one side is emulated so that everyone using these functions towards the MN thinks the MN is always at home, while a few other functions can't be hidden. Example of latter are: link-local addresses, ND, home address address assignment (especially stateful), mobile routers... Since we have decided not to forward link-local addresses, we will have to take the consequences of that. This short-cut or optimization was good for one thing (not wasting bandwidth) but is bad when we (I) want to make MRs work like they were always at home. > > > > > However, Mobile IPv6 fails to be fully transparent when it comes to > > > > link-local addresses. > > > > > > > > Unfortunately, we couldn't make an agreement on how nodes would > > > > function. It is obviously implementation dependent whether the home > > > > agent will do binding cache lookup and routing table lookup in the > > > > correct order to allow this. > > > > > > > > I pointed out that a BSD home agent could probably work like described > > > > above, but Thierry shows in the draft that INRIA's MIPv6 code would not. > > > > > > INRIA MIPv6 is actually FreeBSD. > > > > I know. My feeling with the example in your draft is to support your > > prefix BU. Perhaps INRIA's implementation could be made to work like I > > described, without use of of prefix BU. Not without modification, but > > anyway. > > I could only agree with you as far as you don't want routing > optimization. But an important aim of my draft is to allow optimal > routing, and the prefix is needed for that. This is the justification. > Do you disagree with that ? I want route optimization too. I just feel that maybe forwarding and CN part of HA can be separated, and you are doing to much to make it work. The forwarding part would work anyway, without prefix scoped BU. But the CN part needs it. Please see above. > > > > If distinct implementations lead to distinct results, this means that > > > the MIPv6 specification needs a word about it. It is not clear if the > > > HA is able to tunnel packets intended to the other devices behind the > > > mobile router. The processing of the R-bit by the HA needs > > > clarification. > > > > Good point. > > > > > What I am saying here is that things get more complicated for a mobile > > > node which is also router. There are many issues to care about, and > > > this cannot be solved as easily as one would think. > > > > > > > I agree. This is not so easy at all. Mobile IP as a general vision could > > probably seem to work fine for both hosts and routers. But with all work > > currently done with MIPv6, ND and so on is to support mobile hosts only. > > In the detailed design work, only hosts have been considered. Nobody > > really thought on the routers, until now. > > Yes. Then, the conclusion would be that we should add something like the > following in the MIPv6 spec: > "MIPv6 is a solution to support mobile nodes. It does not support nodes > behind a mobile router". Dot. I don't remember who, but someone said > that we have to insure that what is in the mipv6 draft does not pretend > to support mobile networks. Then, mobile networks will be addressed in > an other spec. Yes. /Mattias > > I think that we had consensus on this at last MIP WG meeting. > > 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 Tue Aug 14 10:59:05 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06699 for ; Tue, 14 Aug 2001 10:59: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 JAA13072; Tue, 14 Aug 2001 09:00: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 HAA06249; Tue, 14 Aug 2001 07:59:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7EEx3B08554 for mobile-ip-dist; Tue, 14 Aug 2001 07:59:03 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7EEx0D08547 for ; Tue, 14 Aug 2001 07:59:00 -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 HAA00076 for ; Tue, 14 Aug 2001 07:59:01 -0700 (PDT) Received: from idcpa4.pa.interdigital.com ([12.32.197.142]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA25274 for ; Tue, 14 Aug 2001 08:59:09 -0600 (MDT) Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19) id ; Tue, 14 Aug 2001 10:57:48 -0400 Message-ID: From: "Briancon, Alain C." To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Heterogeneous Handover - where do i look Date: Tue, 14 Aug 2001 10:57: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: does this change your view on sharif persoective? -----Original Message----- From: Shaheen, Kamel M. [mailto:Kamel.Shaheen@InterDigital.com] Sent: Tuesday, 14 August, 2001 10:52 To: 'mobile-ip@sunroof.eng.sun.com' Subject: RE: [mobile-ip] Heterogeneous Handover - where do i look Now it make sense! -----Original Message----- From: Xiaofeng Xu [mailto:xiaofeng.xu@usa.alcatel.com] Sent: Tuesday, August 14, 2001 12:37 PM To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Heterogeneous Handover - where do i look It should be TR 23.923. Xiaofeng Xu wrote: > TR 29.023 v3.0.0 is a Technical Report, not a TS. You may find it here: > http://www.3gpp.org/ftp/Specs/2001-03/R1999/23_series/ > > GGSN is the anchor point of a registered PDP context, no handover is needed if > MS stays in the GPRS network. > > Regards, > Xiaofeng > > "Shaheen, Kamel M." wrote: > > > I searched for 29.023 but did not find a document under this number in R99, > > R4, nor R5. > > Would you kindly refer me to where this document can be found. > > > > The working document for GPRS is 23.060. It has all related procedures > > including mobility management. > > One thing I am sure is not there is Inter-GGSN handoff (Hand-over) > > procedures. > > > > Further, If my memory serves me well, I recall reading that this issue is > > out of the scope of this document. > > > > If this issue is to come up, I believe 3GPP SA2 will be the place to raise > > this issue. > > > > Regards, > > > > Kamel > > -----Original Message----- > > From: Doradla, Anil [mailto:doradla@tri.sbc.com] > > Sent: Tuesday, August 14, 2001 9:50 AM > > To: 'mobile-ip@sunroof.eng.sun.com' > > Subject: RE: [mobile-ip] Heterogeneous Handover - where do i look > > > > Thanks for replying to my enquiry. I have looked at the 3GPP documents. MIP > > has been incorporated as an option for mobility management (i think it is > > document 3GPP TS 29.023??). Basically, there were three options laied out. > > They are: > > 1. Incorporating MIP totally in a 3GPP core > > 2. Incorporate MIP and GTP together > > 3. Make enhancements to GTP for mobility management. > > > > You do bring up a good point that we need to understand how vendors are > > implementing MIP in GPRS networks. My 2 cents is that present GPRS networks > > that are being deployed across the world do not incorporate MIP. > > As far as handsets are concered, we have not looked at them closely. > > BTW, do you have any references that you can lead me on to ?? > > > > Thanaks a lot > > > > Anil > > > > ---------------------------------------------------------------------------- > > ------------ > > Wireless Communications Division > > SBC Technology Resources, Inc. > > 9505 Arboretum Blvd > > Austin, TX-78759 > > (512) 372-5805 > > FAX: (512) 372-5891 > > > > This e-mail and any files transmitted with it are the property of SBC, are > > confidential, and are intended solely for the use of the individual or > > entity to whom this e-mail is addressed. If you are not one of the named > > recipient(s) or otherwise have reason to believe that you have received this > > message in error, please notify the sender at 512 372-5805 and delete this > > message immediately from your computer. Any other use, retention, > > dissemination, forwarding, printing, or copying of this e-mail is strictly > > prohibited. > > > > -----Original Message----- > > From: Shaheen, Kamel M. [mailto:Kamel.Shaheen@interdigital.com] > > Sent: Tuesday, August 14, 2001 7:55 AM > > To: 'mobile-ip@sunroof.eng.sun.com' > > Subject: RE: [mobile-ip] Heterogeneous Handover - where do i look > > > > GPRS standards (i.e., 23.060) do not specify MIP for inter-GGSN handover. > > > > -----Original Message----- > > From: James Kempf [mailto:James.Kempf@Sun.COM] > > Sent: Monday, August 13, 2001 3:52 PM > > To: mobile-ip@sunroof.eng.sun.com > > Subject: Re: [mobile-ip] Heterogeneous Handover - where do i look > > > > Doradla, > > > > My understanding is that although the GPRS standard specifies MIP > > for inter-GGSN handover, there has been very little effort to clarify > > exactly how this would work and how it would interact with GTP-based > > mobility, primarily, I'm told, due to lack of operator interest. > > I do not know if manufacturers are even building MIP into their terminals. > > So, prior to figuring out at the IP level how heterogeneous handover > > would work, there is a need to figure out in GPRS how MIP and GPRS > > will work together. > > > > jak > > > > >From: "Doradla, Anil" > > >To: "'mobile-ip@sunroof.eng.sun.com'" > > >Subject: [mobile-ip] Heterogeneous Handover - where do i look > > >Date: Fri, 10 Aug 2001 11:28:03 -0500 > > >All: > > > > > >Coming back to the question of handover across heterogeneous wireless > > >networks. Can anyone advise me as to where i should look at? > > >We are seeing a desire for handover between 802.11 and GPRS networks. Is > > >there any group looking at the feasibility of this ? > > > > > >Thanks in advance > > > > > >Anil Doradla > > >SBC- Technology Resources, Inc. > > >Austin, TX-78727 > > > > > > > > >-----Original Message----- > > >From: James Kempf [mailto:James.Kempf@sun.com] > > >Sent: Friday, August 10, 2001 3:57 AM > > >To: mobile-ip@sunroof.eng.sun.com; mobile-ip@sunroof.eng.sun.com > > >Cc: Peter.Dahl > > >Subject: RE: [mobile-ip] Heterogeneous Handover - How Would it Work? > > > > > > > > >Glenn, > > > > > >I think Raj is right on here, sorry. There are enough technical issues > > >involved in getting MIP to be deployable that the MIP group really > > >needs to focus on. An example is this NAT question. > > > > > >If there are any operational issues involved in handover between operators > > >that > > >need resolution, they should probably be handled in a separate working > > >group, like ROAMOPS. An example of such an issue might be advertising > > >access routers between operators using something like the Seamoby > > >CAR discovery protocol, which is just now getting off the ground. > > > > > > jak > > >>Raj, > > >> > > >>That's like saying that BGP doesn't deal with the routing policy related > > to > > >>business relationships between the owners of autonomous systems. You are > > >>shoe-holing the group into only dealing with an enterprise - not the > > >>Internet. > > >> > > >>-----Original Message----- > > >>From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com] > > >>Sent: Thursday, August 09, 2001 10:55 AM > > >>To: mobile-ip > > >>Cc: Peter.Dahl > > >>Subject: RE: [mobile-ip] Heterogeneous Handover - How Would it Work? > > >> > > >> > > >>Clearly, you are mixing roaming with seamless mobility across > > >>heterogeneous > > >>access types. The Mobile IP WG does not deal with aspects related to > > >>roaming > > >>agreements between operators or administrative domains. That is NOT what > > >>this WG is about. > > >> > > >>-Basavaraj > > >> > > >>> -----Original Message----- > > >>> From: ext Dahl, Peter [mailto:Peter.Dahl@VerizonWireless.com] > > >>> Sent: Wednesday, August 08, 2001 1:53 PM > > >>> To: 'mobile-ip@sunroof.eng.sun.com' > > >>> Subject: RE: [mobile-ip] Heterogeneous Handover - How Would it Work? > > >>> > > >>> > > >>> ...not forgetting cdma2000. I am not aware of any work in > > >>> 3GPP2 or IEEE, > > >>> perhaps 3GPP ? > > >>> > > >>> Pete > > >>> > > >>> -----Original Message----- > > >>> From: Brad Casemore [mailto:bcasemore@home.com] > > >>> Sent: Wednesday, August 08, 2001 11:29 AM > > >>> To: mobile-ip@sunroof.eng.sun.com > > >>> Subject: RE: [mobile-ip] Heterogeneous Handover - How Would it Work? > > >>> > > >>> > > >>> If that is the case, then WECA's WISPr is dedicated to > > >>> 802.11b roaming, > > >>> while the ETSI has assigned a group to address GPRS roaming. > > >>> Is there a > > >>> group anywhere that is looking into the technical issues > > >>> associated with > > >>> heterogeneous network roaming (such as between, theoretically, 802.11b > > >>> WLANs and GPRS)? > > >>> > > >>> Brad > > >>> > > >>> > -----Original Message----- > > >>> > From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile- > > >>> > ip@sunroof.eng.sun.com] On Behalf Of James Kempf > > >>> > Sent: Wednesday, August 08, 2001 2:19 AM > > >>> > To: mobile-ip@sunroof.eng.sun.com; mobile-ip@sunroof.eng.sun.com > > >>> > Subject: Re: [mobile-ip] Heterogeneous Handover - How Would it Work? > > >>> > > > >>> > Pat, > > >>> > > > >>> > I think they already have such a standard and I believe it > > >>> only works > > >>> > with GPRS. > > >>> > > > >>> > jak > > >>> > > > >>> > >Also, I believe that ETSI is working on a standard called GRX for > > >>> GSM<- > > >>> > >802.11 > > >>> > >roaming. > > >>> > > > > >>> > >PatC > > >>> > >On Tue, Aug 07, 2001 at 09:32:58AM -0700, Dahl, Peter wrote: > > >>> > >> FYI, the Wireless ISPs (WISPs) are already talking about such > > >>> roaming > > >>> > >> issues. > > >>> > >> > > >>> > >> There appear to be 2 emerging forums for these discussions, one > > >>> under > > >>> > the > > >>> > >> auspices of WECA (http://www.weca.net) known as the WISPr group > > >>> ('r' > > >>> > being > > >>> > >> for roaming), the other a yet to be finalized 'WISP Forum' the > > >>> prime > > >>> > mover > > >>> > >> for which is a company in Luxembourg (www.excilan.com). > > >>> > >> > > >>> > >> Regards > > >>> > >> > > >>> > >> -----Original Message----- > > >>> > >> From: James Kempf [mailto:James.Kempf@Sun.COM] > > >>> > >> Sent: Tuesday, August 07, 2001 8:58 AM > > >>> > >> To: mobile-ip@sunroof.eng.sun.com; mobile-ip@sunroof.eng.sun.com > > >>> > >> Subject: Re: [mobile-ip] Heterogeneous Handover - How Would it > > >>> Work? > > >>> > >> > > >>> > >> > > >>> > >> >On the other hand, the home address must belong to some > > >>> ISP/operator. > > >>> > >> >That ISP must provide a home agent and an ip address, and a CoA > > >>> when > > >>> > the > > >>> > >> >MN is connected to other than the home subnet. Other > > >>> ISPs that are > > >>> > used > > >>> > >> >are only access providers, and would give the MN its > > >>> CoA. This of > > >>> > course > > >>> > >> >would cause political problems. Who are the ISPs that > > >>> are willing > > >>> to > > >>> > be > > >>> > >> >access providers only, and who will be providing home agent and > > >>> home > > >>> > >> >address as well? > > >>> > >> > > > >>> > >> > > >>> > >> This is an issue. What happens if you have one access provider on > > >>> > >> one interface, say the wCDMA interface, and another on > > >>> another, say > > >>> > 802.11? > > >>> > >> There are now in the US a growing number of 802.11 access > > >>> providers, > > >>> > >> and I can imagine someone with a laptop having a wCDMA modem and > > >>> > >> an 802.11 card. > > >>> > >> > > >>> > >> Maybe something like the "roaming consortia" that have sprung up > > >>> > >> around ISP access might evolve, but the protocol > > >>> design/engineering > > >>> > >> issue is whether there is any additional work (such as the NAI in > > >>> > >> the roaming consortia example) needed to enable sharing of a home > > >>> > >> address among interfaces for which different ISPs are > > >>> responsible. > > >>> > >> > > >>> > >> Something like SUCV, that would allow an ISP to cryptographically > > >>> > identify > > >>> > >> to what other ISP an address belonged, might be useful in this > > >>> context. > > >>> > >> > > >>> > >> jak > > >>> > > > From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 14 11:23:23 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07126 for ; Tue, 14 Aug 2001 11:23:23 -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 IAA03357; Tue, 14 Aug 2001 08:24: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 IAA10262; Tue, 14 Aug 2001 08:22:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7EFLn008767 for mobile-ip-dist; Tue, 14 Aug 2001 08:21:49 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7EFLjD08760 for ; Tue, 14 Aug 2001 08:21:45 -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 IAA24747 for ; Tue, 14 Aug 2001 08:21:46 -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 IAA07751 for ; Tue, 14 Aug 2001 08:21:46 -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 f7EFJsD26262 for ; Tue, 14 Aug 2001 08:19:55 -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 ACP19270; Tue, 14 Aug 2001 08:21:44 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA17501; Tue, 14 Aug 2001 08:21:44 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15225.16903.921640.449759@thomasm-u1.cisco.com> Date: Tue, 14 Aug 2001 08:21:43 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] About authorization and security policies In-Reply-To: <200108140252.f7E2qLn00537@dharkins@lounge.orgatty.lounge.org> References: <3B712FBB.607E428B@nomadiclab.com> <200108140252.f7E2qLn00537@dharkins@lounge.orgatty.lounge.org> 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 Dan Harkins writes: > On Wed, 08 Aug 2001 13:25:31 BST you wrote > > > > Case C. IKE and -14 authentication > > > > If we want to use IKE with -14 authentication, we basically need > > a new DOI (or extension to the Internet DOI), specifying how > > authentication data for -14 BU authentication is created. > > Why? The DOI does not specify how authentication data is created. > That is done in AH (2402) or ESP (2406) RFC. Are you implying that if I wanted to use the current IPsec DOI to key, oh say, SNMPV3 USM entries that would be OK with IKE as-is? If nothing else, how would the quick mode exchange know which to stuff the keying material in? Mike From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 14 11:46:03 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07641 for ; Tue, 14 Aug 2001 11:46:03 -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 IAA14568; Tue, 14 Aug 2001 08: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 IAA13967; Tue, 14 Aug 2001 08:46:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7EFiWb08903 for mobile-ip-dist; Tue, 14 Aug 2001 08:44:32 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7EFiSD08896 for ; Tue, 14 Aug 2001 08:44:28 -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 IAA06974 for ; Tue, 14 Aug 2001 08:44:29 -0700 (PDT) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA26167 for ; Tue, 14 Aug 2001 09:44:40 -0600 (MDT) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id IAA18236 for ; Tue, 14 Aug 2001 08:44:27 -0700 (MST)] Received: [from test9.crm.mot.com (zfr24-sr2-04.corp.mot.com [140.101.145.4]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id IAA12916 for ; Tue, 14 Aug 2001 08:44:24 -0700 (MST)] Received: from test9.crm.mot.com.crm.mot.com (localhost [127.0.0.1]) by test9.crm.mot.com (8.9.3/8.9.3) with ESMTP id RAA01357 for ; Tue, 14 Aug 2001 17:43:31 +0200 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile Routers support without optimization References: <3B7923D6.B231F8D3@era.ericsson.se> <3B7937A9.840171E@era.ericsson.se> From: Alexandru Petrescu Date: 14 Aug 2001 17:40:59 +0200 In-Reply-To: <3B7937A9.840171E@era.ericsson.se> 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: 40 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Alexandru Petrescu wrote: > > Is HA necessarily running a routing protocol? Is HA necessarily > > participating in route exchanges if it's not a router? I need to > > understand this. Mattias Pettersson writes: > As I see it, HA is a router since it forwards traffic that is not > destined to itself. HA indeed "forwards" traffic but not at IP level, thus it's not a router. HA builds tunnells to its MN's, in something some call the "Mobile IP plane", different than the "IP routing plane". > Yeah, maybe. But I feel that we should try to make Mobile IPv6 with > minimal inpact on other protocols. Fair enough. But I thought we talk here Mobile Networks and not Mobile IPv6. My approach is to stay independent of the searches in the routing table. I see this as having minimal impact on other things. Or what did you mean by "other protocols"? > If HA is a standard router as well, should it have special handling of > routes to some adjacent routers (i.e. MRs)? What if the MR is at home - > should it now exchange routing info with the HA as a normal router would > do? HA _software_ could run on the same machine that runs routing _software_ but I think the two should be as independent as possible. The question you pose above being related to routing software it should have no impact on HA. You stated previously you wish minimal impact on other protocols. I understand this as "don't modify routing protocols" and "least modify Mobile IP". Alex From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 14 11:53:34 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07937 for ; Tue, 14 Aug 2001 11:53: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 IAA18066; Tue, 14 Aug 2001 08:54: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 IAA16190; Tue, 14 Aug 2001 08:54:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7EFrTx09034 for mobile-ip-dist; Tue, 14 Aug 2001 08:53:29 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7EFrQD09027 for ; Tue, 14 Aug 2001 08:53: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 IAA01126; Tue, 14 Aug 2001 08:53:26 -0700 (PDT) Message-Id: <200108141553.IAA01126@heliopolis.eng.sun.com> Date: Tue, 14 Aug 2001 08:53:19 -0700 (PDT) From: James Kempf Subject: Re: [mobile-ip] Mobile Routers support without optimization To: Erik.Nordmark@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: wyYE2q3K/ip9RWAIRelIMQ== 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: >Regarding your first proposal to have MR adjacent to all routers on the >home link when it is home, and then make it reachable behind the HA when >not at home: how fast can routing protocols reflect this change? If the >other routers are not updated quickly when the MR moves away, they will >keep sending packets to MR's link-local address (according to routing >protocol). The HA has sent proxy NA for MR's link-local address, and the >packets will end up at the HA, which will tunnel them to the MR. This >way will work. > What does a MR being "at home" mean? A router typically bridges subnets and so it is not entirely obvious to me what it means for a MR to have a home agent nor what the router's home subnet would be. One could I suppose take the outward interface (if the subnet behind the MR is a leaf) and assign a home address to that, but then where is the HA? A router is more identified by the prefix of the subnet behind the router than by an address. This is, of course, the simplest case. If there were multiple outgoing interfaces on the router, or multiple subnets behind the router, including perhaps another router that connected into the fixed network, things get much more complicated. jak From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 14 13:00:55 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10288 for ; Tue, 14 Aug 2001 13:00: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 LAA29340; Tue, 14 Aug 2001 11:01: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 KAA01615; Tue, 14 Aug 2001 10:01:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7EH0Rx09352 for mobile-ip-dist; Tue, 14 Aug 2001 10:00:27 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7EH0ND09345 for ; Tue, 14 Aug 2001 10:00:23 -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 KAA22726 for ; Tue, 14 Aug 2001 10:00:25 -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 LAA27756 for ; Tue, 14 Aug 2001 11:00: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 KAA16155 for ; Tue, 14 Aug 2001 10:00:23 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f7EH0Nb12583 for ; Tue, 14 Aug 2001 10:00:23 -0700 X-mProtect: Tue, 14 Aug 2001 10:00:23 -0700 Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (172.21.40.163, claiming to be "Kniveton.com") by darkstar.iprg.nokia.com(P1.5 smtpdYMUnbm; Tue, 14 Aug 2001 10:00:21 PDT Message-ID: <3B795919.22A75AA0@Kniveton.com> Date: Tue, 14 Aug 2001 20:00:09 +0300 From: "T.J. Kniveton" Organization: NOKIA Research X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Mobile Router conversation 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, I am really glad to see so much conversation in the Mobile Router thread. It is clear that there is a lot of interest in this topic, and the problem is understood, though the problem scope needs more definition. This week I am at our office in Helsinki, where it is very difficult for me to read or send messages from this address, and for the next three weeks I'll be on vacation. So I will not be able to participate until I return to the US in a month, at which point I'm hoping the problem will already be solved. (Just kidding) One question I would like to pose, is the best way to address this issue going forward, and I would appreciate comments from the WG chairs and ADs as well. There has already been draft activity and discussion of this issue in the WG meetings, and I heard Phil R. say at IETF51 that although the WG title specifically mentions mobile HOSTS, mobile networks are not excluded from the charter per se. So what is the best way to tackle this? Continue status quo? Design team? BOF? .....? Talk to you all in September... -TJ From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 14 13:03:13 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10432 for ; Tue, 14 Aug 2001 13:03: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 KAA23902; Tue, 14 Aug 2001 10:04:01 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA01280; Tue, 14 Aug 2001 10:00:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7EGxAI09334 for mobile-ip-dist; Tue, 14 Aug 2001 09:59:10 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7EGx6D09327 for ; Tue, 14 Aug 2001 09:59: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 JAA03395 for ; Tue, 14 Aug 2001 09:59:08 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA13589 for ; Tue, 14 Aug 2001 10:59:18 -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 f7EGx4834020; Tue, 14 Aug 2001 18:59:04 +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 SAA14024; Tue, 14 Aug 2001 18:59:03 +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 f7EGx3u13402; Tue, 14 Aug 2001 18:59:03 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200108141659.f7EGx3u13402@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com cc: pekka.nikander@nomadiclab.com Subject: Re: [mobile-ip] About authorization and security policies In-reply-to: Your message of Fri, 10 Aug 2001 11:36:26 +0200. Date: Tue, 14 Aug 2001 18:59:03 +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 hope this helps to clarify the situation. => as we are not beginning from scratch, I'd like to add some comments about IKE. There are three important peer properties for IKE in this context: - the IPv6 address used for IKE exchanges - the phase one identity which can be an address or a name or other thing - the phase two identity which is not an identity but the peer address of the SA pair. The only restriction on the first (transport) address is the transport must work, so with a common correspondent both the home and the care-of addresses are right (with a lot of pros/cons) but with the home agent for the (first?) home registration from visit only the care-of address works. This last point gives a MUST in I-D 14 but in fact the MUST should not be for all cases (cf previous threads in this list about it). The phase one identity is very important because this gives th authentication. There is a special complexity with shared secrets so I assume X.509 certificates are used (and a PKI is available). The subjectName or an alternate subjectName of a valid certificate must match the identity (or certicates are not useful, cf a thread in IPsec list if this is not obvious). If the identity is an address most implementation checks it against the transport address. The phase two identity (i.e. the SA source address selector) must be the home address because of the home address option processing rules and because a new SA pair per hand-off (the rationale for the rules) would be too expensive. If the identities between the two phases are different then there is an authorization constraint. IKE documents don't explain how to express this authorization, nor implementation examination... There is only one case where a good solution (i.e. something which already runs) is the home agent which already knows all the potential mobile nodes. I can resume choices: - care-of for transport, phase one address identity => doesn't work - care-of for transport, phase one name identity => authorization issue - home for transport => works but not for home registration In case A (IKE and AH/ESP) I think one way of getting the authorization is to have the SA be created between the home address and the correspondent. Thus in this case the routability to the home address can be used implicitly by IKE in the key exchange. => this is the simple solution but there is an important exception... Thus as long as there is a way for iked to tell IP to ignore the binding cache when sending the IKE packets this should fall out pretty easy unless I'm confused. (Of course, my confusion increases assympotically during the IETF week :-) => throw away this binding cache consideration... Such an approach would mean that you would need to do something different with respect to IKE for the MN to HA exchanges since in that case you can't rely on the HA reaching the MN as a way to establish authorization. => the MN to HA is special but we can assume many things too! Thus in this case you want to associate a something (shared secret, certificate) with the authority to "be" a certain MN. But this is a local issue contained within the HA as far as I can tell. => any local ad hoc mechanism works. The only trouble with IKE in this (MN-HA) case is with IKE performance (cf proposals to use AAA in an opportunistic way, KINK or HIP will be great too). Regards Francis.Dupont@enst-bretagne.fr PS: two other ideas (results of authentication/authorization brain storming): - a "home address" identity - lookups for key or cert RRs in the DNSSEC reverse (i.e. ip6.arpa) map. From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 14 13: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 ESMTP id NAA11332 for ; Tue, 14 Aug 2001 13:38:46 -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 KAA12586; Tue, 14 Aug 2001 10:39: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 KAA24498; Tue, 14 Aug 2001 10:39:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7EHcEN09704 for mobile-ip-dist; Tue, 14 Aug 2001 10:38: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+Sun/8.11.5) with ESMTP id f7EHcAD09697 for ; Tue, 14 Aug 2001 10:38: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 KAA06390 for ; Tue, 14 Aug 2001 10:38:12 -0700 (PDT) Message-Id: <200108141738.KAA06390@heliopolis.eng.sun.com> Date: Tue, 14 Aug 2001 10:38:05 -0700 (PDT) From: James Kempf Subject: Re: [mobile-ip] Mobile Router conversation To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 2m8jamVc4CAzOajoFUve1g== 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: TJ, Thanx for bringing this up. IMHO, the MIP group should concentrate on MIP for hosts. There are enough problems there to keep the group busy, and more will emerge as MIP begins to see wider deployment (example: the NAT/VPN discussion at IETF 51). While I can't claim to have studied the problem in much detail, I wonder if perhaps we shouldn't return to first principles when trying to solve the mobile router problem, rather than trying to shoehorn the solution into a MIP framework. We could probably come up with a solution within the MIP framework for a limited class of mobile networks, but we may regret adopting the solution later when people try to modify it for more complex cases and it doesn't work. That said, I can understand completely the desire to try to come up with a solution within the MIP framework, especially for cases such as a PAN, since they look like they may be coming along sooner than expected. jak >X-Delivered-For: >X-mProtect: Tue, 14 Aug 2001 10:00:23 -0700 Nokia Silicon Valley Messaging Protection >Date: Tue, 14 Aug 2001 20:00:09 +0300 >From: "T.J. Kniveton" >To: mobile-ip@sunroof.eng.sun.com >Subject: [mobile-ip] Mobile Router conversation > >Hi folks, >I am really glad to see so much conversation in the Mobile Router >thread. It is clear that there is a lot of interest in this topic, and >the problem is understood, though the problem scope needs more >definition. > >This week I am at our office in Helsinki, where it is very difficult for >me to read or send messages from this address, and for the next three >weeks I'll be on vacation. So I will not be able to participate until I >return to the US in a month, at which point I'm hoping the problem will >already be solved. (Just kidding) > >One question I would like to pose, is the best way to address this issue >going forward, and I would appreciate comments from the WG chairs and >ADs as well. There has already been draft activity and discussion of >this issue in the WG meetings, and I heard Phil R. say at IETF51 that >although the WG title specifically mentions mobile HOSTS, mobile >networks are not excluded from the charter per se. So what is the best >way to tackle this? Continue status quo? Design team? BOF? .....? > >Talk to you all in September... >-TJ > From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 14 13:51:56 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11650 for ; Tue, 14 Aug 2001 13:51: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 LAA13844; Tue, 14 Aug 2001 11:52: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 KAA13515; Tue, 14 Aug 2001 10:52:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7EHpg809814 for mobile-ip-dist; Tue, 14 Aug 2001 10:51:42 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7EHpcD09807 for ; Tue, 14 Aug 2001 10:51: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 KAA27991 for ; Tue, 14 Aug 2001 10:51:41 -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 KAA23965 for ; Tue, 14 Aug 2001 10:51:40 -0700 (PDT) Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.24.14]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f7EHpGn09116; Tue, 14 Aug 2001 10:51:16 -0700 (PDT) Received: from cisco.com (alpesh-u5.cisco.com [128.107.162.126]) by mira-sjcm-2.cisco.com (Mirapoint) with ESMTP id AHU11230 (AUTH alpesh); Tue, 14 Aug 2001 10:51:03 -0700 (PDT) Message-ID: <3B796506.94333304@cisco.com> Date: Tue, 14 Aug 2001 10:51:02 -0700 From: Alpesh Patel X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com CC: "Madhavi W. Chandra" , "Charles E. Perkins" , Pat Calhoun , "Kent K. Leung" Subject: [mobile-ip] Re: Basavaraj.Patil@nokia.com: RE: mobile-ip] Re: mobile-ip] RFC2002bis] References: <20010718115752.A689@cisco.com> <3B61D37F.A75CF9B4@iprg.nokia.com> <20010731143810.B5836@cisco.com> <20010731120312.D6031@charizard.diameter.org> <3B69855D.4F20AB2B@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 Hi, This is about mandating HMAC-MD5 for MobileIP as per the current discussions in 2002bis. My colleagues' and my concern is that this is not backwards compatible with RFC2002. I think indicating MD5 as SHOULD is not sufficient. What if three years from now, new authentication algorithms come up. Shouldn't we have a mechanism to indicate to the Mobile Entity what algorithm to use to authenticate the peer entity? Probably by means of an extension (too costly) or just by adding a field in the authentication extension itself? I think this is a good time to do that. HMAC-MD5/MD5 as MUST/SHOULD in that order, as per me is not sufficient. I would prefer SHOULD/MUST order for HMAC-MD5/MD5 to be backwards compatible. I heard/read one argument that RFC2002 was never a draft standard and 2002bis is on that track. My argument is that RFC2002 is out for about 4/5 years now and it is obvious that there would be implementation/deployment out there. IETF is not ITU where in everyone waits till a whole reference architecture document is published on a consensus. I have no intention to trash ITU here, but am trying to make it obvious for a need to be backwards compatible to what had been agreed/recommended in 2002. Thanks -a From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 14 17:18:21 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15377 for ; Tue, 14 Aug 2001 17:18: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 OAA26931; Tue, 14 Aug 2001 14:19:17 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA11445; Tue, 14 Aug 2001 14:17:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7ELG3H10210 for mobile-ip-dist; Tue, 14 Aug 2001 14:16:03 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7ELFwD10203 for ; Tue, 14 Aug 2001 14:15: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 OAA27454 for ; Tue, 14 Aug 2001 14:15:34 -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 PAA17184 for ; Tue, 14 Aug 2001 15:15:45 -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 f7ELFgn05832; Tue, 14 Aug 2001 14:15: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 ACR01928; Tue, 14 Aug 2001 14:15:29 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA17539; Tue, 14 Aug 2001 14:15:29 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15225.38129.102203.479658@thomasm-u1.cisco.com> Date: Tue, 14 Aug 2001 14:15:29 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Cc: Alexis_Olivereau-AAO011@email.mot.com Subject: Re: [mobile-ip] Mobile Routers support without optimization In-Reply-To: References: <3B73B753.D3365C7E@crm.mot.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Erik Nordmark writes: > > Actually Binding Updates for prefixes do not disable route optimization > > feature. Clearly, the authorization process is trickier. It can however > > be performed provided that it makes use of the knowledge the HA has > > about the binding 'Mobile Prefix' / 'Mobile Router'. HA can then be > > asked by the CN before CN updates its Binding Cache upon receiption of a > > prefix BU. > > I don't understand how the CN checking with the HA solves the trust issue > for using BUs to redirect whole prefixes. > > Example: I run a MN and a HA . My MN sends a BU for a /3 to a CN > the fact that my MN says "yes" when the CN asks if the binding is ok. > > The redirection of a prefix must be related to the routing for that whole > prefix going to the HA. In general you can't verify that this is the case > for a prefix without actually sending packets to all IP addresses in the > prefix and seeing that you get a response back from the HA. In fact, it's not necessarily the HA. It's the topologically closest router to the CN which advertises that prefix. For a /3 (wow, where'd you get one of those??) that's probably going to be a core router which wants the Yea or Nay vote on that, not the HA or anything else. Another thing to consider is that the HA can be evil and in collusion with the MR. Mike > But, what problem are we really trying to solve by being able to send > a BU for a whole prefix? > This seems like optimizing something which is close to a non-problem. Er, if I could smooth the triangular routing for, say, an aircraft carrier through it's MR's home agent, that sounds like a pretty big win to me. In fact, it's arguable that the larger the prefix, the larger the motivation to optimize (hence renumbering too.) Mike From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 15 08: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 ESMTP id IAA16569 for ; Wed, 15 Aug 2001 08:35:33 -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 FAA02691; Wed, 15 Aug 2001 05:36: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 FAA23198; Wed, 15 Aug 2001 05:33:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7FCWLv12588 for mobile-ip-dist; Wed, 15 Aug 2001 05:32:21 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7FCWHD12581 for ; Wed, 15 Aug 2001 05:32:18 -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 FAA23030 for ; Wed, 15 Aug 2001 05:32:19 -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 GAA25580 for ; Wed, 15 Aug 2001 06:32:28 -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 f7FCW8O08936 for ; Wed, 15 Aug 2001 14:32:08 +0200 (MEST) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id OAA22505; Wed, 15 Aug 2001 14:32:07 +0200 Message-ID: <3B7A6B57.70543E62@era.ericsson.se> Date: Wed, 15 Aug 2001 14:30:15 +0200 From: Mattias Pettersson Organization: Ericsson Research X-Mailer: Mozilla 4.77 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile Router conversation References: <200108141738.KAA06390@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: > > TJ, > > Thanx for bringing this up. > > IMHO, the MIP group should concentrate on MIP for hosts. There are > enough problems there to keep the group busy, and more will emerge > as MIP begins to see wider deployment (example: the NAT/VPN discussion > at IETF 51). > > While I can't claim to have studied the problem in much detail, I > wonder if perhaps we shouldn't return to first principles when > trying to solve the mobile router problem, rather than trying to > shoehorn the solution into a MIP framework. We could probably come > up with a solution within the MIP framework for a limited class of mobile > networks, but we may regret adopting the solution later when people > try to modify it for more complex cases and it doesn't work. Exactly my point too! But we should at least start with the two I-Ds that exist. Is "Prefix Scoped BU" enough as a start? Maybe, in some cases. The requirements I-D should reflect the discussions we have here. > That > said, I can understand completely the desire to try to come up > with a solution within the MIP framework, especially for cases > such as a PAN, since they look like they may be coming along sooner > than expected. > Throw in a NAT, if you want a quick solution... ;) /Mattias From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 15 11:22:37 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23542 for ; Wed, 15 Aug 2001 11:22: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 IAA00470; Wed, 15 Aug 2001 08:22: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 HAA28531; Wed, 15 Aug 2001 07:13:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7FEC5l13151 for mobile-ip-dist; Wed, 15 Aug 2001 07:12:05 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7FEC1D13144 for ; Wed, 15 Aug 2001 07:12: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 HAA03364 for ; Wed, 15 Aug 2001 07:12:01 -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 IAA12772 for ; Wed, 15 Aug 2001 08:11:59 -0600 (MDT) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f7FEBjN03049 for ; Wed, 15 Aug 2001 16:11:45 +0200 (MEST) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id QAA25559; Wed, 15 Aug 2001 16:11:44 +0200 Message-ID: <3B7A82AB.7F81FF45@era.ericsson.se> Date: Wed, 15 Aug 2001 16:09:47 +0200 From: Mattias Pettersson Organization: Ericsson Research X-Mailer: Mozilla 4.77 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile Routers support without optimization References: <3B7923D6.B231F8D3@era.ericsson.se> <3B7937A9.840171E@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 Alexandru Petrescu wrote: > > Alexandru Petrescu wrote: > > > Is HA necessarily running a routing protocol? Is HA necessarily > > > participating in route exchanges if it's not a router? I need to > > > understand this. > > Mattias Pettersson writes: > > As I see it, HA is a router since it forwards traffic that is not > > destined to itself. > > HA indeed "forwards" traffic but not at IP level, thus it's not a > router. HA builds tunnells to its MN's, in something some call the > "Mobile IP plane", different than the "IP routing plane". Ok. That's your terminology and your point of view. I explained mine. I think implementations will vary just like that. > > > Yeah, maybe. But I feel that we should try to make Mobile IPv6 with > > minimal inpact on other protocols. > > Fair enough. > > But I thought we talk here Mobile Networks and not Mobile IPv6. My > approach is to stay independent of the searches in the routing table. > I see this as having minimal impact on other things. Or what did you > mean by "other protocols"? For instance, RIP and OSPF. > > > If HA is a standard router as well, should it have special handling of > > routes to some adjacent routers (i.e. MRs)? What if the MR is at home - > > should it now exchange routing info with the HA as a normal router would > > do? > > HA _software_ could run on the same machine that runs routing > _software_ but I think the two should be as independent as possible. > The question you pose above being related to routing software it > should have no impact on HA. > > You stated previously you wish minimal impact on other protocols. I > understand this as "don't modify routing protocols" and "least modify > Mobile IP". Because if Mobile IPv6 (or Mobile Network Support) must have a protocol hack or its own proprietary for each other L3 protocol, I am getting scared. I hope we don't have to do that. Still, how should the MR function when it is at home? Then Mobile IPv6 shouldn't do anything, should it? Who would take care of routing updates then? Personally, I would like to get away from that old behaviour (that a MN at home is just like any other node) and go for more homeless mobile nodes. /Mattias From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 15 11:39:31 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23973 for ; Wed, 15 Aug 2001 11:39:31 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA06926; Wed, 15 Aug 2001 08:40: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 HAA00174; Wed, 15 Aug 2001 07:23:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7FEMMf13217 for mobile-ip-dist; Wed, 15 Aug 2001 07:22:22 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7FEMID13210 for ; Wed, 15 Aug 2001 07:22: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 HAA04345 for ; Wed, 15 Aug 2001 07:22:19 -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 HAA24597 for ; Wed, 15 Aug 2001 07:22:17 -0700 (PDT) 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 f7FEMGO12327 for ; Wed, 15 Aug 2001 16:22:16 +0200 (MEST) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id QAA26029; Wed, 15 Aug 2001 16:22:16 +0200 Message-ID: <3B7A8522.CACD34C4@era.ericsson.se> Date: Wed, 15 Aug 2001 16:20:18 +0200 From: Mattias Pettersson Organization: Ericsson Research X-Mailer: Mozilla 4.77 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile Routers support without optimization References: <200108141553.IAA01126@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: > > >Regarding your first proposal to have MR adjacent to all routers on the > >home link when it is home, and then make it reachable behind the HA when > >not at home: how fast can routing protocols reflect this change? If the > >other routers are not updated quickly when the MR moves away, they will > >keep sending packets to MR's link-local address (according to routing > >protocol). The HA has sent proxy NA for MR's link-local address, and the > >packets will end up at the HA, which will tunnel them to the MR. This > >way will work. > > > > What does a MR being "at home" mean? A router typically bridges subnets > and so it is not entirely obvious to me what it means for a MR to > have a home agent nor what the router's home subnet would be. > > One could I suppose take the outward interface (if the subnet > behind the MR is a leaf) and assign a home address to that, > but then where is the HA? A router is more identified by the > prefix of the subnet behind the router than by an address. You have a point, but I would try to stick to figures and definitions in draft-ernst-mobileip-monetv6-00.txt. I see the MR as both a an ordinary MN with one home address and a home agent, and also as an MR, which also is an MNN. /Mattias From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 15 12:46:30 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25805 for ; Wed, 15 Aug 2001 12:46: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 KAA03826; Wed, 15 Aug 2001 10:47:24 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA02908; Wed, 15 Aug 2001 07:45:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7FEifl13397 for mobile-ip-dist; Wed, 15 Aug 2001 07:44:41 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7FEibD13383 for ; Wed, 15 Aug 2001 07:44:37 -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 HAA18172 for ; Wed, 15 Aug 2001 07:44:37 -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 HAA09638 for ; Wed, 15 Aug 2001 07:44:36 -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 f7FEiZN22794 for ; Wed, 15 Aug 2001 16:44:35 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Wed Aug 15 16:44:29 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Wed, 15 Aug 2001 16:44:30 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008BB7@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Cc: Alexis_Olivereau-AAO011@email.mot.com Subject: RE: [mobile-ip] Mobile Routers support without optimization Date: Wed, 15 Aug 2001 16:44: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: > > > Actually Binding Updates for prefixes do not disable route optimization > > > feature. Clearly, the authorization process is trickier. It can however > > > be performed provided that it makes use of the knowledge the HA has > > > about the binding 'Mobile Prefix' / 'Mobile Router'. HA can then be > > > asked by the CN before CN updates its Binding Cache upon receiption of a > > > prefix BU. > > > > I don't understand how the CN checking with the HA solves the trust issue > > for using BUs to redirect whole prefixes. > > > > Example: I run a MN and a HA . My MN sends a BU for a /3 to a CN > > the fact that my MN says "yes" when the CN asks if the binding is ok. > > > > The redirection of a prefix must be related to the routing for that whole > > prefix going to the HA. In general you can't verify that this is the case > > for a prefix without actually sending packets to all IP addresses in the > > prefix and seeing that you get a response back from the HA. > > In fact, it's not necessarily the HA. It's the > topologically closest router to the CN which > advertises that prefix. For a /3 (wow, where'd you > get one of those??) that's probably going to be a > core router which wants the Yea or Nay vote on > that, not the HA or anything else. > => I think the point is that you can really redirect a LOT of traffic depnding on the length of the prefix that you choose to steal. This will probably not happen with a HA but when it comes to the MN - CN it is very difficult to get that to work. > Another thing to consider is that the HA can > be evil and in collusion with the MR. > => Yes that's the example that Erik gave above. Therefore a CN checking the authenticity of MR's BU on an entire prefix doesn't solve the problem for a prefix based BU. Hesham > > But, what problem are we really trying to solve by being able to send > > a BU for a whole prefix? > > This seems like optimizing something which is close to a non-problem. > > Er, if I could smooth the triangular routing for, > say, an aircraft carrier through it's MR's home > agent, that sounds like a pretty big win to me. > In fact, it's arguable that the larger the prefix, > the larger the motivation to optimize (hence > renumbering too.) > > Mike From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 15 14:44:19 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28931 for ; Wed, 15 Aug 2001 14:44: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 LAA02815; Wed, 15 Aug 2001 11:45: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 LAA23187; Wed, 15 Aug 2001 11:35:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7FIXwk14485 for mobile-ip-dist; Wed, 15 Aug 2001 11:33: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+Sun/8.11.5) with ESMTP id f7FIXsD14478 for ; Wed, 15 Aug 2001 11:33: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 LAA28132 for ; Wed, 15 Aug 2001 11:33:54 -0700 (PDT) Message-Id: <200108151833.LAA28132@heliopolis.eng.sun.com> Date: Wed, 15 Aug 2001 11:33:47 -0700 (PDT) From: James Kempf Subject: Re: [mobile-ip] Mobile Routers support without optimization To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 2xFSizq9/vwEPM2rQbUtTw== 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: >> >> But I thought we talk here Mobile Networks and not Mobile IPv6. My >> approach is to stay independent of the searches in the routing table. >> I see this as having minimal impact on other things. Or what did you >> mean by "other protocols"? > >For instance, RIP and OSPF. > Not to mention BGP. Should a BGP autonomous system be advertising prefixes for "care-of" subnets, i.e. subnets that get their prefixes doled out to mobile routers when they arrive, even though there may be no mobile network there yet? >Still, how should the MR function when it is at home? Then Mobile IPv6 >shouldn't do anything, should it? Who would take care of routing updates >then? > >Personally, I would like to get away from that old behaviour (that a MN >at home is just like any other node) and go for more homeless mobile >nodes. > Agree 100%! jak From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 16 02:25:49 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25167 for ; Thu, 16 Aug 2001 02:25:49 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA07350; Wed, 15 Aug 2001 23:26: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 XAA02758; Wed, 15 Aug 2001 23:26:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7G6Pd715955 for mobile-ip-dist; Wed, 15 Aug 2001 23:25:39 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7G6PaD15948 for ; Wed, 15 Aug 2001 23:25:36 -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 XAA14151 for ; Wed, 15 Aug 2001 23:25:38 -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 XAA17411 for ; Wed, 15 Aug 2001 23:25:37 -0700 (PDT) Received: from MIKAELSPC (c32.local.ipunplugged.com [192.168.4.231]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with SMTP id IAA21297; Thu, 16 Aug 2001 08:26:36 +0200 Message-ID: <006901c1261c$0e954d50$e704a8c0@MIKAELSPC> From: "Mikael Wolf" To: , Cc: Subject: [mobile-ip] MN-FA/MN-HA Key Material clarification needed Date: Thu, 16 Aug 2001 08:24:08 +0200 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.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit draft-ietf-mobileip-aaa-key-08.txt, chapter 3, specifies the algorithms to be used for producing the authentication information included in the Mobile Home Authentication extension or the Mobile Foreign Authentication extension; one of them is SHA-1 (#3). However, a hash function cannot be used as a MAC since it does not rely on a secret key (contradictory to what is stated in chapter 3). Please clarify how SHA-1 should be used provide authentication. Thanks, Mikael. From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 16 06:05:56 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27161 for ; Thu, 16 Aug 2001 06:05: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 EAA20479; Thu, 16 Aug 2001 04:06: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 DAA00449; Thu, 16 Aug 2001 03:06:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7GA5H716394 for mobile-ip-dist; Thu, 16 Aug 2001 03:05:17 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7GA5DD16387 for ; Thu, 16 Aug 2001 03:05:14 -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 DAA01228 for ; Thu, 16 Aug 2001 03:05:16 -0700 (PDT) Received: from mailweb32.rediffmail.com ([203.199.83.152]) by venus.sun.com (8.9.3+Sun/8.9.3) with SMTP id DAA23913 for ; Thu, 16 Aug 2001 03:05:15 -0700 (PDT) Received: (qmail 11012 invoked by uid 510); 16 Aug 2001 10:05:39 -0000 Date: 16 Aug 2001 10:05:39 -0000 Message-ID: <20010816100539.11011.qmail@mailweb32.rediffmail.com> Received: from unknown (202.9.170.10) by rediffmail.com via HTTP; 16 Aug 2001 10:05:39 -0000 MIME-Version: 1.0 To: Subject: Re: [mobile-ip] MN-FA/MN-HA Key Material clarification needed From: "Tony lance" Content-ID: Content-type: text/plain Content-Description: Body Content-Transfer-Encoding: quoted-printable Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: quoted-printable Hi , The draft on Route Optimization in Mobile IP i.e. draft-ietf-mobileip-optim-10.txt was supposed to expire by 15 Ma= y 2001.Can I know,is there any rfc based on this draft?.Can we consider t= his draft as a valid one? Thank u (Tony) = From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 16 06:56:05 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27788 for ; Thu, 16 Aug 2001 06:56: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 EAA14656; Thu, 16 Aug 2001 04:57:01 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA04335; Thu, 16 Aug 2001 03:56:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7GAtpa16608 for mobile-ip-dist; Thu, 16 Aug 2001 03:55:51 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7GAtmD16601 for ; Thu, 16 Aug 2001 03:55:48 -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 DAA26638 for ; Thu, 16 Aug 2001 03:55:50 -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 EAA14042 for ; Thu, 16 Aug 2001 04:55:47 -0600 (MDT) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate2.mot.com (motgate2 2.1) with ESMTP id DAA10387 for ; Thu, 16 Aug 2001 03:55:49 -0700 (MST)] Received: [from m-il06-r1.mot.com (m-il06-r1.mot.com [129.188.137.193]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id DAA11975 for ; Thu, 16 Aug 2001 03:47:56 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r1.mot.com with ESMTP for mobile-ip@sunroof.eng.sun.com; Thu, 16 Aug 2001 05:55:47 -0500 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 894F32ECAC for ; Thu, 16 Aug 2001 12:55:18 +0200 (CEST) To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile Routers support without optimization References: <3B7923D6.B231F8D3@era.ericsson.se> <3B7937A9.840171E@era.ericsson.se> <3B7A82AB.7F81FF45@era.ericsson.se> From: Alexandru Petrescu Date: 16 Aug 2001 12:55:45 +0200 In-Reply-To: <3B7A82AB.7F81FF45@era.ericsson.se> Message-Id: Lines: 67 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: Mattias Pettersson writes: > > Mattias Pettersson writes: > > > As I see it, HA is a router since it forwards traffic that is not > > > destined to itself. > > > > HA indeed "forwards" traffic but not at IP level, thus it's not a > > router. HA builds tunnells to its MN's, in something some call the > > "Mobile IP plane", different than the "IP routing plane". > > Ok. That's your terminology and your point of view. I explained mine. I > think implementations will vary just like that. You're absolutely right. Sorry for making too much of a strong statement, it's indeed my humble way of seeing things. > > But I thought we talk here Mobile Networks and not Mobile IPv6. My > > approach is to stay independent of the searches in the routing table. > > I see this as having minimal impact on other things. Or what did you > > mean by "other protocols"? > > For instance, RIP and OSPF. I asked also, why not RIP or OSPF? Several reasons, _IMHO_. Same scalability issues that applied when designing Mobile IP will apply to Mobile Networks. How fast routes get updated? How many routes change at how many routers? Also, in my understanding, off-the-shelf RIP would not suffice, one needs Triggered RIP. Also, RIP's bad news don't propagate quickly, so don't rely on it to tell CN's that MR's are no longer there. I completely agree that one could look into routing protocols when designing a mobile networks solution, but what would be the goal? Proper setting of RIP/OSPF? Or a modification of RIP/OSPF? > > You stated previously you wish minimal impact on other protocols. I > > understand this as "don't modify routing protocols" and "least modify > > Mobile IP". > > Because if Mobile IPv6 (or Mobile Network Support) must have a > protocol hack or its own proprietary for each other L3 protocol, I > am getting scared. I hope we don't have to do that. This is what I believe too. This is why I'm also proposing not to tightly couple searches into binding cache with searches into routing table. > Still, how should the MR function when it is at home? Then Mobile > IPv6 shouldn't do anything, should it? Who would take care of > routing updates then? The questions are very valid, IMHO. Regarding the last question only, why would a router of a small PAN have to deal with routing updates? I was thinking it could only have one (or a few) static routes to its subnet and a default route towards the AR (this would be discovered with ND, no routing updates). > Personally, I would like to get away from that old behaviour (that a > MN at home is just like any other node) and go for more homeless > mobile nodes. Wasn't there a draft "homeless Mobile IP" somewhere? Alex PS: I start to think that I would have liked to see the short lived -14 to advance and not get trimmed of those prefix sections. From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 16 07:03:26 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28320 for ; Thu, 16 Aug 2001 07:03: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 FAA17990; Thu, 16 Aug 2001 05:03: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 EAA04856; Thu, 16 Aug 2001 04:03:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7GB2wZ16728 for mobile-ip-dist; Thu, 16 Aug 2001 04:02:58 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7GB2sD16721 for ; Thu, 16 Aug 2001 04:02: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 EAA04122 for ; Thu, 16 Aug 2001 04:02:56 -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 EAA08325 for ; Thu, 16 Aug 2001 04:02:56 -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 HAA28056; Thu, 16 Aug 2001 07:01:42 -0400 (EDT) Message-Id: <200108161101.HAA28056@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-jacobs-mobileip-pki-auth-03.txt Date: Thu, 16 Aug 2001 07:01: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. Title : Mobile IP Public Key Based Authentication Author(s) : S. Jacobs, S. Belgard Filename : draft-jacobs-mobileip-pki-auth-03.txt Pages : 31 Date : 15-Aug-01 This document proposes an extension to the Mobile IP base protocol (RFC 2002) to allow Mobile Nodes (Hosts) and Mobility Agents (both home network and foreign network) to use X.509 digital certificates, public keys and digital signatures as the basis of authenticating Mobile IP control messages in addition to secret key authentication. The use of these mechanisms will allow Mobile IP to scale from small research environments to potentially millions of mobile nodes across thousands of networks owned-operated by different organizations and service providers. A Public Key Infrastructure is proposed that focuses specifically on authentication of Mobile IP knowledgeable nodes, NOT general use for authenticating individuals. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-jacobs-mobileip-pki-auth-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-jacobs-mobileip-pki-auth-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-jacobs-mobileip-pki-auth-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. --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: <20010815145024.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-jacobs-mobileip-pki-auth-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-jacobs-mobileip-pki-auth-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010815145024.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 16 07:31:24 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29044 for ; Thu, 16 Aug 2001 07:31: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 EAA18423; Thu, 16 Aug 2001 04:32: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 EAA06739; Thu, 16 Aug 2001 04:32:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7GBV4516927 for mobile-ip-dist; Thu, 16 Aug 2001 04:31:04 -0700 (PDT) Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.179.15]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7GBUxD16920 for ; Thu, 16 Aug 2001 04:31:00 -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 f7GBUq217025; Thu, 16 Aug 2001 13:30:52 +0200 (MET DST) Date: Thu, 16 Aug 2001 13:28:02 +0200 (CEST) From: Erik Nordmark Subject: Re: [mobile-ip] Mobile Routers support without optimization To: James Kempf Cc: Erik.Nordmark@eng.sun.com, mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <200108141553.IAA01126@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: > What does a MR being "at home" mean? A router typically bridges subnets > and so it is not entirely obvious to me what it means for a MR to > have a home agent nor what the router's home subnet would be. Depending on approach to the problem people might come up with different definitions. In the PAN case (and perhaps other scenarios) it probably makes sense to define the "home link" as the link where the routers live that the MR has routing adjacencies. Essentially those routers at home trust the MR to announce routes for at least its mobile subnet. In order for the MR to tell those routers at home its current location the MR need some identity. I think the home address could be such an identity. Erik From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 16 07:34:33 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29145 for ; Thu, 16 Aug 2001 07:34: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 FAA03724; Thu, 16 Aug 2001 05:35: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 EAA07097; Thu, 16 Aug 2001 04:35:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7GBYUB17025 for mobile-ip-dist; Thu, 16 Aug 2001 04:34:30 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7GBYQD17018 for ; Thu, 16 Aug 2001 04:34:26 -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 EAA29113 for ; Thu, 16 Aug 2001 04:34:29 -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 FAA08840 for ; Thu, 16 Aug 2001 05:34:41 -0600 (MDT) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f7GBYQN03050 for ; Thu, 16 Aug 2001 13:34:26 +0200 (MEST) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id NAA24881; Thu, 16 Aug 2001 13:34:26 +0200 Message-ID: <3B7BAF3D.27B4C11C@era.ericsson.se> Date: Thu, 16 Aug 2001 13:32:13 +0200 From: Mattias Pettersson Organization: Ericsson Research X-Mailer: Mozilla 4.77 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile Routers support without optimization References: <3B7923D6.B231F8D3@era.ericsson.se> <3B7937A9.840171E@era.ericsson.se> <3B7A82AB.7F81FF45@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 Alexandru Petrescu wrote: > > > > But I thought we talk here Mobile Networks and not Mobile IPv6. My > > > approach is to stay independent of the searches in the routing table. > > > I see this as having minimal impact on other things. Or what did you > > > mean by "other protocols"? > > > > For instance, RIP and OSPF. > > I asked also, why not RIP or OSPF? Several reasons, _IMHO_. Same > scalability issues that applied when designing Mobile IP will apply to > Mobile Networks. How fast routes get updated? How many routes change > at how many routers? Also, in my understanding, off-the-shelf RIP > would not suffice, one needs Triggered RIP. Also, RIP's bad news > don't propagate quickly, so don't rely on it to tell CN's that MR's > are no longer there. Sorry, I can't see what CN this would affect. Also, your argument is an indicator to that Mobile IPv6 should hide the fact that the MR is moving. In other words, not show that to RIP. Erik talked about tunnelling between the MR and HA, also when the MR is home. > > I completely agree that one could look into routing protocols when > designing a mobile networks solution, but what would be the goal? > Proper setting of RIP/OSPF? Or a modification of RIP/OSPF? > > > > You stated previously you wish minimal impact on other protocols. I > > > understand this as "don't modify routing protocols" and "least modify > > > Mobile IP". > > > > Because if Mobile IPv6 (or Mobile Network Support) must have a > > protocol hack or its own proprietary for each other L3 protocol, I > > am getting scared. I hope we don't have to do that. > > This is what I believe too. This is why I'm also proposing not to > tightly couple searches into binding cache with searches into routing > table. Ok. You want the same thing, only we see different problems here. > > > Still, how should the MR function when it is at home? Then Mobile > > IPv6 shouldn't do anything, should it? Who would take care of > > routing updates then? > > The questions are very valid, IMHO. > > Regarding the last question only, why would a router of a small PAN > have to deal with routing updates? I was thinking it could only have > one (or a few) static routes to its subnet and a default route towards > the AR (this would be discovered with ND, no routing updates). Outbound traffic from the MR's subnet is more of default route type. But still, a router should not be listening to RAs (or a router enabled interface). Or have I got this all wrong? Anyway, inbound traffic to the MR's subnet is more problematic. You suggest static routes. In some cases this is ok, I suppose. But an ISP with a lot of MRs would likely prefer some automation here. A new protocol? > > > Personally, I would like to get away from that old behaviour (that a > > MN at home is just like any other node) and go for more homeless > > mobile nodes. > > Wasn't there a draft "homeless Mobile IP" somewhere? Yes, draft-nikander-mobileip-homelessv6-01.txt. /Mattias From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 16 08:25:20 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01936 for ; Thu, 16 Aug 2001 08:25: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 GAA00615; Thu, 16 Aug 2001 06:26:15 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA11887; Thu, 16 Aug 2001 05:26:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7GCP6717267 for mobile-ip-dist; Thu, 16 Aug 2001 05:25:06 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7GCP2D17260 for ; Thu, 16 Aug 2001 05:25: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 FAA09832 for ; Thu, 16 Aug 2001 05:25:06 -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 FAA01964 for ; Thu, 16 Aug 2001 05:25:05 -0700 (PDT) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate.mot.com (motgate 2.1) with ESMTP id FAA01258 for ; Thu, 16 Aug 2001 05:25:00 -0700 (MST)] Received: [from m-il06-r4.mot.com (m-il06-r4.mot.com [129.188.137.196]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id FAA17836 for ; Thu, 16 Aug 2001 05:25:00 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r4.mot.com with ESMTP for mobile-ip@sunroof.eng.sun.com; Thu, 16 Aug 2001 07:24:59 -0500 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id E5F522ECAC for ; Thu, 16 Aug 2001 14:24:29 +0200 (CEST) To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Comments on draft-team-mobileip-mipv6-sec-reqts-00.txt From: Alexandru Petrescu Date: 16 Aug 2001 14:24:56 +0200 Message-Id: Lines: 53 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 have further comments on this draft that I believe have not yet been mentioned. -the table in section 6 has threat B.4 but it is not described anywhere in the body. -I propose addition of a DoS attack realized by sending fake Binding Acknowledgments (this is also mentioned in draft-roe-mobileip-updateauth-00.txt): Threat B.5: By being able to passively monitor the traffic, the attacker could learn about the CNs that the MN is communicating with and also determine to which CNs the MN is sending BUs. The attacker could thus synchronize with the MN such that when MN sends a BU to CN then attacker replies to MN with a fake Binding Acknowledgment with a Status field different than 0. Effect B.5: This will cause the MN to resend a new Binding Update (subject to rate limiting of sending BU's) to CN's. Depending on timing and synchronization, this could result on a DoS or low-grade service: the communication between MN and CN can be shut off or it can follow an unoptimized triangular route. Requirement B.5: I don't know. Probably the mentionned draft has a good idea in this respect. -in section 5 Classification of Attackers, after reading the first three lines I'm tempted to understand "link" as a "subnet". But then, a "link" between CN an HA tends to be interpreted more as a large portion of Internet, including CN's and HA' subnets. Thus I propose a finer distinction, for example replace: "- an attacker on the link between the CN and the HA - an attacker on the link between the MN and the CN" with: "- an attacker on the path between the CN and the HA (except CN's and HA's links) - an attacker on the path link between the MN and the CN (except CN's and MN's links)" Thank you for reading these comments, Alex From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 16 09:17:03 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04782 for ; Thu, 16 Aug 2001 09:17:02 -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 GAA16761; Thu, 16 Aug 2001 06:18: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 GAA08863; Thu, 16 Aug 2001 06:17:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7GDF2817419 for mobile-ip-dist; Thu, 16 Aug 2001 06:15:02 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7GDEwD17412 for ; Thu, 16 Aug 2001 06:14: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 GAA04556 for ; Thu, 16 Aug 2001 06:15:02 -0700 (PDT) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA19025 for ; Thu, 16 Aug 2001 06:15:02 -0700 (PDT) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id GAA20763 for ; Thu, 16 Aug 2001 06:15:01 -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 GAA08519 for ; Thu, 16 Aug 2001 06:07:08 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r4.mot.com with ESMTP for mobile-ip@sunroof.eng.sun.com; Thu, 16 Aug 2001 08:15:00 -0500 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id B893C2ECAC for ; Thu, 16 Aug 2001 15:14:30 +0200 (CEST) To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile Routers support without optimization References: <3B7923D6.B231F8D3@era.ericsson.se> <3B7937A9.840171E@era.ericsson.se> <3B7A82AB.7F81FF45@era.ericsson.se> <3B7BAF3D.27B4C11C@era.ericsson.se> From: Alexandru Petrescu Date: 16 Aug 2001 15:14:58 +0200 In-Reply-To: <3B7BAF3D.27B4C11C@era.ericsson.se> Message-Id: Lines: 47 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: Mattias Pettersson writes: > > I asked also, why not RIP or OSPF? Several reasons, _IMHO_. Same > > scalability issues that applied when designing Mobile IP will apply to > > Mobile Networks. How fast routes get updated? How many routes change > > at how many routers? Also, in my understanding, off-the-shelf RIP > > would not suffice, one needs Triggered RIP. Also, RIP's bad news > > don't propagate quickly, so don't rely on it to tell CN's that MR's > > are no longer there. > > Sorry, I can't see what CN this would affect. Right, I meant CN's TCP will retransmit because MN unreachable. > Also, your argument is an indicator to that Mobile IPv6 should hide > the fact that the MR is moving. In other words, not show that to > RIP. Right, kind of. I think a solution can be designed where tunnelling is used between HA and MR-not-at-home (without tunnelling route adjacency, looks complex) and routing is used only between HA and MR-at-home. > Erik talked about tunnelling between the MR and HA, also when the MR > is home. YEs, I reread his messages. Thanks for pointing it out. > Outbound traffic from the MR's subnet is more of default route > type. But still, a router should not be listening to RAs (or a > router enabled interface). Or have I got this all wrong? Oops, _I_ might have it all wrong. Shame. So how do MR's get a CoA? > Anyway, inbound traffic to the MR's subnet is more problematic. You > suggest static routes. In some cases this is ok, I suppose. But an > ISP with a lot of MRs would likely prefer some automation here. A > new protocol? You enlarge the _number of MR's_, I was saying that the _number of hosts_ in a PAN is small and thus MR has probably only a very few prefixes (read 1) it knows to route. But I'll go back read that route adjacency thread. Alex From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 16 09:56:21 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07208 for ; Thu, 16 Aug 2001 09:56: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 GAA02943; Thu, 16 Aug 2001 06:57:19 -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 GAA16267; Thu, 16 Aug 2001 06:56:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7GDtA917730 for mobile-ip-dist; Thu, 16 Aug 2001 06:55:10 -0700 (PDT) Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.179.15]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7GDt1D17723 for ; Thu, 16 Aug 2001 06:55:01 -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 f7GDst228463; Thu, 16 Aug 2001 15:54:55 +0200 (MET DST) Date: Thu, 16 Aug 2001 15:52:08 +0200 (CEST) From: Erik Nordmark Subject: Re: [mobile-ip] Mobile Routers support without optimization To: Thierry Ernst Cc: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3B791AEB.655F8118@inrialpes.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > I think my note had "basic" in there :-) > By basic, you mean "no routing optimization". I advocate that providing > routing optimization is a requirement. You also demonstrate a need to > support VMNs; at the same time this also highlights an even more > important need for routing optimization. Thierry, By "basic" I meant to imply that while the current MIPv6 spec (through the R bit in the BU) has some basic support in this general direction - that's all. I guage from the discussion that there is interest in doing more than this. The best way for this to proceed is to initially try to get shared understanding on a problem statement, terminology, and how this relates to different scenarious that folks want to deploy. But please folks (on the mailing list in general), don't think that authorization and other security issues can be left until later - those need to be a fundamental part of the thinking from the start. Erik From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 16 10:06:45 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07814 for ; Thu, 16 Aug 2001 10:06: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 HAA06889; Thu, 16 Aug 2001 07:07:46 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA18987; Thu, 16 Aug 2001 07:07:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7GE68R17865 for mobile-ip-dist; Thu, 16 Aug 2001 07:06:08 -0700 (PDT) Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.179.15]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7GE64D17855 for ; Thu, 16 Aug 2001 07:06:04 -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 f7GE5r229421; Thu, 16 Aug 2001 16:05:53 +0200 (MET DST) Date: Thu, 16 Aug 2001 16:03:06 +0200 (CEST) From: Erik Nordmark Subject: Re: [mobile-ip] Mobile Routers support without optimization To: Thierry Ernst Cc: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3B791D5F.18C9D39F@inrialpes.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > So how do you handle the case I'm trying to explain above? > > draft-ernst-mobileip-v6-network-02.txt section 5. I didn't see anything in that section saying how a random CN can trust the prefix privided by the MR in the BU except bythe CN blindly trusting the HA. Also, section 5 doesn't even appear to be concerned with the threat I've brought up (which is that an MR specify a shorter prefix length than it is authorized to route with the cooperation of the MR's HA). The only threat explicitly listed is that an MN served by the MR send a BU for the prefix, which clearly the HA+MR can reject as pointed out in that section. Is there a need for a threat analysis? Erik From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 16 10: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 ESMTP id KAA08427 for ; Thu, 16 Aug 2001 10:16: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 IAA14048; Thu, 16 Aug 2001 08:16: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 HAA20973; Thu, 16 Aug 2001 07:15:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7GEDmL17966 for mobile-ip-dist; Thu, 16 Aug 2001 07:13:48 -0700 (PDT) Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.179.15]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7GEDgD17959 for ; Thu, 16 Aug 2001 07:13:43 -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 f7GEDX229997; Thu, 16 Aug 2001 16:13:33 +0200 (MET DST) Date: Thu, 16 Aug 2001 16:10:46 +0200 (CEST) From: Erik Nordmark Subject: Re: [mobile-ip] Mobile Routers support without optimization To: Thierry Ernst Cc: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3B79320E.837B04A5@inrialpes.fr> 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: > Yes. Then, the conclusion would be that we should add something like the > following in the MIPv6 spec: > "MIPv6 is a solution to support mobile nodes. It does not support nodes > behind a mobile router". Dot. I don't remember who, but someone said > that we have to insure that what is in the mipv6 draft does not pretend > to support mobile networks. Then, mobile networks will be addressed in > an other spec. If the WG decides to go that path, which is definitely an option, to be constitent with the above wording the WG needs to remove the "R (Router)" bit from the binding update option. If the WG instead likes to keep that bit the above note needs be written to take into account that the R bit can be used to support some very limited form of MRs. Just to be consistent, Erik From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 16 10:24:23 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08935 for ; Thu, 16 Aug 2001 10:24: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 HAA13743; Thu, 16 Aug 2001 07:25:12 -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 HAA22644; Thu, 16 Aug 2001 07:24:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7GENHs18114 for mobile-ip-dist; Thu, 16 Aug 2001 07:23:17 -0700 (PDT) Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.179.15]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7GEN8D18107 for ; Thu, 16 Aug 2001 07:23:08 -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 f7GEMw201100; Thu, 16 Aug 2001 16:22:58 +0200 (MET DST) Date: Thu, 16 Aug 2001 16:20:11 +0200 (CEST) From: Erik Nordmark Subject: Re: [mobile-ip] Mobile Routers support without optimization To: Mattias Pettersson Cc: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3B793BFC.86D838B1@era.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > First, I still can accept that we use prefix scoped BUs. For another > reason, that is not part of this particular discussion, I suggested that > each MNN takes care of its own home registration. It has pros and cons, > but at least we don't need to check authorization of prefixes. Perhaps I've missed a subtle point in the discussion. Let me try to clarify. I think it is intractable for a CN to verify the authorization for BUs for prefixes. However, a home agent could do this by manual configuration. In the precense of such manual configuration there might not need to be a prefix in the BU. The prefix could be implicit in the prestablished setup between the HA and MR. Thus when the MR does a binding with its HA the HA would automatically associate the appropriate prefix route with that prefix. [However, it would be interesting to compare the resiliency against HA failures between such a simple scheme and a scheme where the MR establishes effectively a tunnel to multiple routers on the home link and uses a routing protocol over those tunnels. Such a scheme would create routing traffic but would be able to recover from HA failures more rapidly.] > The HA, when acting as a CN (i.e. initiating traffic itself), *then* it > would need a prefix scoped BU. But when it is only intercepting and > forwarding packets initiated by others, a standard entry in the binding > cache plus a routing entry for the mobile network prefix would be > sufficient. Presumably one can make both the originating and forwarding aspects of a HA take the prefix into account - the authorization issue is indepedent of this. Erik From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 16 10:30:15 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09359 for ; Thu, 16 Aug 2001 10:30: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 IAA24949; Thu, 16 Aug 2001 08:30: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 HAA22993; Thu, 16 Aug 2001 07:27:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7GEQWw18191 for mobile-ip-dist; Thu, 16 Aug 2001 07:26:32 -0700 (PDT) Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.179.15]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7GEQRD18179 for ; Thu, 16 Aug 2001 07:26:28 -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 f7GEQK201506; Thu, 16 Aug 2001 16:26:20 +0200 (MET DST) Date: Thu, 16 Aug 2001 16:23:34 +0200 (CEST) From: Erik Nordmark Subject: Re: [mobile-ip] Mobile Routers support without optimization To: Alexandru Petrescu Cc: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > HA indeed "forwards" traffic but not at IP level, thus it's not a > router. HA builds tunnells to its MN's, in something some call the > "Mobile IP plane", different than the "IP routing plane". The only concise definition of "router" I know of is captured in RFC 2460: router - a node that forwards IPv6 packets not explicitly addressed to itself. By this definition a HA is a router. Which is your definition of a router? The HA needs to decrement ttl when forwarding the packets and as far as I know that is part of the "IP level". Erik From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 16 11:14:02 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11976 for ; Thu, 16 Aug 2001 11:14: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 JAA01315; Thu, 16 Aug 2001 09:14: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 IAA01151; Thu, 16 Aug 2001 08:11:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7GFA4518558 for mobile-ip-dist; Thu, 16 Aug 2001 08:10:04 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7GF9xD18541 for ; Thu, 16 Aug 2001 08:09: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 IAA27731 for ; Thu, 16 Aug 2001 08:10:02 -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 JAA02594 for ; Thu, 16 Aug 2001 09:10:12 -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 f7GF9wO05202 for ; Thu, 16 Aug 2001 17:09:58 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Thu Aug 16 17:09:58 2001 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 16 Aug 2001 17:03:27 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008BC5@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Mobile Routers support without optimization Date: Thu, 16 Aug 2001 17:09:50 +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: > > Yes. Then, the conclusion would be that we should add something like the > > following in the MIPv6 spec: > > "MIPv6 is a solution to support mobile nodes. It does not support nodes > > behind a mobile router". Dot. I don't remember who, but someone said > > that we have to insure that what is in the mipv6 draft does not pretend > > to support mobile networks. Then, mobile networks will be addressed in > > an other spec. > > If the WG decides to go that path, which is definitely an option, > to be constitent with the above wording the WG needs to remove > the "R (Router)" bit from the binding update option. > > If the WG instead likes to keep that bit the above note needs be written > to take into account that the R bit can be used to support some very > limited form of MRs. > => Without having the prefix scoped BU to the HA, I don't really see a lot of value for the R flag. In fact I never really understood what the intention was. So unless there is a meaning behind it I would ote for removng it, since we already had concensus on removing the prefix based BU suboption. Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 16 11:34:27 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13249 for ; Thu, 16 Aug 2001 11:34:27 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA20235; Thu, 16 Aug 2001 09:35: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 IAA05092; Thu, 16 Aug 2001 08:34:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7GFXqK18707 for mobile-ip-dist; Thu, 16 Aug 2001 08:33:52 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7GFXnD18700 for ; Thu, 16 Aug 2001 08:33: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 IAA00868 for ; Thu, 16 Aug 2001 08:33:52 -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 JAA18896 for ; Thu, 16 Aug 2001 09:33:47 -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 f7GFXoO13331 for ; Thu, 16 Aug 2001 17:33:50 +0200 (MEST) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id RAA01915; Thu, 16 Aug 2001 17:33:50 +0200 Message-ID: <3B7BE745.30783FA8@era.ericsson.se> Date: Thu, 16 Aug 2001 17:31:17 +0200 From: Mattias Pettersson Organization: Ericsson Research X-Mailer: Mozilla 4.77 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile Routers support without optimization References: <3B7923D6.B231F8D3@era.ericsson.se> <3B7937A9.840171E@era.ericsson.se> <3B7A82AB.7F81FF45@era.ericsson.se> <3B7BAF3D.27B4C11C@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 Alexandru Petrescu wrote: > > Mattias Pettersson writes: > > > I asked also, why not RIP or OSPF? Several reasons, _IMHO_. Same > > > scalability issues that applied when designing Mobile IP will apply to > > > Mobile Networks. How fast routes get updated? How many routes change > > > at how many routers? Also, in my understanding, off-the-shelf RIP > > > would not suffice, one needs Triggered RIP. Also, RIP's bad news > > > don't propagate quickly, so don't rely on it to tell CN's that MR's > > > are no longer there. > > > > Sorry, I can't see what CN this would affect. > > Right, I meant CN's TCP will retransmit because MN unreachable. Yes, if we go for a solution where routing protocols will reflect in some manner that the MR is away, then they have to be fast (which is unlikely) or the HA must cover up for the MR. Of course we don't want CN to get destination unreachable icmp error. > > > Also, your argument is an indicator to that Mobile IPv6 should hide > > the fact that the MR is moving. In other words, not show that to > > RIP. > > Right, kind of. I think a solution can be designed where tunnelling > is used between HA and MR-not-at-home (without tunnelling route > adjacency, looks complex) and routing is used only between HA and > MR-at-home. Ok, if possible. > > > Erik talked about tunnelling between the MR and HA, also when the MR > > is home. > > YEs, I reread his messages. Thanks for pointing it out. > > > Outbound traffic from the MR's subnet is more of default route > > type. But still, a router should not be listening to RAs (or a > > router enabled interface). Or have I got this all wrong? > > Oops, _I_ might have it all wrong. Shame. > > So how do MR's get a CoA? This is a paradox, I'm afraid. Routers should not autoconfigure. Sometimes routers shouldn't even have a global address, but only a link-local. I believe we need to do work in this area, because ND spec is not covering this. > > > Anyway, inbound traffic to the MR's subnet is more problematic. You > > suggest static routes. In some cases this is ok, I suppose. But an > > ISP with a lot of MRs would likely prefer some automation here. A > > new protocol? > > You enlarge the _number of MR's_, I was saying that the _number of > hosts_ in a PAN is small and thus MR has probably only a very few > prefixes (read 1) it knows to route. All true, but I meant that there could possibly be a large number of MRs belonging on the home link, each with one (or multiple) mobile subnets. /Mattias > > But I'll go back read that route adjacency thread. > > Alex From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 16 12:01:07 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14389 for ; Thu, 16 Aug 2001 12:01: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 JAA27729; Thu, 16 Aug 2001 09:02: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 JAA07921; Thu, 16 Aug 2001 09:01:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7GG0Er18891 for mobile-ip-dist; Thu, 16 Aug 2001 09:00:14 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7GG0AD18884 for ; Thu, 16 Aug 2001 09:00: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 JAA06527 for ; Thu, 16 Aug 2001 09:00:14 -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 JAA19934 for ; Thu, 16 Aug 2001 09:00:13 -0700 (PDT) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate2.mot.com (motgate2 2.1) with ESMTP id JAA11188 for ; Thu, 16 Aug 2001 09:00:12 -0700 (MST)] Received: [from m-il06-r4.mot.com (m-il06-r4.mot.com [129.188.137.196]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id JAA17239 for ; Thu, 16 Aug 2001 09:00:10 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r4.mot.com with ESMTP; Thu, 16 Aug 2001 11:00:09 -0500 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 485502ECAC; Thu, 16 Aug 2001 17:59:39 +0200 (CEST) To: Erik Nordmark Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile Routers support without optimization References: From: Alexandru Petrescu Date: 16 Aug 2001 18:00:07 +0200 In-Reply-To: Message-Id: Lines: 35 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 made the distinction HA - router mainly to stress that HA can be physically separated of the AR and that it is not likely to participate in route maintenance protocols. But I might have it all wrong, thanks for helping me understanding these issues. I recognize my ignorance in my first appreciation. Erik Nordmark writes: > > HA indeed "forwards" traffic but not at IP level, thus it's not a > > router. HA builds tunnells to its MN's, in something some call the > > "Mobile IP plane", different than the "IP routing plane". > > The only concise definition of "router" I know of is captured in RFC 2460: > router - a node that forwards IPv6 packets not explicitly > addressed to itself. > > By this definition a HA is a router. Indeed. > Which is your definition of a router? Why isn't Mobile IPv6 spec requiring the HA to join all-routers mc address? Why isn't Mobile IPv6 spec requiring the HA to send router advertisements? [*] Alex [*] Well the -13 doesn't require it in 7.3. Requirements for IPv6 Home Agents, but it does talk about it in 4.1. Basic Operation: "This list of home agents is maintained by each home agent on the home link through use of the Home Agent (H) bit in each home agent's periodic unsolicited multicast Router Advertisements." From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 16 12:24:33 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15182 for ; Thu, 16 Aug 2001 12:24: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 KAA04564; Thu, 16 Aug 2001 10:24:19 -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 JAA12620; Thu, 16 Aug 2001 09:24:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7GGMpY19071 for mobile-ip-dist; Thu, 16 Aug 2001 09:22:51 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7GGMlD19064 for ; Thu, 16 Aug 2001 09:22:47 -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 JAA12328 for ; Thu, 16 Aug 2001 09:22:51 -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 JAA17222 for ; Thu, 16 Aug 2001 09:22:50 -0700 (PDT) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate.mot.com (motgate 2.1) with ESMTP id JAA09903 for ; Thu, 16 Aug 2001 09:22:50 -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 JAA06319 for ; Thu, 16 Aug 2001 09:22:50 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r1.mot.com with ESMTP for mobile-ip@sunroof.eng.sun.com; Thu, 16 Aug 2001 11:22:49 -0500 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id EFAAE2ECAC for ; Thu, 16 Aug 2001 18:22:19 +0200 (CEST) To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile Routers support without optimization References: From: Alexandru Petrescu Date: 16 Aug 2001 18:22:48 +0200 In-Reply-To: Message-Id: Lines: 7 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: Alexandru Petrescu writes: > Why isn't Mobile IPv6 spec requiring the HA to send router > advertisements? [*] Sorry, I had it wrong again. Alex From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 16 13:20:49 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16445 for ; Thu, 16 Aug 2001 13:20:49 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA05137; Thu, 16 Aug 2001 10:21: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 KAA24092; Thu, 16 Aug 2001 10:21:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7GHK2M19356 for mobile-ip-dist; Thu, 16 Aug 2001 10:20: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+Sun/8.11.5) with ESMTP id f7GHJxD19349 for ; Thu, 16 Aug 2001 10: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 KAA15868; Thu, 16 Aug 2001 10:20:02 -0700 (PDT) Message-Id: <200108161720.KAA15868@heliopolis.eng.sun.com> Date: Thu, 16 Aug 2001 10:19:54 -0700 (PDT) From: James Kempf Subject: Re: [mobile-ip] Mobile Routers support without optimization To: thierry.ernst@inrialpes.fr, 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: utCdeh7f4YAQXO2CrWeFeA== 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 think it would be appropriate to remove the "R" bit. There are too many issues involved in mobile routers that are not well understood. If BUs ultimately turn out to be the right way to go to route optimize for mobile routers, then we can rev the spec and add something to support prefixes. jak >Date: Thu, 16 Aug 2001 16:10:46 +0200 (CEST) >From: Erik Nordmark >Subject: Re: [mobile-ip] Mobile Routers support without optimization >To: Thierry Ernst >Cc: mobile-ip@sunroof.eng.sun.com > >> Yes. Then, the conclusion would be that we should add something like the >> following in the MIPv6 spec: >> "MIPv6 is a solution to support mobile nodes. It does not support nodes >> behind a mobile router". Dot. I don't remember who, but someone said >> that we have to insure that what is in the mipv6 draft does not pretend >> to support mobile networks. Then, mobile networks will be addressed in >> an other spec. > >If the WG decides to go that path, which is definitely an option, >to be constitent with the above wording the WG needs to remove >the "R (Router)" bit from the binding update option. > >If the WG instead likes to keep that bit the above note needs be written >to take into account that the R bit can be used to support some very >limited form of MRs. > >Just to be consistent, > Erik > From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 16 13:22:53 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16478 for ; Thu, 16 Aug 2001 13:22: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 LAA22144; Thu, 16 Aug 2001 11:22: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 KAA24379; Thu, 16 Aug 2001 10:22:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7GHLGF19377 for mobile-ip-dist; Thu, 16 Aug 2001 10:21:16 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7GHLDD19370 for ; Thu, 16 Aug 2001 10:21:13 -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 KAA24135 for ; Thu, 16 Aug 2001 10:21:17 -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 KAA08706 for ; Thu, 16 Aug 2001 10:21:16 -0700 (PDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (motgate2 2.1) with ESMTP id KAA17570 for ; Thu, 16 Aug 2001 10:21:15 -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 KAA04250 for ; Thu, 16 Aug 2001 10:21:15 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r4.mot.com with ESMTP for mobile-ip@sunroof.eng.sun.com; Thu, 16 Aug 2001 12:21:14 -0500 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 960B52ECAC for ; Thu, 16 Aug 2001 19:20:44 +0200 (CEST) To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile Routers support without optimization References: <200108151833.LAA28132@heliopolis.eng.sun.com> From: Alexandru Petrescu Date: 16 Aug 2001 19:21:14 +0200 In-Reply-To: <200108151833.LAA28132@heliopolis.eng.sun.com> Message-Id: Lines: 10 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: James Kempf writes: > Not to mention BGP. Should a BGP autonomous system be advertising > prefixes for "care-of" subnets, i.e. subnets that get their prefixes > doled out to mobile routers when they arrive, even though there may > be no mobile network there yet? You mean that instead of a CoA, a visiting MR would obtain a CoP (care-of prefix) and renumber its MNN's with it? Alex From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 16 13:25:04 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16563 for ; Thu, 16 Aug 2001 13:25: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 LAA24125; Thu, 16 Aug 2001 11:24: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 KAA24966; Thu, 16 Aug 2001 10:24:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7GHO2119491 for mobile-ip-dist; Thu, 16 Aug 2001 10:24: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+Sun/8.11.5) with ESMTP id f7GHNwD19480 for ; Thu, 16 Aug 2001 10:23:58 -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 KAA16121; Thu, 16 Aug 2001 10:23:58 -0700 (PDT) Message-Id: <200108161723.KAA16121@heliopolis.eng.sun.com> Date: Thu, 16 Aug 2001 10:23:50 -0700 (PDT) From: James Kempf Subject: Re: [mobile-ip] Mobile Routers support without optimization To: James.Kempf@Sun.COM, Erik.Nordmark@eng.sun.com Cc: Erik.Nordmark@eng.sun.com, mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: q0y7YprV5pH41R0RuMRbsA== 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, Thanx for the reply. >> What does a MR being "at home" mean? A router typically bridges subnets >> and so it is not entirely obvious to me what it means for a MR to >> have a home agent nor what the router's home subnet would be. > >Depending on approach to the problem people might come up >with different definitions. In the PAN case (and perhaps other scenarios) >it probably makes sense to define the "home link" as the link >where the routers live that the MR has routing adjacencies. >Essentially those routers at home trust the MR to announce routes for >at least its mobile subnet. > >In order for the MR to tell those routers at home its current location >the MR need some identity. I think the home address could be such an identity. > In the PAN scenario, the PAN always gets access to the wired network through some other radio or wired link, correct? If so, the PAN interface itself is never connecting into the wired network directly. In that case, as Mattias suggested, a NAT on the PAN side would work just fine (yes, I know NATs are evil, but they are a practical, short term solution that should be discussed). jak From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 16 13:42:10 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17150 for ; Thu, 16 Aug 2001 13:42: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 KAA17597; Thu, 16 Aug 2001 10:42:32 -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 KAA29289; Thu, 16 Aug 2001 10:37:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7GHaI019680 for mobile-ip-dist; Thu, 16 Aug 2001 10:36:18 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7GHaED19673 for ; Thu, 16 Aug 2001 10:36: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 KAA16912 for ; Thu, 16 Aug 2001 10:36:18 -0700 (PDT) Message-Id: <200108161736.KAA16912@heliopolis.eng.sun.com> Date: Thu, 16 Aug 2001 10:36:11 -0700 (PDT) From: James Kempf Subject: Re: [mobile-ip] Mobile Routers support without optimization To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: +7b+GbRcWWVawRzGf0KaQw== 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: >> Not to mention BGP. Should a BGP autonomous system be advertising >> prefixes for "care-of" subnets, i.e. subnets that get their prefixes >> doled out to mobile routers when they arrive, even though there may >> be no mobile network there yet? > >You mean that instead of a CoA, a visiting MR would obtain a CoP >(care-of prefix) and renumber its MNN's with it? > I was thinking of the route optimization case, where the MR sends a BU with a prefix. Should the autonomous system of the access network reserve this prefix and should the prefix be advertised via BGP even if there is no MR there? Seems like an invitation for even more growth in routing tables, but if this isn't done, then I suppose one would have to wait for the updates to propagate before the prefix was visible outside the autonomous system. I'm not a BGP expert, so maybe there is some clever way around this. But now that you mention it, what does a MR having a "home address" mean? According to Erik's previous definition of a router, a router forwards traffic that is not sent to it. So other than for handling routing updates and sending routing advertisements, it is not clear what a "home address" means for a router. Am I missing something? jak From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 16 14:08:56 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18037 for ; Thu, 16 Aug 2001 14:08: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 MAA04677; Thu, 16 Aug 2001 12:09: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 LAA07334; Thu, 16 Aug 2001 11:09:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7GI7hO19853 for mobile-ip-dist; Thu, 16 Aug 2001 11:07:43 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7GI7eD19846 for ; Thu, 16 Aug 2001 11:07: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 LAA05083 for ; Thu, 16 Aug 2001 11:07:44 -0700 (PDT) Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA02899 for ; Thu, 16 Aug 2001 12:07:40 -0600 (MDT) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate3.mot.com (motgate3 2.1) with ESMTP id LAA03713 for ; Thu, 16 Aug 2001 11:00:02 -0700 (MST)] Received: [from m-il06-r3.mot.com (m-il06-r3.mot.com [129.188.137.194]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id LAA25863 for ; Thu, 16 Aug 2001 11:07:43 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r3.mot.com with ESMTP; Thu, 16 Aug 2001 13:07:35 -0500 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 03E062ECAC; Thu, 16 Aug 2001 20:07:12 +0200 (CEST) To: mobile-ip@sunroof.eng.sun.com Cc: Thierry Ernst Subject: Re: [mobile-ip] Mobile Routers support without optimization References: From: Alexandru Petrescu Date: 16 Aug 2001 20:07:41 +0200 In-Reply-To: Message-Id: Lines: 12 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: Erik Nordmark writes: > If the WG decides to go that path, which is definitely an option, to > be constitent with the above wording the WG needs to remove the "R > (Router)" bit from the binding update option. I'm not sure how easy this will be since it's used in the binding cache too and from there into the modified Router Advertisement. The latter should be kept, I think, being used by other things than the R bit from cache. Alex From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 16 14:34:01 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18722 for ; Thu, 16 Aug 2001 14:34: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 MAA29089; Thu, 16 Aug 2001 12:34: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 LAA11462; Thu, 16 Aug 2001 11:34:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7GIXZ020021 for mobile-ip-dist; Thu, 16 Aug 2001 11:33:35 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7GIXVD20014 for ; Thu, 16 Aug 2001 11:33: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 LAA11356 for ; Thu, 16 Aug 2001 11:33:34 -0700 (PDT) Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA27756 for ; Thu, 16 Aug 2001 12:33:29 -0600 (MDT) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate4.mot.com (motgate4 2.1) with ESMTP id LAA11046 for ; Thu, 16 Aug 2001 11:33:33 -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 LAA11601 for ; Thu, 16 Aug 2001 11:33:33 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r3.mot.com with ESMTP for mobile-ip@sunroof.eng.sun.com; Thu, 16 Aug 2001 13:33:22 -0500 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 1B8362ECAC for ; Thu, 16 Aug 2001 20:32:59 +0200 (CEST) To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile Routers support without optimization References: <200108161736.KAA16912@heliopolis.eng.sun.com> From: Alexandru Petrescu Date: 16 Aug 2001 20:33:29 +0200 In-Reply-To: <200108161736.KAA16912@heliopolis.eng.sun.com> Message-Id: Lines: 37 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: James Kempf writes: > >You mean that instead of a CoA, a visiting MR would obtain a CoP > >(care-of prefix) and renumber its MNN's with it? > > I was thinking of the route optimization case, where the MR sends a > BU with a prefix. Should the autonomous system of the access network > reserve this prefix and should the prefix be advertised via BGP even > if there is no MR there? If by "access network" you mean the foreign network then the prefix in BU sent by MR doesn't belong to the foreign net but to the home net, so it's not advertised by that BGP right? If by "access network" you mean the home network then the BGP of the AS of that could freely advertise that prefix (a superset of it), because even if MR-not-at-home, its prefix would be defended by the HA when receiving a BU. > Seems like an invitation for even more growth in routing tables, but > if this isn't done, then I suppose one would have to wait for the > updates to propagate before the prefix was visible outside the > autonomous system. All valid argument. > But now that you mention it, what does a MR having a "home address" > mean? According to Erik's previous definition of a router, a router > forwards traffic that is not sent to it. I was thinking that MR's home address is like a classical MN's home address. When MR is not at home, all incoming traffic from CN's to MNN's, would first go to HA, encapsulated, decapsulated by MR-not-at-home and forwarded to MNN. Thus, the scenario agrees with Erik definition of a router: MR-not-at-home would still forward traffic not directed to itself. Alex From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 16 15:47:08 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21237 for ; Thu, 16 Aug 2001 15:47: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 MAA21437; Thu, 16 Aug 2001 12:48: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 MAA28161; Thu, 16 Aug 2001 12:47:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7GJk0G20202 for mobile-ip-dist; Thu, 16 Aug 2001 12:46: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+Sun/8.11.5) with ESMTP id f7GJjuD20195 for ; Thu, 16 Aug 2001 12:45: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 MAA23383 for ; Thu, 16 Aug 2001 12:45:59 -0700 (PDT) Message-Id: <200108161945.MAA23383@heliopolis.eng.sun.com> Date: Thu, 16 Aug 2001 12:45:51 -0700 (PDT) From: James Kempf Subject: Re: [mobile-ip] Mobile Routers support without optimization To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: ow/lWw65nJEjPb2iw/va8A== 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: Alex, >> >You mean that instead of a CoA, a visiting MR would obtain a CoP >> >(care-of prefix) and renumber its MNN's with it? >> >> I was thinking of the route optimization case, where the MR sends a >> BU with a prefix. Should the autonomous system of the access network >> reserve this prefix and should the prefix be advertised via BGP even >> if there is no MR there? > >If by "access network" you mean the foreign network then the prefix in >BU sent by MR doesn't belong to the foreign net but to the home net, >so it's not advertised by that BGP right? > Sorry for sounding totally clueless, but I'm extrapolating what's in the BU from what would be in if an MN were to send it. If an MN sends it, the BU contains the care of address, which is in the foreign network. Extrapolating, the MR would have to send a prefix that is in the foreign network. The point of the BU in the mobile host case is to tell the HA and CN to change its routing to the new address. The point of the BU for a MR is presumably to cause a change in the routing tables in subnets that are corresponding with host behind the MR, including the home network. That is, of course, if you want to completely eliminate triange routing. >If by "access network" you mean the home network then the BGP of the >AS of that could freely advertise that prefix (a superset of it), >because even if MR-not-at-home, its prefix would be defended by the HA >when receiving a BU. > >> Seems like an invitation for even more growth in routing tables, but >> if this isn't done, then I suppose one would have to wait for the >> updates to propagate before the prefix was visible outside the >> autonomous system. > >All valid argument. > >> But now that you mention it, what does a MR having a "home address" >> mean? According to Erik's previous definition of a router, a router >> forwards traffic that is not sent to it. > >I was thinking that MR's home address is like a classical MN's home >address. When MR is not at home, all incoming traffic from CN's to >MNN's, would first go to HA, encapsulated, decapsulated by >MR-not-at-home and forwarded to MNN. Thus, the scenario agrees with >Erik definition of a router: MR-not-at-home would still forward >traffic not directed to itself. > This sounds like MIP + a NAT. jak From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 16 16:55:37 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22669 for ; Thu, 16 Aug 2001 16:55: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 NAA19481; Thu, 16 Aug 2001 13:56: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 NAA09680; Thu, 16 Aug 2001 13:56:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7GKt6v20435 for mobile-ip-dist; Thu, 16 Aug 2001 13:55:06 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7GKt3D20428 for ; Thu, 16 Aug 2001 13:55:03 -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 NAA12033 for ; Thu, 16 Aug 2001 13:55: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 NAA29686 for ; Thu, 16 Aug 2001 13:55: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 f7GKt4O02395 for ; Thu, 16 Aug 2001 22:55:04 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Thu Aug 16 22:54:57 2001 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 16 Aug 2001 22:48:32 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008BC9@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Cc: Thierry Ernst Subject: RE: [mobile-ip] Mobile Routers support without optimization Date: Thu, 16 Aug 2001 22:54:57 +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: > > If the WG decides to go that path, which is definitely an option, to > > be constitent with the above wording the WG needs to remove the "R > > (Router)" bit from the binding update option. > > I'm not sure how easy this will be since it's used in the binding > cache too and from there into the modified Router Advertisement. > => Which router advertisement ? I think you're talking about a different R bit maybe ? Anyway, it's used in the Binding cache because it's in the BU, so if it's removed from the BU it is removed from the binding cache. > The latter should be kept, I think, being used by other things than > the R bit from cache. > => I've lost you here. The latter meaning the R bit? what was the former ? Thanks, Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 16 17:20:44 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23134 for ; Thu, 16 Aug 2001 17:20: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 PAA28658; Thu, 16 Aug 2001 15:21: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 OAA15657; Thu, 16 Aug 2001 14:21:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7GLKSG20593 for mobile-ip-dist; Thu, 16 Aug 2001 14:20:28 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7GLKOD20586 for ; Thu, 16 Aug 2001 14:20: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 OAA17578 for ; Thu, 16 Aug 2001 14:20:29 -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 OAA22959 for ; Thu, 16 Aug 2001 14:20:27 -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 f7GLKQN13092 for ; Thu, 16 Aug 2001 23:20:26 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu Aug 16 23:20:20 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Thu, 16 Aug 2001 23:20:25 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008BCA@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] IPsec, IKE, MIPv6 and concensus Date: Thu, 16 Aug 2001 23:20: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, During the meeting Phil had asked me to write something up to describe the problem with IPsec usage and some suggestions. Obviously as we all know (or some of us) Mike Thomas already wrote a draft for ESP, also Pekka sent a very long mail on the general topic, so I'm not sure if a draft would add more to what we discussed. Therefore I thought perhaps getting some concensus on IPsec usage would be a good idea. First let me summarise briefly the two problems we're having: 1. Relying on IKE only as a key exchange mechanism is not acceptable (This was discussed several times and I think we all agree on this assumption) 2. There are some issues to be resolved if IPsec is to be used. Mainly this is related to the recent discussions on IPsec selectors and their granularity. Before London, we agreed that (2) can be solved in 2 different ways: A. Use a new Ext Header value for MIPv6 BUs. This will not involve any modifications to the IPsec implementations. B. Add some text to the draft to explain that all implementations for MNs and CNs (receiving BUs only) MUST increase the granularity of their IPsec implementations to search for the BU option instead of relying on the nxt Header value only. Of course both A and B rely on eliminating piggybacking of the BUs. Problem (1) is addressed by several proposals. Needless to say that 1 and 2 are not dependant on each other (or need not be). So the questions that should be answered IMO are: 1. Do we want to completely disallow the use of IKE ? 2. Do we want to completely disallow the use of IPsec ? I guess based on the WG concensus this should be reflected in the draft so we can get on with our implementations. What do people think ? My answer to both questions is No. I do believe that there will be cases where strong authentication will be required. Since there are ways of allowing the use of both IKE (as an option) and IPsec (whether its AH or ESP) then I don't see why we can't reuse them. Regards, Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 16 18:34:58 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26774 for ; Thu, 16 Aug 2001 18:34: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 PAA28051; Thu, 16 Aug 2001 15:35: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 PAA03513; Thu, 16 Aug 2001 15:35:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7GMYce21028 for mobile-ip-dist; Thu, 16 Aug 2001 15:34:38 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7GMYZL21021 for ; Thu, 16 Aug 2001 15:34: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 PAA03461 for ; Thu, 16 Aug 2001 15:34:38 -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 PAA13407 for ; Thu, 16 Aug 2001 15:34:38 -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 PAA14666 for ; Thu, 16 Aug 2001 15:34:37 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f7GMYbN05213 for ; Thu, 16 Aug 2001 15:34:37 -0700 X-mProtect: Thu, 16 Aug 2001 15:34: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 smtpdu6fmVr; Thu, 16 Aug 2001 15:34:35 PDT Message-ID: <3B7C4A7B.2DCECEDC@iprg.nokia.com> Date: Thu, 16 Aug 2001 15:34: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] IPsec, IKE, MIPv6 and concensus References: <034BEFD03799D411A59F00508BDF754603008BCA@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: > Problem (1) is addressed by several proposals. Needless to say that > 1 and 2 are not dependant on each other (or need not be). > > So the questions that should be answered IMO are: > > 1. Do we want to completely disallow the use of IKE ? NO. > > 2. Do we want to completely disallow the use of IPsec ? YES. use authentication data suboption for the BU. vijay > > I guess based on the WG concensus this should be reflected > in the draft so we can get on with our implementations. > > What do people think ? > > My answer to both questions is No. I do believe that there will > be cases where strong authentication will be required. Since > there are ways of allowing the use of both IKE (as an option) > and IPsec (whether its AH or ESP) then I don't see why we can't > reuse them. > > Regards, > Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 16 19:36:15 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27634 for ; Thu, 16 Aug 2001 19:36: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 RAA21264; Thu, 16 Aug 2001 17:37:05 -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 QAA15536; Thu, 16 Aug 2001 16:36:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7GNZVT21297 for mobile-ip-dist; Thu, 16 Aug 2001 16:35:31 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.88.31]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7GNZSL21290 for ; Thu, 16 Aug 2001 16:35:28 -0700 (PDT) Received: from locked (locked.Eng.Sun.COM [129.146.85.189]) by jurassic.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with SMTP id f7GNZTe741649 for ; Thu, 16 Aug 2001 16:35:29 -0700 (PDT) Message-Id: <200108162335.f7GNZTe741649@jurassic.eng.sun.com> Date: Thu, 16 Aug 2001 16:34:03 -0700 (PDT) From: Mohan Parthasarathy Subject: Re: [mobile-ip] IPsec, IKE, MIPv6 and concensus To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: vdepQ+2Hp4iWcq2XqCvwBg== 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: . > > So the questions that should be answered IMO are: > > 1. Do we want to completely disallow the use of IKE ? > > 2. Do we want to completely disallow the use of IPsec ? > > I guess based on the WG concensus this should be reflected > in the draft so we can get on with our implementations. > > What do people think ? > > My answer to both questions is No. Agreed. > I do believe that there will > be cases where strong authentication will be required. Since Correct. We need this for communication between MN and HA. -mohan > there are ways of allowing the use of both IKE (as an option) > and IPsec (whether its AH or ESP) then I don't see why we can't > reuse them. > > Regards, > Hesham > > > > > From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 16 19: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 ESMTP id TAA27823 for ; Thu, 16 Aug 2001 19:54:35 -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 QAA24244; Thu, 16 Aug 2001 16:55: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 QAA19058; Thu, 16 Aug 2001 16:55:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7GNrul21478 for mobile-ip-dist; Thu, 16 Aug 2001 16:53:56 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7GNrqL21471 for ; Thu, 16 Aug 2001 16:53:52 -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 QAA17664 for ; Thu, 16 Aug 2001 16:53: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 RAA29309 for ; Thu, 16 Aug 2001 17:53: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 QAA20497 for ; Thu, 16 Aug 2001 16:53:54 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f7GNrrh03491 for ; Thu, 16 Aug 2001 16:53:53 -0700 X-mProtect: Thu, 16 Aug 2001 16:53:53 -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 smtpdW2QHFD; Thu, 16 Aug 2001 16:53:52 PDT Message-ID: <3B7C5D11.94BC74D5@iprg.nokia.com> Date: Thu, 16 Aug 2001 16:53: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: Re: [mobile-ip] IPsec, IKE, MIPv6 and concensus References: <200108162335.f7GNZTe741649@jurassic.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit IKE and 'authentication data suboption' is also strong authentication IMHO authentication data suboption = hmac_md5("bu option + home address option", len, key, key_len) here the key is generated by IKE. vijay Mohan Parthasarathy wrote: > > > > > So the questions that should be answered IMO are: > > > > 1. Do we want to completely disallow the use of IKE ? > > > > 2. Do we want to completely disallow the use of IPsec ? > > > > I guess based on the WG concensus this should be reflected > > in the draft so we can get on with our implementations. > > > > What do people think ? > > > > My answer to both questions is No. > > Agreed. > > > I do believe that there will > > be cases where strong authentication will be required. Since > > Correct. We need this for communication between MN and HA. > > -mohan > > > there are ways of allowing the use of both IKE (as an option) > > and IPsec (whether its AH or ESP) then I don't see why we can't > > reuse them. > > > > Regards, > > Hesham > > > > > > > > > > From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 16 19:58:05 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27862 for ; Thu, 16 Aug 2001 19:58: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 QAA25442; Thu, 16 Aug 2001 16:59:08 -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 QAA19761; Thu, 16 Aug 2001 16:58:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7GNvg521548 for mobile-ip-dist; Thu, 16 Aug 2001 16:57:42 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7GNvcL21541 for ; Thu, 16 Aug 2001 16:57:38 -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 QAA19523 for ; Thu, 16 Aug 2001 16:57:42 -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 QAA12740 for ; Thu, 16 Aug 2001 16:57:41 -0700 (PDT) Received: (qmail 6075 invoked by uid 500); 16 Aug 2001 23:45:56 -0000 Date: Thu, 16 Aug 2001 16:45:56 -0700 From: Pat Calhoun To: Mikael Wolf Cc: charliep@iprg.nokia.com, pcalhoun@diameter.org, mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Re: MN-FA/MN-HA Key Material clarification needed Message-ID: <20010816164556.J4357@charizard.diameter.org> References: <006901c1261c$0e954d50$e704a8c0@MIKAELSPC> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <006901c1261c$0e954d50$e704a8c0@MIKAELSPC>; from mikael.wolf@ipunplugged.com on Thu, Aug 16, 2001 at 08:24:08AM +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: Chapter 3 defines the hashing algorithms used in the computation of the relevant authentication extensions, not how to encrypt the key. So, the key material is used to create the key, and the key is used to create the auth extensions. Hope this is clearer, PatC On Thu, Aug 16, 2001 at 08:24:08AM +0200, Mikael Wolf wrote: > draft-ietf-mobileip-aaa-key-08.txt, chapter 3, > specifies the algorithms to be used for producing > the authentication information included in the Mobile > Home Authentication extension or the Mobile Foreign > Authentication extension; one of them is SHA-1 (#3). > > However, a hash function cannot be used as a MAC > since it does not rely on a secret key (contradictory to > what is stated in chapter 3). > > Please clarify how SHA-1 should be used provide > authentication. > > Thanks, > Mikael. > > From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 17 01:58:22 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11495 for ; Fri, 17 Aug 2001 01:58: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 XAA11283; Thu, 16 Aug 2001 23:59: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 WAA23779; Thu, 16 Aug 2001 22:14:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7H5CPc22176 for mobile-ip-dist; Thu, 16 Aug 2001 22:12:25 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7H5CLL22169 for ; Thu, 16 Aug 2001 22:12: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 WAA23667 for ; Thu, 16 Aug 2001 22:12:25 -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 WAA26477 for ; Thu, 16 Aug 2001 22:12:24 -0700 (PDT) Received: from MIKAELSPC (c32.local.ipunplugged.com [192.168.4.231]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with SMTP id HAA11155; Fri, 17 Aug 2001 07:13:25 +0200 Message-ID: <001101c126db$20733900$e704a8c0@MIKAELSPC> From: "Mikael Wolf" To: "Pat Calhoun" Cc: , References: <006901c1261c$0e954d50$e704a8c0@MIKAELSPC> <20010816164556.J4357@charizard.diameter.org> Subject: [mobile-ip] Re: MN-FA/MN-HA Key Material clarification needed Date: Fri, 17 Aug 2001 07:11:48 +0200 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.00.2919.6700 X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit But anyone can compute a correct digest using SHA-1, i.e., just using a hash function does not provide any authentication. You mention that the key is used to create the authentication extensions, but how the key should be used is not clear; SHA-1 in itself does not use a key. In contrast, HMAC-SHA-1 does specifiy how to use a key together with SHA-1 to provide authentication. Therefore, I would expect the Algorithm Identifier to specify HMAC-SHA-1 ( and possibly SHA-1/prefix+suffix? ) as supported algorithm(s), and not SHA-1. Mikael. ----- Original Message ----- From: "Pat Calhoun" To: "Mikael Wolf" Cc: ; ; Sent: Friday, August 17, 2001 1:45 AM Subject: Re: MN-FA/MN-HA Key Material clarification needed > Chapter 3 defines the hashing algorithms used in the computation > of the relevant authentication extensions, not how to encrypt the > key. So, the key material is used to create the key, and the key is > used to create the auth extensions. > > Hope this is clearer, > > PatC > On Thu, Aug 16, 2001 at 08:24:08AM +0200, Mikael Wolf wrote: > > draft-ietf-mobileip-aaa-key-08.txt, chapter 3, > > specifies the algorithms to be used for producing > > the authentication information included in the Mobile > > Home Authentication extension or the Mobile Foreign > > Authentication extension; one of them is SHA-1 (#3). > > > > However, a hash function cannot be used as a MAC > > since it does not rely on a secret key (contradictory to > > what is stated in chapter 3). > > > > Please clarify how SHA-1 should be used provide > > authentication. > > > > Thanks, > > Mikael. > > > > > From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 17 04:11:34 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAB21530 for ; Fri, 17 Aug 2001 04:11: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 CAA01852; Fri, 17 Aug 2001 02:11: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 BAA07863; Fri, 17 Aug 2001 01:11:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7H8Adx22572 for mobile-ip-dist; Fri, 17 Aug 2001 01:10:39 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7H8AaL22565 for ; Fri, 17 Aug 2001 01:10: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 BAA06846 for ; Fri, 17 Aug 2001 01:10:40 -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 CAA01192 for ; Fri, 17 Aug 2001 02:10:35 -0600 (MDT) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate.mot.com (motgate 2.1) with ESMTP id BAA18588 for ; Fri, 17 Aug 2001 01:10:39 -0700 (MST)] Received: [from m-il06-r4.mot.com (m-il06-r4.mot.com [129.188.137.196]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id BAA19920 for ; Fri, 17 Aug 2001 01:10:38 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r4.mot.com with ESMTP for mobile-ip@sunroof.eng.sun.com; Fri, 17 Aug 2001 03:10:37 -0500 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 5D1D22ECAC for ; Fri, 17 Aug 2001 10:10:05 +0200 (CEST) To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile Routers support without optimization References: <200108161945.MAA23383@heliopolis.eng.sun.com> From: Alexandru Petrescu Date: 17 Aug 2001 10:10:35 +0200 In-Reply-To: <200108161945.MAA23383@heliopolis.eng.sun.com> Message-Id: Lines: 53 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: James Kempf writes: > Sorry for sounding totally clueless, but I'm extrapolating what's in > the BU from what would be in if an MN were to send it. If an MN > sends it, the BU contains the care of address, which is in the > foreign network. Extrapolating, the MR would have to send a prefix > that is in the foreign network. Right, this is what I would call CoP (care-of prefix). But I'm still wondering if there's a need to acquire a CoP and renumber all MNN's when moving. Keeping the same MR-subnet prefix wherever MR moves can be done by updating only binding caches of HA's and CN's and not any routing tables of anyone. Keeping the same MR-subnet prefix also leads to "binding cache-free" MNN's. > The point of the BU in the mobile host case is to tell the HA and CN > to change its routing to the new address. The point of the BU for a > MR is presumably to cause a change in the routing tables in subnets > that are corresponding with host behind the MR, including the home > network. Your extrapolation looks right. With a twist: I would like MR to use BU like MN/HA/CN use it. That is update binding caches only and not routing tables. > That is, of course, if you want to completely eliminate triange > routing. The triangular routing would be eliminated by MR's telling CN's an association of the form (CoA of MR, MR-subnet prefix). And not by telling CN's extrapolated associations like (CoP, Home Prefix). > >I was thinking that MR's home address is like a classical MN's home > >address. When MR is not at home, all incoming traffic from CN's to > >MNN's, would first go to HA, encapsulated, decapsulated by > >MR-not-at-home and forwarded to MNN. Thus, the scenario agrees with > >Erik definition of a router: MR-not-at-home would still forward > >traffic not directed to itself. > > > > This sounds like MIP + a NAT. As I see it, MR is not NAT because its subnet prefix is Internet-routable. By "triangular routing", but still routable. Also, when CN has learned the MR CoA, it would send a packet to MNN by putting MR's CoA and MNN's address into a routing header and off it goes over the net, through MR and to MNN. With a NAT you can't reach nodes behind it whatever you try. NAT uses a sort of translation table containing many-to-one connections, but MR uses its routing table only. Alex From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 17 04:26:45 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21684 for ; Fri, 17 Aug 2001 04:26: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 CAA08883; Fri, 17 Aug 2001 02: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 BAA09218; Fri, 17 Aug 2001 01:27:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7H8QNN22706 for mobile-ip-dist; Fri, 17 Aug 2001 01:26:23 -0700 (PDT) Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.179.15]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7H8QJL22699 for ; Fri, 17 Aug 2001 01:26:19 -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 f7H8Q7228102; Fri, 17 Aug 2001 10:26:07 +0200 (MET DST) Date: Fri, 17 Aug 2001 10:23:16 +0200 (CEST) From: Erik Nordmark Subject: Re: [mobile-ip] Mobile Routers support without optimization To: James Kempf Cc: Erik.Nordmark@eng.sun.com, mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <200108161723.KAA16121@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: > In the PAN scenario, the PAN always gets access to the wired network through > some other radio or wired link, correct? If so, the PAN interface itself is > never connecting into the wired network directly. I don't know exactly what a "PAN interface" is so let me try to restate what you are saying. A PAN is an IP link. There is an IP router between the PAN and the rest of the network. Thus the devices on the PAN (other than the router) never connect directly to any other link - they always go through the router. If that is what you are saying then, from my IP centric view of the world, I think that is a very reasonable view of a PAN. In fact it is the view I'd prefer. > In that case, as Mattias suggested, a NAT on the PAN side would work > just fine (yes, I know NATs are evil, but they are a practical, > short term solution that should be discussed). Whoa - what a can of worms. Should we really dive into that one? NAT has nothing inherently to do with PANs - this argument is no different than NAT being useful in a home environment. And NAT assumes that the devices on the PAN are client-only i.e. they only initiate communication. I for sure want the model to allow devices on the PAN to be able to do peer-to-peer communication with other devices elsewhere in the network i.e. allowing other nodes to connect to the devices in my PAN. Erik From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 17 05:15:35 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22189 for ; Fri, 17 Aug 2001 05:15: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 DAA01490; Fri, 17 Aug 2001 03:16: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 CAA12601; Fri, 17 Aug 2001 02:16:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7H9FZQ22881 for mobile-ip-dist; Fri, 17 Aug 2001 02:15:35 -0700 (PDT) Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.179.15]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7H9FVL22874 for ; Fri, 17 Aug 2001 02:15:31 -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 f7H9En203000; Fri, 17 Aug 2001 11:14:49 +0200 (MET DST) Date: Fri, 17 Aug 2001 11:11:59 +0200 (CEST) From: Erik Nordmark Subject: Re: [mobile-ip] IPsec, IKE, MIPv6 and concensus To: "Hesham Soliman (ERA)" Cc: "'mobile-ip@sunroof.eng.sun.com'" In-Reply-To: "Your message with ID" <034BEFD03799D411A59F00508BDF754603008BCA@esealnt448.al.sw.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > 1. Relying on IKE only as a key exchange mechanism is not > acceptable (This was discussed several times and I think we > all agree on this assumption) I think the placement of "only" above can be a source of confusion - IKE is only ("nothing but") a key exchange mechanism as far as I know. Did you really mean Relying on IKE as the only key exchange mechanism used to secure Mobile IPv6 is not acceptable ... > So the questions that should be answered IMO are: Presumably these questions are solely in the context of securing MIPv6 or perhaps just securing the BUs, or perhaps just securing the BUs with CNs?. I can see folks wanting to use IKE and IPsec to build VPNs to mobile nodes. Thus I think we need more context in order for folks to agree what the questions mean. > 1. Do we want to completely disallow the use of IKE ? > > 2. Do we want to completely disallow the use of IPsec ? > Erik From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 17 07:38:21 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24477 for ; Fri, 17 Aug 2001 07:38:21 -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 FAA26694; Fri, 17 Aug 2001 05:39:15 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA16437; Fri, 17 Aug 2001 04:38:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7HBbGj23297 for mobile-ip-dist; Fri, 17 Aug 2001 04:37:16 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7HBbCL23290 for ; Fri, 17 Aug 2001 04:37:12 -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 EAA22302 for ; Fri, 17 Aug 2001 04:37:13 -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 FAA25822 for ; Fri, 17 Aug 2001 05:37:08 -0600 (MDT) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f7HBbAK19762 for ; Fri, 17 Aug 2001 13:37:11 +0200 (MEST) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id NAA28772; Fri, 17 Aug 2001 13:37:09 +0200 Message-ID: <3B7D0178.B63412C2@era.ericsson.se> Date: Fri, 17 Aug 2001 13:35:20 +0200 From: Mattias Pettersson Organization: Ericsson Research X-Mailer: Mozilla 4.77 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile Routers support without optimization References: <200108161736.KAA16912@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: > > >> Not to mention BGP. Should a BGP autonomous system be advertising > >> prefixes for "care-of" subnets, i.e. subnets that get their prefixes > >> doled out to mobile routers when they arrive, even though there may > >> be no mobile network there yet? > > > >You mean that instead of a CoA, a visiting MR would obtain a CoP > >(care-of prefix) and renumber its MNN's with it? > > > > I was thinking of the route optimization case, where the MR sends > a BU with a prefix. Should the autonomous system of the access network reserve > this prefix and should the prefix be advertised via BGP even if there is > no MR there? Seems like an invitation for even more growth > in routing tables, but if this isn't done, then I suppose > one would have to wait for the updates to propagate before > the prefix was visible outside the autonomous system. I'm > not a BGP expert, so maybe there is some clever way around this. I hope that what is happening at the edges of the foreign ISP won't be reflected to BGP. The CoP (if we now should have one) could be allocated by the MR from the AR at the foreign ISP. The method used could be the prefix delegation draft. If the MR is there, the CoP is being used and should of course be a routeable prefix. MR and AR would announce it upstream (but probably not with BGP, but RIP or OSPF). If MR is not there (or no other MR), the CoP is not being used and the AR keeps it in its prefix pool. Now, AR still announces it upstream. In both cases, aggregation is used outside the ISP, so that BGP doesn't have to know about the CoP - it is rather a subset of the aggregated address space of the ISP. > > But now that you mention it, what does a MR having a "home address" mean? > According to Erik's previous definition of a router, a router forwards > traffic that is not sent to it. So other than for handling routing > updates and sending routing advertisements, it is not clear what > a "home address" means for a router. Am I missing something? But a MR is still a node as well. It could initiate and terminate traffic just like any other node, if someone it currently using it as a client/server or whatever. For this, it needs a home address. /Mattias > > jak From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 17 09:03:29 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28225 for ; Fri, 17 Aug 2001 09:03: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 HAA03024; Fri, 17 Aug 2001 07:04: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 GAA00932; Fri, 17 Aug 2001 06:04:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7HD2Xb23632 for mobile-ip-dist; Fri, 17 Aug 2001 06:02:33 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7HD2UL23625 for ; Fri, 17 Aug 2001 06:02:30 -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 GAA23197 for ; Fri, 17 Aug 2001 06:02: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 HAA04069 for ; Fri, 17 Aug 2001 07:02: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 f7HD2RK10922 for ; Fri, 17 Aug 2001 15:02:27 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Fri Aug 17 15:02:27 2001 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 17 Aug 2001 14:55:55 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008BD7@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Mobile Routers support without optimization Date: Fri, 17 Aug 2001 15:02: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: > > > > > In that case, as Mattias suggested, a NAT on the PAN side would work > > > just fine (yes, I know NATs are evil, but they are a practical, > > > short term solution that should be discussed). > > > > Whoa - what a can of worms. Should we really dive into that one? > > So you prefer this Mobile IPv6 can of worms instead? I wouldn't say we > are completely clean here either... :) > > We are a bit more end-to-end, but NAT has obviously been more deployed > than Mobile IP and seems to be of some use at least. > > Sorry for being ironical (or cynical). I don't support NAT, but it could > solve a few things here: > - No complex trust model, the mobile network will look like a single > MN. > - No additional support in CNs. > - No routing problems at home with other routers. > - As the mobile network is maybe very small, it will require little > configuration. > - If the user wants e2e, he could use the MR. > > Now, if mobile-ip was moderated, I would have been kicked off this list > by now. ;) Should have use my hotmail account... > => Is this the right Mattias ? :)) I think we're discussing solutions under different assmptions. I can understand the MR being used to upate the HA with a prefix scoped BU, however I can not imagine how we could generically solve the authorisation problem if we consider route optimisation being initiated by the MR. So in my mind I always assume that the CN operations are not affected. Ie. BU from the MR to the HA (prefix scoped) and e2e route opt. If we want to to delegate route opt to the MR I think we should start by solving the authorisation problem first. The routing problem will seem trivial after that IMHO. Hesham From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 17 10:57:48 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04331 for ; Fri, 17 Aug 2001 10:57: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 IAB07851; Fri, 17 Aug 2001 08:58: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 HAA15616; Fri, 17 Aug 2001 07:58:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7HEvZ523984 for mobile-ip-dist; Fri, 17 Aug 2001 07:57:35 -0700 (PDT) Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.179.15]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7HEvVL23977 for ; Fri, 17 Aug 2001 07:57:31 -0700 (PDT) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f7HErp229933; Fri, 17 Aug 2001 16:53:51 +0200 (MET DST) Date: Fri, 17 Aug 2001 16:50:58 +0200 (CEST) From: Erik Nordmark Subject: Re: [mobile-ip] Mobile Routers support without optimization To: Alexandru Petrescu Cc: Erik Nordmark , mobile-ip@sunroof.eng.sun.com, Thierry Ernst 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: > Erik Nordmark writes: > > The modifications to the RA (section 6.2) has a unrelated 'R' bit > > which has nothing to do with the 'R' bit in the BU. > > I was thinking that HA should respond to RS's with R bit set if the MN > is away and is a router. That RA's R bit would come from R of binding > cache. It's not specified, but I thought that should be specified. No, the RA should always have the R bit set to that other home agents can discover the global address(es) of the sending HA. This information is needed for the home agent discovery stuff - each HA on the home subnet needs to know the IP addresses of the other HAs since any HA might receive the anycast. Erik From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 17 11:52:16 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06045 for ; Fri, 17 Aug 2001 11:52: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 JAA19712; Fri, 17 Aug 2001 09:53: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 IAA25690; Fri, 17 Aug 2001 08:53:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7HFqQM24228 for mobile-ip-dist; Fri, 17 Aug 2001 08:52:26 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7HFqML24221 for ; Fri, 17 Aug 2001 08:52:22 -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 IAA22185 for ; Fri, 17 Aug 2001 08:52:23 -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 IAA11581 for ; Fri, 17 Aug 2001 08:52:22 -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 f7HFqLv28733 for ; Fri, 17 Aug 2001 17:52:21 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Fri Aug 17 17:52:15 2001 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 17 Aug 2001 17:45:49 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008BE7@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] IPsec, IKE, MIPv6 and concensus Date: Fri, 17 Aug 2001 17:52:14 +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: > > 2. There are some issues to be resolved if IPsec is to be used. > Mainly this is related to the recent discussions on IPsec selectors > and their granularity. > > => there are two extra issues: > - the authentication/authorization problem and the lack of a global PKI > (not a real IPsec problem) > - the cost/performance of using IPsec (this seems more a IKE problem > than a general IPsec problem IMHO but do we agree about that?) > => I do. > Before London, we agreed that (2) can be solved in 2 different ways: > > A. Use a new Ext Header value for MIPv6 BUs. This will not > involve any modifications to the IPsec implementations. > > => note this extension header must be final (and of course UDP with > a well known port does the job in 256 time cheaper way :-). > => Sure. I was just trying to minimise the impct on MIPv6 implementations. Since everything is already Kernel based. Thanks, Hesham > Of course both A and B rely on eliminating piggybacking of the BUs. > > => Yeh! > > Problem (1) is addressed by several proposals. Needless to say that > 1 and 2 are not dependant on each other (or need not be). > > So the questions that should be answered IMO are: > > 1. Do we want to completely disallow the use of IKE ? > > => no, if we have already a phase 1 it will be stupid to do > something different than a phase 2 to get SAs. > > 2. Do we want to completely disallow the use of IPsec ? > > => please don't! > > I guess based on the WG concensus this should be reflected > in the draft so we can get on with our implementations. > > What do people think ? > > => see above. > > My answer to both questions is No. I do believe that there will > be cases where strong authentication will be required. Since > there are ways of allowing the use of both IKE (as an option) > and IPsec (whether its AH or ESP) then I don't see why we can't > reuse them. > > => I agree. > > Regards > > Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 17 12:04:25 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06571 for ; Fri, 17 Aug 2001 12:04: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 KAA29543; Fri, 17 Aug 2001 10:05:15 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA12527; Fri, 17 Aug 2001 08:46:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7HFjNN24159 for mobile-ip-dist; Fri, 17 Aug 2001 08:45:23 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7HFjJL24152 for ; Fri, 17 Aug 2001 08:45:19 -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 IAA21080 for ; Fri, 17 Aug 2001 08:45:19 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA12592 for ; Fri, 17 Aug 2001 09:45:14 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.5/8.11.5) with ESMTP id f7HFjHx01180 for ; Fri, 17 Aug 2001 17:45:17 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id RAA08503 for ; Fri, 17 Aug 2001 17:45:17 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id f7HFjGl12967 for ; Fri, 17 Aug 2001 17:45:16 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200108171545.f7HFjGl12967@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] IPsec, IKE, MIPv6 and concensus In-reply-to: Your message of Thu, 16 Aug 2001 23:20:19 +0200. <034BEFD03799D411A59F00508BDF754603008BCA@esealnt448.al.sw.ericsson.se> Date: Fri, 17 Aug 2001 17:45:16 +0200 X-Virus-Scanned: by amavisd-milter (http://www.amavis.org/) at laposte.enst-bretagne.fr Sender: owner-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: During the meeting Phil had asked me to write something up to describe the problem with IPsec usage and some suggestions. Obviously as we all know (or some of us) Mike Thomas already wrote a draft for ESP, also Pekka sent a very long mail on the general topic, so I'm not sure if a draft would add more to what we discussed. Therefore I thought perhaps getting some concensus on IPsec usage would be a good idea. First let me summarise briefly the two problems we're having: 1. Relying on IKE only as a key exchange mechanism is not acceptable (This was discussed several times and I think we all agree on this assumption) 2. There are some issues to be resolved if IPsec is to be used. Mainly this is related to the recent discussions on IPsec selectors and their granularity. => there are two extra issues: - the authentication/authorization problem and the lack of a global PKI (not a real IPsec problem) - the cost/performance of using IPsec (this seems more a IKE problem than a general IPsec problem IMHO but do we agree about that?) Before London, we agreed that (2) can be solved in 2 different ways: A. Use a new Ext Header value for MIPv6 BUs. This will not involve any modifications to the IPsec implementations. => note this extension header must be final (and of course UDP with a well known port does the job in 256 time cheaper way :-). B. Add some text to the draft to explain that all implementations for MNs and CNs (receiving BUs only) MUST increase the granularity of their IPsec implementations to search for the BU option instead of relying on the nxt Header value only. => we should push this idea for ICMPv6 first and when the door will be open come back... Of course both A and B rely on eliminating piggybacking of the BUs. => Yeh! Problem (1) is addressed by several proposals. Needless to say that 1 and 2 are not dependant on each other (or need not be). So the questions that should be answered IMO are: 1. Do we want to completely disallow the use of IKE ? => no, if we have already a phase 1 it will be stupid to do something different than a phase 2 to get SAs. 2. Do we want to completely disallow the use of IPsec ? => please don't! I guess based on the WG concensus this should be reflected in the draft so we can get on with our implementations. What do people think ? => see above. My answer to both questions is No. I do believe that there will be cases where strong authentication will be required. Since there are ways of allowing the use of both IKE (as an option) and IPsec (whether its AH or ESP) then I don't see why we can't reuse them. => I agree. Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 17 12:23:59 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07283 for ; Fri, 17 Aug 2001 12:23: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 KAA24253; Fri, 17 Aug 2001 10:24:54 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA01826; Fri, 17 Aug 2001 09:24:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7HGNjx24619 for mobile-ip-dist; Fri, 17 Aug 2001 09:23:45 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7HGNfL24612 for ; Fri, 17 Aug 2001 09:23:41 -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 JAA28638; Fri, 17 Aug 2001 09:23:41 -0700 (PDT) Message-Id: <200108171623.JAA28638@heliopolis.eng.sun.com> Date: Fri, 17 Aug 2001 09:23:33 -0700 (PDT) From: James Kempf Subject: Re: [mobile-ip] Mobile Routers support without optimization To: James.Kempf@Sun.COM, Erik.Nordmark@eng.sun.com Cc: Erik.Nordmark@eng.sun.com, mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 4Cuf7l1KSs6pJhU0JRxFFQ== 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, Thanx for your reply. I'm trying to wrap my mind around this problem by looking at the simplest case. The general case seems to escalate somewhat rapidly in complexity. >A PAN is an IP link. There is an IP router between the PAN and the rest >of the network. >Thus the devices on the PAN (other than the router) never connect directly >to any other link - they always go through the router. > >If that is what you are saying then, from my IP centric view of the world, >I think that is a very reasonable view of a PAN. In fact it is the view >I'd prefer. > Right, but what I was trying to say is that there is another interface, either wireless (like 802.11 or wCDMA) connecting the device to the wired network. So the device acts either as a multihomed host or a router, with the PAN/Bluetooth interface on one side and the WLAN/WAN interface it the Internet on the other. The point I think I was trying to make is that the PAN network is strictly a leaf, i.e. there is no other router somewhere routing out of the PAN network into the Internet. >> In that case, as Mattias suggested, a NAT on the PAN side would work >> just fine (yes, I know NATs are evil, but they are a practical, >> short term solution that should be discussed). > >Whoa - what a can of worms. Should we really dive into that one? > Well, maybe not. :-) But I think we need to look at it just for the sake of argument. I'm not advocating that it be accepted, just that we examine the case. >NAT has nothing inherently to do with PANs - this argument is no >different than NAT being useful in a home environment. If the PAN network is a leaf network and the devices are client only (as you point out below), then maybe it's a possible solution. >And NAT assumes that the devices on the PAN are client-only i.e. they >only initiate communication. >I for sure want the model to allow devices on the PAN to be able to >do peer-to-peer communication with other devices elsewhere in the network >i.e. allowing other nodes to connect to the devices in my PAN. > That is a concern. An advantage of a NAT-like solution (I'm playing devil's advocate here) is that it allows the devices behind the PAN to keep their CoA while the multihomed host/mobile router moves. Additonally, the NAT can do route optimization with CNs, and traffic from the PAN network is routable directly to the CN (i.e. not back through the home network), so no triangle routing. The disadvantage, as you point out, is you can't do push without special hacks, if then. A simple alternative, if I understood your previous email correctly, is to have the PAN addresses globally routable through the home subnet but don't do route optimization to the CN. That would require a tunnel back through the HA for packets to the PAN because the PAN network prefix wouldn't be in the visited subnet routing tables and therefore packets with PAN network prefixes may be subject to ingress filtering. Similarly, incoming packets to the PAN would need to be routed through the home network, resulting in quadralateral routing. The advantage is that push would be possible without special hacks. Packets to the WAN/WLAN interface, presuming the device is a multihomed host, could still benefit from route optimization however. Are there any other advantages/disadvantages that I am missing? Perhaps there is another solution? It helped me alot in this simple case to think of the mobile device as a multihomed host instead of a router (actually, I think that may be more accurate anyway if the device is a cell phone with a Bluetooth interface) because it allowed me to avoid having to think about the effects on the routing protocols in the visited network. jak From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 17 13:33:47 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09265 for ; Fri, 17 Aug 2001 13:33: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 LAA21615; Fri, 17 Aug 2001 11:34: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 KAA17439; Fri, 17 Aug 2001 10:34:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7HHXTO24894 for mobile-ip-dist; Fri, 17 Aug 2001 10:33:29 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7HHXPL24887 for ; Fri, 17 Aug 2001 10:33:25 -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 KAA17200 for ; Fri, 17 Aug 2001 10:33:27 -0700 (PDT) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA12538 for ; Fri, 17 Aug 2001 11:33:40 -0600 (MDT) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate2.mot.com (motgate2 2.1) with ESMTP id KAA23797 for ; Fri, 17 Aug 2001 10:32:02 -0700 (MST)] Received: [from m-il06-r2.mot.com (m-il06-r2.mot.com [129.188.137.24]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id KAA28533 for ; Fri, 17 Aug 2001 10:32:01 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r2.mot.com with ESMTP; Fri, 17 Aug 2001 12:31:54 -0500 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 280582ECAC; Fri, 17 Aug 2001 19:31:25 +0200 (CEST) To: mobile-ip@sunroof.eng.sun.com Cc: James.Kempf@Sun.COM, Erik.Nordmark@eng.sun.com Subject: Re: [mobile-ip] Mobile Routers support without optimization References: <200108171623.JAA28638@heliopolis.eng.sun.com> From: Alexandru Petrescu Date: 17 Aug 2001 19:31:59 +0200 In-Reply-To: <200108171623.JAA28638@heliopolis.eng.sun.com> Message-Id: Lines: 28 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: James Kempf writes: > An advantage of a NAT-like solution (I'm playing devil's advocate > here) is that it allows the devices behind the PAN to keep their CoA > while the multihomed host/mobile router moves. You say "keep" so it might mean the Home Address, not the CoA? NAT would disallow not only traffic from CN to MNN but also from HA to MNN, right? Or you see traffic from HA to MNN as being tunnelled (through MR)? > Additonally, the NAT can do route optimization with CNs, and traffic > from the PAN network is routable directly to the CN (i.e. not back > through the home network), so no triangle routing. What if the CN is itself behind an MR-NAT? > It helped me alot in this simple case to think of the mobile device > as a multihomed host instead of a router (actually, I think that may > be more accurate anyway if the device is a cell phone with a > Bluetooth interface) because it allowed me to avoid having to think > about the effects on the routing protocols in the visited network. Right, there are many names under which this moving devices could be called and that would put less requirements on its behaviour, than calling it router. Alex From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 17 14:43:13 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12298 for ; Fri, 17 Aug 2001 14:43: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 LAA14738; Fri, 17 Aug 2001 11:42:24 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA21900; Fri, 17 Aug 2001 10:53:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7HHqDu25113 for mobile-ip-dist; Fri, 17 Aug 2001 10:52:13 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7HHq9L25106 for ; Fri, 17 Aug 2001 10:52:09 -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 KAA02742; Fri, 17 Aug 2001 10:52:11 -0700 (PDT) Message-Id: <200108171752.KAA02742@heliopolis.eng.sun.com> Date: Fri, 17 Aug 2001 10:52:03 -0700 (PDT) From: James Kempf Subject: Re: [mobile-ip] Mobile Routers support without optimization To: mobile-ip@sunroof.eng.sun.com, petrescu@crm.mot.com Cc: James.Kempf@Sun.COM, Erik.Nordmark@eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: GGup/eu2ADaC7+sL1emwjw== 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: Alex, >> An advantage of a NAT-like solution (I'm playing devil's advocate >> here) is that it allows the devices behind the PAN to keep their CoA >> while the multihomed host/mobile router moves. > >You say "keep" so it might mean the Home Address, not the CoA? > No, I meant the address on the PAN subnet. I'm assuming here that the devices on the PAN subnet are not MNs in the MIP sense, or, at least, that they are not going to move even if they are MIP capable. It's a very limited case. >NAT would disallow not only traffic from CN to MNN but also from HA to >MNN, right? Or you see traffic from HA to MNN as being tunnelled >(through MR)? > Yes, that's right, but the devices don't need to talk to an HA (as above). >> Additonally, the NAT can do route optimization with CNs, and traffic >> from the PAN network is routable directly to the CN (i.e. not back >> through the home network), so no triangle routing. > >What if the CN is itself behind an MR-NAT? > Hmmm, difficult. Needs more thought. There is a group working on the problem of NATs around CNs and HAs, perhaps the solution will fall out of that. There is a third solution which came out of your previous email, namely that the mobile multihomed host/mobile router does route optimization with the CN but the CN tunnels traffic for the PAN subnet through the MMH/MR. So the MMH is acting like a (dare I say it?) MIPv4 FA. In this case, you reduce the extent of the legs on the quadralaterial route, since the tunnel to/from the mobile subnet is through the MMH, which is probably a lot closer to the mobile subnet than the HA. jak From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 17 15:16:49 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13158 for ; Fri, 17 Aug 2001 15:16: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 NAA09312; Fri, 17 Aug 2001 13:17: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 MAA28040; Fri, 17 Aug 2001 12:17:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7HJEIg25521 for mobile-ip-dist; Fri, 17 Aug 2001 12:14:18 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7HJEFL25514 for ; Fri, 17 Aug 2001 12:14:15 -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 MAA06921; Fri, 17 Aug 2001 12:13:40 -0700 (PDT) Message-Id: <200108171913.MAA06921@heliopolis.eng.sun.com> Date: Fri, 17 Aug 2001 12:13:32 -0700 (PDT) From: James Kempf Subject: Re: [mobile-ip] Mobile Routers support without optimization To: James.Kempf@sun.com, petrescu@crm.mot.com Cc: mobile-ip@sunroof.eng.sun.com, Erik.Nordmark@eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Xy1KYR23p9BO8U1TRQmQbg== 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: Alex, >> There is a third solution which came out of your previous email, >> namely that the mobile multihomed host/mobile router does route >> optimization with the CN but the CN tunnels traffic for the PAN >> subnet through the MMH/MR. > >Gee, I thought _you_ had this in mind when writing previous messages. > >Also, tunnelling could mean tunnelling, or routing heading? > The point is to defeat any ingress filtering on the visited subnet. If ingress filtering is done on the destination address without reference to the route headers, then it would have to be a full-fledged tunnel. If the ingress filter checks the route headers before discarding the packet, route headers can be used. Is this specified anywhere? I imagine it is the kind of thing that might be left up to system administrators as policy, but not sure. The only question is whether there needs to be any change to the BU. I don't think an 'R' flag is enough, and, besides, draft-ietf-mobileip-ipv6-13.txt reserves that only for HA BUs only. One would at least need both the MMH/MR's new CoA and the subnet prefix of the subnet behind the MR. I suppose we could define a prefix extension to the BU, which, when present, indicated that all traffic to that prefix from CN would have to be tunnelled through the MMH/MR's CoA. The other question is, of course, security, but I don't see any difference between this case and the case of a mobile host (again, which is why calling it a MMH seems more to the point than calling it a MR). The MMH is controls all the traffic going to the leaf subnet. jak From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 17 15:22:19 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13276 for ; Fri, 17 Aug 2001 15:22: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 MAA29127; Fri, 17 Aug 2001 12:18: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 LAA05823; Fri, 17 Aug 2001 11:58:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7HIvvc25385 for mobile-ip-dist; Fri, 17 Aug 2001 11:57:57 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7HIvrL25378 for ; Fri, 17 Aug 2001 11:57: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 LAA02454 for ; Fri, 17 Aug 2001 11:57:53 -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 MAA14620 for ; Fri, 17 Aug 2001 12:58:07 -0600 (MDT) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate.mot.com (motgate 2.1) with ESMTP id LAA05000 for ; Fri, 17 Aug 2001 11:57:51 -0700 (MST)] Received: [from m-il06-r4.mot.com (m-il06-r4.mot.com [129.188.137.196]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id LAA21785 for ; Fri, 17 Aug 2001 11:57:51 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r4.mot.com with ESMTP; Fri, 17 Aug 2001 13:57:49 -0500 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 50F9E2ECAC; Fri, 17 Aug 2001 20:57:15 +0200 (CEST) To: James Kempf Cc: mobile-ip@sunroof.eng.sun.com, Erik.Nordmark@eng.sun.com Subject: Re: [mobile-ip] Mobile Routers support without optimization References: <200108171752.KAA02742@heliopolis.eng.sun.com> From: Alexandru Petrescu Date: 17 Aug 2001 20:57:50 +0200 In-Reply-To: <200108171752.KAA02742@heliopolis.eng.sun.com> Message-Id: Lines: 41 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: James Kempf writes: > No, I meant the address on the PAN subnet. I'm assuming here that > the devices on the PAN subnet are not MNs in the MIP sense, or, at > least, that they are not going to move even if they are MIP > capable. It's a very limited case. PErfect for our discussion, this is what I have in mind too. > Hmmm, difficult. Needs more thought. There is a group working on > the problem of NATs around CNs and HAs, perhaps the solution > will fall out of that. Aha, eager to see it, thanks for indication. > There is a third solution which came out of your previous email, > namely that the mobile multihomed host/mobile router does route > optimization with the CN but the CN tunnels traffic for the PAN > subnet through the MMH/MR. Gee, I thought _you_ had this in mind when writing previous messages. Also, tunnelling could mean tunnelling, or routing heading? > So the MMH is acting like a (dare I say it?) MIPv4 FA. Well, yes, there are similarities between MMH/MR and FA's, except they move. More generally, Thierry and HMIPv6 authors see a similarity between MMH and MAP extended mode. When thinking about MMH we can take additional requirements that stem from the elimination of FA and the arguments against MAP. Thanks for your useful insights, Alex [NAT: in my understanding, an address behind a NAT is not routable on the Internet and it's reserved as such. An address behind an MR should be routable at least between CN and HA. Maybe in our context the MR should use a sort of address translation (could be tunnelling), maybe should not call it NAT] From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 17 15:42:47 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13887 for ; Fri, 17 Aug 2001 15:42:47 -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 NAA25754; Fri, 17 Aug 2001 13:43: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 KAA19630; Fri, 17 Aug 2001 10:43:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7HHgiN24999 for mobile-ip-dist; Fri, 17 Aug 2001 10:42:44 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7HHgfL24992 for ; Fri, 17 Aug 2001 10:42:41 -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 KAA02321 for ; Fri, 17 Aug 2001 10:42:42 -0700 (PDT) Message-Id: <200108171742.KAA02321@heliopolis.eng.sun.com> Date: Fri, 17 Aug 2001 10:42:35 -0700 (PDT) From: James Kempf Subject: Re: [mobile-ip] Mobile Routers support without optimization To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: nen1PIP1wPrGaoBZVpHEdw== 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 Alex, >The triangular routing would be eliminated by MR's telling CN's an >association of the form (CoA of MR, MR-subnet prefix). And not by >telling CN's extrapolated associations like (CoP, Home Prefix). > I can't see how triangle routing to hosts behind the MR can be eliminated unless their addresses are routable within the visited subnet. Otherwise, the visited subnet will reject incoming packets because the destination address is not topologically meaningful. I suppose traffic to/from the CN from hosts on the mobile subnet could tunnel through the MR's CoA. That would avoid the CN having to send packets back through the home subnet, and vice versa, essentially quadrelateral routing, which is what I mentioned in my response to Erik's message. Was that what you were thinking of? >As I see it, MR is not NAT because its subnet prefix is >Internet-routable. By "triangular routing", but still routable. > >Also, when CN has learned the MR CoA, it would send a packet to MNN by >putting MR's CoA and MNN's address into a routing header and off it >goes over the net, through MR and to MNN. With a NAT you can't reach >nodes behind it whatever you try. > OK, it does seem to be what you are thinking of! Yes, I agree that a tunnel from CN through MR would allow route optimization and thus eliminate quadrilaterial routing. A NAT would avoid the tunnel, but I think a tunnel is a small price to pay in this case. It sounds to me like we may be converging on an acceptable solution for this very specific, limited problem of MR (which I think is more like a mobile multihomed host). jak From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 17 16:02:41 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14301 for ; Fri, 17 Aug 2001 16:02: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 OAA09426; Fri, 17 Aug 2001 14:03:42 -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 LAA23957; Fri, 17 Aug 2001 11:03:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7HI2R925201 for mobile-ip-dist; Fri, 17 Aug 2001 11:02:27 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7HI2NL25194 for ; Fri, 17 Aug 2001 11:02: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 LAA23776 for ; Fri, 17 Aug 2001 11:02:25 -0700 (PDT) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA04092 for ; Fri, 17 Aug 2001 12:02: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 LAA12022 for ; Fri, 17 Aug 2001 11:02:23 -0700 (MST)] Received: [from m-il06-r2.mot.com (m-il06-r2.mot.com [129.188.137.24]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id LAA17587 for ; Fri, 17 Aug 2001 11:02:23 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r2.mot.com with ESMTP for mobile-ip@sunroof.eng.sun.com; Fri, 17 Aug 2001 13:02:10 -0500 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id CF72F2ECAC for ; Fri, 17 Aug 2001 20:01:42 +0200 (CEST) To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile Routers support without optimization References: <3B73A9C9.38C82250@Kniveton.com> From: Alexandru Petrescu Date: 17 Aug 2001 20:02:17 +0200 In-Reply-To: <3B73A9C9.38C82250@Kniveton.com> Message-Id: Lines: 17 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: "T.J. Kniveton" writes: > There was some concern about how to properly authenticate > authorization for the ability to change subnet routing > information. For instance, it seems to be trickier to know when to > allow a binding for a /4 prefix than for a /128 prefix (host) on a > correspondent node. This opens up a nasty redirection attack on any > correspondent node supporting mobile routers. MNN-away-from-home sends packet to CN through MR. MR decides it should send a BU to CN and it sends a BW (B Warning) providing its MR-CoA, the MR-subnet prefix, the MR Home Address and the MNN home address (must fit into MR-subnet prefix). The CN then sends a sort of request to MNN home address that gets to the true HA and that says "yes, MNN home address is under the MR; yes, MR-subnet prefix is his". At that moment only CN updates its cache. Alex From owner-mobile-ip@sunroof.eng.sun.com Sat Aug 18 00:40:01 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21812 for ; Sat, 18 Aug 2001 00:40: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 HAA23128; Fri, 17 Aug 2001 07:01:38 -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 FAA28369; Fri, 17 Aug 2001 05:36:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7HCZbT23500 for mobile-ip-dist; Fri, 17 Aug 2001 05:35:37 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7HCZXL23493 for ; Fri, 17 Aug 2001 05:35:33 -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 FAA26914 for ; Fri, 17 Aug 2001 05:35:34 -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 GAA19500 for ; Fri, 17 Aug 2001 06:35:29 -0600 (MDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (motgate 2.1) with ESMTP id FAA12486 for ; Fri, 17 Aug 2001 05:35:33 -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 FAA02778 for ; Fri, 17 Aug 2001 05:35:32 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r3.mot.com with ESMTP; Fri, 17 Aug 2001 07:35:30 -0500 Received: from crm.mot.com (nero.crm.mot.com [140.101.173.36]) by thorgal.crm.mot.com (Postfix) with ESMTP id 8E6202ECAC; Fri, 17 Aug 2001 14:34:58 +0200 (CEST) Message-Id: <3B7D0F8B.A5D49572@crm.mot.com> Date: Fri, 17 Aug 2001 14:35:23 +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: Erik Nordmark , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile Routers support without optimization References: Content-Type: multipart/mixed; boundary="------------1B27D71BE661CCE275DCB0ED" Sender: owner-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. --------------1B27D71BE661CCE275DCB0ED Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Erik Nordmark wrote: > > > > So how do you handle the case I'm trying to explain above? > > > > draft-ernst-mobileip-v6-network-02.txt section 5. > > I didn't see anything in that section saying how a random CN > can trust the prefix privided by the MR in the BU > except bythe CN blindly trusting the HA. You are right, thank you for pointing out that possible attack. Section 5 will be updated soon to provide a security context that will no longer be dependent on HA certification. Note however that the authorization problem you raised here does not necessarily lead to "sending packets to all IP addresses in the prefix and seeing that you get a response back from the HA". We are currently checking two other solutions that should be fittable to solve the problem without extra messaging. Alexis. --------------1B27D71BE661CCE275DCB0ED 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 --------------1B27D71BE661CCE275DCB0ED-- From owner-mobile-ip@sunroof.eng.sun.com Sat Aug 18 02:52:47 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09028 for ; Sat, 18 Aug 2001 02:52:46 -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 DAA22434; Fri, 17 Aug 2001 03:24: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 CAA06012; Fri, 17 Aug 2001 02:09:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7H98CH22827 for mobile-ip-dist; Fri, 17 Aug 2001 02:08:12 -0700 (PDT) Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.179.15]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7H988L22820 for ; Fri, 17 Aug 2001 02:08:08 -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 f7H983202440; Fri, 17 Aug 2001 11:08:03 +0200 (MET DST) Date: Fri, 17 Aug 2001 11:05:12 +0200 (CEST) From: Erik Nordmark Subject: Re: [mobile-ip] Mobile Routers support without optimization To: Alexandru Petrescu Cc: mobile-ip@sunroof.eng.sun.com, Thierry Ernst In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > I'm not sure how easy this will be since it's used in the binding > cache too and from there into the modified Router Advertisement. It's use in the binding cache is solely to be able to set the R bit in the Neighbor Advertisements to non-zero, which is only needed when the MN is a MR. The modifications to the RA (section 6.2) has a unrelated 'R' bit which has nothing to do with the 'R' bit in the BU. The former is just a way to indicate that the prefix info option, often in addition to containing a prefix, also contains a full (global or site-local) address of the sending router. Erik > The latter should be kept, I think, being used by other things than > the R bit from cache. > > Alex > From owner-mobile-ip@sunroof.eng.sun.com Sat Aug 18 03:04:25 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09092 for ; Sat, 18 Aug 2001 03:04: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 DAA24331; Fri, 17 Aug 2001 03:40: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 CAA13426; Fri, 17 Aug 2001 02:25:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7H9Oqn22976 for mobile-ip-dist; Fri, 17 Aug 2001 02:24:52 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7H9OnL22969 for ; Fri, 17 Aug 2001 02:24:49 -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 CAA13321 for ; Fri, 17 Aug 2001 02:24:54 -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 CAA25095 for ; Fri, 17 Aug 2001 02:24:53 -0700 (PDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (motgate 2.1) with ESMTP id CAA24301 for ; Fri, 17 Aug 2001 02:24:53 -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 CAA21075 for ; Fri, 17 Aug 2001 02:24:52 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r3.mot.com with ESMTP; Fri, 17 Aug 2001 04:24:41 -0500 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id A482E2ECAC; Fri, 17 Aug 2001 11:24:18 +0200 (CEST) To: Erik Nordmark Cc: mobile-ip@sunroof.eng.sun.com, Thierry Ernst Subject: Re: [mobile-ip] Mobile Routers support without optimization References: From: Alexandru Petrescu Date: 17 Aug 2001 11:24:48 +0200 In-Reply-To: Message-Id: Lines: 9 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: Erik Nordmark writes: > The modifications to the RA (section 6.2) has a unrelated 'R' bit > which has nothing to do with the 'R' bit in the BU. I was thinking that HA should respond to RS's with R bit set if the MN is away and is a router. That RA's R bit would come from R of binding cache. It's not specified, but I thought that should be specified. Alex From owner-mobile-ip@sunroof.eng.sun.com Sat Aug 18 03:14:13 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09168 for ; Sat, 18 Aug 2001 03:14: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 DAA23869; Fri, 17 Aug 2001 03:36: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 CAA13064; Fri, 17 Aug 2001 02:21:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7H9KwX22935 for mobile-ip-dist; Fri, 17 Aug 2001 02:20:58 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7H9KsL22928 for ; Fri, 17 Aug 2001 02:20: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 CAA14398 for ; Fri, 17 Aug 2001 02:20: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 CAA23815 for ; Fri, 17 Aug 2001 02:20:58 -0700 (PDT) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate2.mot.com (motgate2 2.1) with ESMTP id CAA28823 for ; Fri, 17 Aug 2001 02:20:57 -0700 (MST)] Received: [from m-il06-r1.mot.com (m-il06-r1.mot.com [129.188.137.193]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id CAA00018 for ; Fri, 17 Aug 2001 02:20:57 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r1.mot.com with ESMTP; Fri, 17 Aug 2001 04:20:56 -0500 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 8C9F72ECAC; Fri, 17 Aug 2001 11:20:23 +0200 (CEST) To: mobile-ip@sunroof.eng.sun.com Cc: Thierry Ernst Subject: Re: [mobile-ip] Mobile Routers support without optimization References: <034BEFD03799D411A59F00508BDF754603008BC9@esealnt448.al.sw.ericsson.se> From: Alexandru Petrescu Date: 17 Aug 2001 11:20:53 +0200 In-Reply-To: <034BEFD03799D411A59F00508BDF754603008BC9@esealnt448.al.sw.ericsson.se> 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: "Hesham Soliman (ERA)" writes: > > I'm not sure how easy this will be since it's used in the binding > > cache too and from there into the modified Router Advertisement. > > > => Which router advertisement ? I think you're talking about > a different R bit maybe ? Yes, I was talking about a different R bit. Fact is that there are 4 R bits: in BU, in proxy NA, in modified RA and in binding cache. The R's in BU and binding cache are related to R in proxy NA and to R in RA. While the R in proxy NA comes only from the R in binding cache, the R in RA can come from other places. Thus I think the R bits in BU and binding cache could be removed. I was tempted to suggest removal of R from modified RA but that is also used for building home agent lists and something else. Also, I'm wondering if it's good to suggest "removal" or it's better to copy paste it into a new draft and polish that draft. Alex From owner-mobile-ip@sunroof.eng.sun.com Sat Aug 18 03:17:51 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09217 for ; Sat, 18 Aug 2001 03:17: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 BAA09048; Fri, 17 Aug 2001 01:56: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 AAA05832; Fri, 17 Aug 2001 00:47:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7H7jbQ22430 for mobile-ip-dist; Fri, 17 Aug 2001 00:45:37 -0700 (PDT) Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.179.15]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7H7jXL22423 for ; Fri, 17 Aug 2001 00:45: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 f7H7hY224329; Fri, 17 Aug 2001 09:43:34 +0200 (MET DST) Date: Fri, 17 Aug 2001 09:40:43 +0200 (CEST) From: Erik Nordmark Subject: Re: [mobile-ip] Mobile Routers support without optimization To: Alexandru Petrescu Cc: Erik Nordmark , mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > I made the distinction HA - router mainly to stress that HA can be > physically separated of the AR and that it is not likely to > participate in route maintenance protocols. But I might have it all > wrong, thanks for helping me understanding these issues. I recognize > my ignorance in my first appreciation. Yes but running routing protocols is not required by all routers. And I agree that HA and AR are likely to be different - in some cases they might be placed in very different parts of the network. > Why isn't Mobile IPv6 spec requiring the HA to join all-routers mc > address? Good questions. Perhaps it should for consistency. Joining all-routers would definitely be required if the router was to send router advertisements which brings us to: > Why isn't Mobile IPv6 spec requiring the HA to send router > advertisements? [*] I don't think this needs to be mandatory for routers in general. For instance, for routers which are only attached to links with other routers (and not hosts) there is no use in sending RAs. Also, RFC 2461 was written to allow there be routers on the link which do not send RAs but instead are only used by the hosts as a result of another router sending redirects. If a HA is only connected to one "physical" link (in addition to whatever tunnels it has to the served MNs) then its routing cabability will not be very useful for other hosts attched to the physical link. Thus it might not be that useful for it to send RAs on that link. But when the HA is attached to multiple physical links it can very well serve as a "normal" router between those links in addition to its home agent functionality. Thus in such a case it makes more sense for it to send RAs. > Alex > > [*] Well the -13 doesn't require it in 7.3. Requirements for IPv6 > Home Agents, but it does talk about it in 4.1. Basic Operation: > > "This list of home agents is maintained by each home agent on the > home link through use of the Home Agent (H) bit in each home > agent's periodic unsolicited multicast Router Advertisements." Correct. But the router can still "hide" i.e. not be used as a default router by setting the router lifetime to zero. Thus the above logic for when it makes sense to be a default router or not still applies. Erik From owner-mobile-ip@sunroof.eng.sun.com Sat Aug 18 03:25:55 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09260 for ; Sat, 18 Aug 2001 03:25:55 -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 GAA14710; Fri, 17 Aug 2001 06:11:45 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA23313; Fri, 17 Aug 2001 04:53:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7HBqg023354 for mobile-ip-dist; Fri, 17 Aug 2001 04:52:42 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7HBqcL23347 for ; Fri, 17 Aug 2001 04:52: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 EAA23393 for ; Fri, 17 Aug 2001 04:52:39 -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 FAA01816 for ; Fri, 17 Aug 2001 05:52:34 -0600 (MDT) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f7HBqbK00119 for ; Fri, 17 Aug 2001 13:52:37 +0200 (MEST) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id NAA29201; Fri, 17 Aug 2001 13:52:35 +0200 Message-ID: <3B7D0516.69267C9E@era.ericsson.se> Date: Fri, 17 Aug 2001 13:50:46 +0200 From: Mattias Pettersson Organization: Ericsson Research X-Mailer: Mozilla 4.77 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile Routers support without optimization References: <200108161945.MAA23383@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 Alexandru Petrescu wrote: > > James Kempf writes: > > Sorry for sounding totally clueless, but I'm extrapolating what's in > > the BU from what would be in if an MN were to send it. If an MN > > sends it, the BU contains the care of address, which is in the > > foreign network. Extrapolating, the MR would have to send a prefix > > that is in the foreign network. > > Right, this is what I would call CoP (care-of prefix). But I'm still > wondering if there's a need to acquire a CoP and renumber all MNN's > when moving. Keeping the same MR-subnet prefix wherever MR moves can > be done by updating only binding caches of HA's and CN's and not any > routing tables of anyone. Keeping the same MR-subnet prefix also > leads to "binding cache-free" MNN's. Although a beautiful way, I'm afraid such a renumbering is going to be something really heavy. Some ISPs are really reluctant to renumbering, and here we happy Mobile IPv6-people come and suggest mandatory renumbering every 20 second or so... :) > > > The point of the BU in the mobile host case is to tell the HA and CN > > to change its routing to the new address. The point of the BU for a > > MR is presumably to cause a change in the routing tables in subnets > > that are corresponding with host behind the MR, including the home > > network. > > Your extrapolation looks right. With a twist: I would like MR to use > BU like MN/HA/CN use it. That is update binding caches only and not > routing tables. > > > That is, of course, if you want to completely eliminate triange > > routing. > > The triangular routing would be eliminated by MR's telling CN's an > association of the form (CoA of MR, MR-subnet prefix). And not by > telling CN's extrapolated associations like (CoP, Home Prefix). Exactly. Altering the routing tables of the CN is not enough. You would need to use MR prefix-routes in every intermediate router between the CN and MR in order to deliver the packets. Or do you suggest some tunnelling/routing header mechanism? /Mattias From owner-mobile-ip@sunroof.eng.sun.com Sat Aug 18 04:50:11 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09712 for ; Sat, 18 Aug 2001 04:50: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 EAA02742; Fri, 17 Aug 2001 04:49: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 DAA12067; Fri, 17 Aug 2001 03:35:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7HAXWl23124 for mobile-ip-dist; Fri, 17 Aug 2001 03:33:32 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7HAXSL23117 for ; Fri, 17 Aug 2001 03:33:28 -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 DAA12007 for ; Fri, 17 Aug 2001 03:33:28 -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 EAA02644 for ; Fri, 17 Aug 2001 04:33:23 -0600 (MDT) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate2.mot.com (motgate2 2.1) with ESMTP id DAA24773 for ; Fri, 17 Aug 2001 03:33:26 -0700 (MST)] Received: [from m-il06-r2.mot.com (m-il06-r2.mot.com [129.188.137.24]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id DAA19521 for ; Fri, 17 Aug 2001 03:33:26 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r2.mot.com with ESMTP; Fri, 17 Aug 2001 05:33:14 -0500 Received: from crm.mot.com (nero.crm.mot.com [140.101.173.36]) by thorgal.crm.mot.com (Postfix) with ESMTP id 4C06C2ECAC; Fri, 17 Aug 2001 12:32:52 +0200 (CEST) Message-Id: <3B7CF2ED.CBF3611@crm.mot.com> Date: Fri, 17 Aug 2001 12:33:17 +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 Cc: Alexis Subject: Re: [mobile-ip] IPsec, IKE, MIPv6 and concensus References: <034BEFD03799D411A59F00508BDF754603008BCA@esealnt448.al.sw.ericsson.se> Content-Type: multipart/mixed; boundary="------------0986C27A64DF8D725ACD01C9" Sender: owner-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. --------------0986C27A64DF8D725ACD01C9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Hesham Soliman (ERA)" wrote: > > Problem (1) is addressed by several proposals. Needless to say that > 1 and 2 are not dependant on each other (or need not be). > > So the questions that should be answered IMO are: > > 1. Do we want to completely disallow the use of IKE ? No. As long as other solutions of key exchange are retained, we do not need to discard this one. > 2. Do we want to completely disallow the use of IPsec ? No. IMHO we should work to make MIPv6 & IPsec work together (solutions A or B you mentioned). I think that a decision to disallow the use of IPsec would eventually be regretted in a next future. If we envision a world with fully deployed MIPv6 along with IPsec-based VPNs no doubt that a single security standard will be more than desirable. Regards, Alexis. --------------0986C27A64DF8D725ACD01C9 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 --------------0986C27A64DF8D725ACD01C9-- From owner-mobile-ip@sunroof.eng.sun.com Sat Aug 18 05:00:02 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09766 for ; Sat, 18 Aug 2001 05:00: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 GAA18234; Fri, 17 Aug 2001 06:33: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 FAA24925; Fri, 17 Aug 2001 05:13:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7HCCGY23439 for mobile-ip-dist; Fri, 17 Aug 2001 05:12:16 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7HCCCL23432 for ; Fri, 17 Aug 2001 05:12:12 -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 FAA24894 for ; Fri, 17 Aug 2001 05:12: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 FAA17687 for ; Fri, 17 Aug 2001 05:12:12 -0700 (PDT) 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 f7HCCAv07637 for ; Fri, 17 Aug 2001 14:12:11 +0200 (MEST) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id OAA29714; Fri, 17 Aug 2001 14:12:09 +0200 Message-ID: <3B7D09AC.66A68701@era.ericsson.se> Date: Fri, 17 Aug 2001 14:10:20 +0200 From: Mattias Pettersson Organization: Ericsson Research X-Mailer: Mozilla 4.77 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile Routers support without optimization References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Erik Nordmark wrote: > > > In that case, as Mattias suggested, a NAT on the PAN side would work > > just fine (yes, I know NATs are evil, but they are a practical, > > short term solution that should be discussed). > > Whoa - what a can of worms. Should we really dive into that one? So you prefer this Mobile IPv6 can of worms instead? I wouldn't say we are completely clean here either... :) We are a bit more end-to-end, but NAT has obviously been more deployed than Mobile IP and seems to be of some use at least. Sorry for being ironical (or cynical). I don't support NAT, but it could solve a few things here: - No complex trust model, the mobile network will look like a single MN. - No additional support in CNs. - No routing problems at home with other routers. - As the mobile network is maybe very small, it will require little configuration. - If the user wants e2e, he could use the MR. Now, if mobile-ip was moderated, I would have been kicked off this list by now. ;) Should have use my hotmail account... > > NAT has nothing inherently to do with PANs - this argument is no > different than NAT being useful in a home environment. NAT is just a quick short-term solution. But a PAN such as you describe it does have a number of similarities with home environments. > And NAT assumes that the devices on the PAN are client-only i.e. they > only initiate communication. There are ugly tricks for this too. > I for sure want the model to allow devices on the PAN to be able to > do peer-to-peer communication with other devices elsewhere in the network > i.e. allowing other nodes to connect to the devices in my PAN. > > Erik /Mattias From owner-mobile-ip@sunroof.eng.sun.com Sat Aug 18 06:06:53 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10427 for ; Sat, 18 Aug 2001 06:06: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 FAA08902; Fri, 17 Aug 2001 05: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 EAA14845; Fri, 17 Aug 2001 04:17:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7HBFkK23217 for mobile-ip-dist; Fri, 17 Aug 2001 04:15:46 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7HBFgL23210 for ; Fri, 17 Aug 2001 04:15:42 -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 EAA22187 for ; Fri, 17 Aug 2001 04:15:42 -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 EAA29858 for ; Fri, 17 Aug 2001 04:15:41 -0700 (PDT) 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 f7HBFev01184 for ; Fri, 17 Aug 2001 13:15:40 +0200 (MEST) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id NAA28187; Fri, 17 Aug 2001 13:15:38 +0200 Message-ID: <3B7CFC6D.64E29B62@era.ericsson.se> Date: Fri, 17 Aug 2001 13:13:49 +0200 From: Mattias Pettersson Organization: Ericsson Research X-Mailer: Mozilla 4.77 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile Routers support without optimization 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 Alexandru Petrescu wrote: > > I made the distinction HA - router mainly to stress that HA can be > physically separated of the AR and that it is not likely to > participate in route maintenance protocols. But I might have it all > wrong, thanks for helping me understanding these issues. I recognize > my ignorance in my first appreciation. > The HA can very well be separated from the AR (or the gateway router or border router whatever it means). Each link can have any number of routers. One or more of them connects it to the internet. The HA doesn't have to be one of them. A node can have one interface and still be a router. An important aspect of routers is that they can't get their routes by ND autoconfiguration, such as hosts do. They need manual configuration or routing protocols for that. And as concluded earlier, the HA is a router. Sorry, just want to make things clear. /Mattias From owner-mobile-ip@sunroof.eng.sun.com Sat Aug 18 23:30:46 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19793 for ; Sat, 18 Aug 2001 23:30: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 VAA28215; Sat, 18 Aug 2001 21:31: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 UAA27280; Sat, 18 Aug 2001 20:29:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7J3SXk29351 for mobile-ip-dist; Sat, 18 Aug 2001 20:28:33 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7J3SRL29329 for ; Sat, 18 Aug 2001 20:28: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 JAA25045 for ; Sat, 18 Aug 2001 09:10:58 -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 JAA10694 for ; Sat, 18 Aug 2001 09:10:57 -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 f7IGAtK04958 for ; Sat, 18 Aug 2001 18:10:55 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Sat Aug 18 18:10:49 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Sat, 18 Aug 2001 18:10:55 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008BE9@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Erik Nordmark'" Cc: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] IPsec, IKE, MIPv6 and concensus Date: Sat, 18 Aug 2001 18:10: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: > > 1. Relying on IKE only as a key exchange mechanism is not > > acceptable (This was discussed several times and I think we > > all agree on this assumption) > > I think the placement of "only" above can be a source of confusion - > IKE is only ("nothing but") a key exchange mechanism as far as I know. > > Did you really mean > Relying on IKE as the only key exchange mechanism used to secure > Mobile IPv6 is not acceptable ... > => That's what I meant, thanks. > > So the questions that should be answered IMO are: > > Presumably these questions are solely in the context of > securing MIPv6 or perhaps just securing the BUs, or perhaps just securing > the BUs with CNs?. > => Yes only for securing BUs. I wasn't intending to segregate the HA BU from the CN BU. For instance using a MIPv6-specific mechanism to replace IKE can still utilise IPsec for securing the BUs. > I can see folks wanting to use IKE and IPsec to build VPNs to mobile nodes. > Thus I think we need more context in order for folks to agree > what the questions mean. > => Right, so what I meant to say was that : Should we disallow IKE from being "optionally" used ? Should we disallow the use of IPsec at all ? An answer of No to the second question would imply that IPsec will be THE mechanism used for authenticating BUs with any other key exchange mechanism (IKE, BAKE, HA cookies .....etc) Please note that there is no distinction between the HA and CN BUs above. For example you can still use IKE with another CN (if you can establish an SA). It could be a CN that you already know would require strong authentication (eg. a server at your corporate or at your home network). Hesham From owner-mobile-ip@sunroof.eng.sun.com Sun Aug 19 05:43:12 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10444 for ; Sun, 19 Aug 2001 05:43:12 -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 CAA15405; Sun, 19 Aug 2001 02:43: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 CAA29880; Sun, 19 Aug 2001 02:43:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7J9fpr29932 for mobile-ip-dist; Sun, 19 Aug 2001 02:41:52 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7J9fmL29925 for ; Sun, 19 Aug 2001 02:41:48 -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 CAA15346 for ; Sun, 19 Aug 2001 02:41:51 -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 DAA09273 for ; Sun, 19 Aug 2001 03:42:06 -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 f7J9fmv24003 for ; Sun, 19 Aug 2001 11:41:48 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Sun Aug 19 11:41:48 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Sun, 19 Aug 2001 11:41:48 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008BEA@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Mobile Routers support without optimization Date: Sun, 19 Aug 2001 11:41: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: > > > I'm not sure how easy this will be since it's used in the binding > > > cache too and from there into the modified Router Advertisement. > > > > > => Which router advertisement ? I think you're talking about > > a different R bit maybe ? > > Yes, I was talking about a different R bit. > > Fact is that there are 4 R bits: in BU, in proxy NA, in modified RA > and in binding cache. The R's in BU and binding cache are related to > R in proxy NA and to R in RA. While the R in proxy NA comes only from > the R in binding cache, the R in RA can come from other places. > > Thus I think the R bits in BU and binding cache could be removed. > > I was tempted to suggest removal of R from modified RA but that is > also used for building home agent lists and something else. > => I'm getting the list's emails in a strange order but I saw that Erik had already replied to this issue. > Also, I'm wondering if it's good to suggest "removal" or it's better > to copy paste it into a new draft and polish that draft. > => well that implies the removal from the MIPv6 draft anyway. The point is, it's not clear to me what it does in the BU. So putting it in another draft is ok once we know what to do with it. I assume the "other" drat would be addressing a solution for Mobile networks so we can decide whether the R flag is appropriate or something else. Having it in the MIPv6 draft at the moment seems superfluous. Hesham From owner-mobile-ip@sunroof.eng.sun.com Sun Aug 19 17:28:22 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16501 for ; Sun, 19 Aug 2001 17:28: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 OAA03290; Sun, 19 Aug 2001 14:29: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 OAA18847; Sun, 19 Aug 2001 14:28:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7JLRMH01228 for mobile-ip-dist; Sun, 19 Aug 2001 14:27:22 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7JLRIL01221 for ; Sun, 19 Aug 2001 14:27:18 -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 OAA05826 for ; Sun, 19 Aug 2001 14:27:15 -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 PAA28397 for ; Sun, 19 Aug 2001 15:27: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 f7JLRPn20373 for ; Sun, 19 Aug 2001 14:27: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 ACW00152; Sun, 19 Aug 2001 14:27:12 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA18971; Sun, 19 Aug 2001 14:27:12 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15232.12080.628273.833183@thomasm-u1.cisco.com> Date: Sun, 19 Aug 2001 14:27:12 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] IPsec, IKE, MIPv6 and concensus In-Reply-To: <3B7C4A7B.2DCECEDC@iprg.nokia.com> References: <034BEFD03799D411A59F00508BDF754603008BCA@esealnt448.al.sw.ericsson.se> <3B7C4A7B.2DCECEDC@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 Soliman (ERA)" wrote: > > > Problem (1) is addressed by several proposals. Needless to say that > > 1 and 2 are not dependant on each other (or need not be). > > > > So the questions that should be answered IMO are: > > > > 1. Do we want to completely disallow the use of IKE ? > > NO. > > > > > 2. Do we want to completely disallow the use of IPsec ? > > YES. use authentication data suboption for the BU. Since this requires a new DOI for IKE, your answers are mutually contradictory. Mike From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 20 00:46:14 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21326 for ; Mon, 20 Aug 2001 00:46: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 WAA09733; Sun, 19 Aug 2001 22:45: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 VAA05960; Sun, 19 Aug 2001 21:44:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7K4hX402071 for mobile-ip-dist; Sun, 19 Aug 2001 21:43:33 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7K4hTL02064 for ; Sun, 19 Aug 2001 21:43:29 -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 VAA05878 for ; Sun, 19 Aug 2001 21:43:31 -0700 (PDT) Received: from telecom.samsung.co.kr ([165.213.221.4]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA29391 for ; Sun, 19 Aug 2001 21:43:29 -0700 (PDT) Received: from cychong (a22416 [165.213.224.16]) by telecom.samsung.co.kr (8.9.3/8.9.3) with SMTP id NAA15833 for ; Mon, 20 Aug 2001 13:46:05 +0900 (KST) Message-ID: <005d01c12933$528a70c0$10e0d5a5@cychong> From: "Chae-yong Chong" To: References: <697DAA22C5004B4596E033803A7CEF440861EC@daebe007.NOE.Nokia.com> <4.3.1.2.20010813170049.02eadf08@mail1.qualcomm.com> Subject: Re: [mobile-ip] RFC2002bis Date: Mon, 20 Aug 2001 13:48:13 +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 f7K4hTL02065 Sender: owner-mobile-ip@sunroof.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 I'm late to reply your message -_- However, could you explain about your statement "a fact that the current IS835 deployment in Korea does not support Moblie IP"? Why do you think so? As far as I know, the Mobile IP in SKT/KTF is just working. They only are lack of Mobile Node software. Chae-yong ----- Original Message ----- From: "Marcello Lioy" To: ; Sent: Tuesday, August 14, 2001 12:03 AM Subject: Re: [mobile-ip] RFC2002bis > At 01:16 8/13/2001, Chae-yong Chong wrote: > >Hi. > > > >This is just an information for you. > > > >The IS-835 network is already deployed in Korea on a commercial basis. > >If you asked that how many subscribers are using Mobile IP service, I am > >sorry not to give you an exact answer. That answer could be given by > >some guys of Operators, SK Telecom ro KTF :-) > >I think you all just consider the situation of North American. :-( > > I know for a fact that the current IS835 deployment in Korea does not > support Mobile IP - this will change in short order, as the infrastructure > will be upgraded, when the new mobiles will have support for it. > > I did not mean to disregard Korea - It is just that the only large scale > M.IP deployment that was immanent was that in the U.S. > > > >As far as I know, there is no commercial product for > >Mobile Node software. Okay. I agree that you could assume that > >the current deployment in Korea could be regarded to a nothing. > >(If the number of Mobile IP service subscriber is just trivial) > >I just write this message to let you know that IS-835 is ALREADY deployed > >somewhere :-) > > > >Chae-yong > > > > > The IS-835 network is not yet deployed on a commercial basis. And you > > > seem to agree that the above fixes would be good for the spec. Would > > > make sense to consider making these changes now than later when it is > > > deployed. > > > > > > >----------------------------------- > > > >Marcello (Wandering through France) > > > > > > > > > > -Basavaraj > > > > > > > > ----------------------------------- > Marcello (Wandering through France) > > From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 20 04:16:11 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09271 for ; Mon, 20 Aug 2001 04:16: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 BAA17541; Mon, 20 Aug 2001 01: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 BAA21014; Mon, 20 Aug 2001 01:16:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7K8E5202373 for mobile-ip-dist; Mon, 20 Aug 2001 01:14:05 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7K8E2L02366 for ; Mon, 20 Aug 2001 01:14: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 BAA12077 for ; Mon, 20 Aug 2001 01:14:04 -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 CAA00612 for ; Mon, 20 Aug 2001 02:13:59 -0600 (MDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (motgate 2.1) with ESMTP id BAA17962 for ; Mon, 20 Aug 2001 01:14:02 -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 BAA05560 for ; Mon, 20 Aug 2001 01:14:02 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r1.mot.com with ESMTP; Mon, 20 Aug 2001 03:10:30 -0500 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 7162D2ECAC; Mon, 20 Aug 2001 10:09:45 +0200 (CEST) To: mobile-ip@sunroof.eng.sun.com Cc: mattias.pettersson@era.ericsson.se Subject: Re: [mobile-ip] Mobile Routers support without optimization References: <200108161945.MAA23383@heliopolis.eng.sun.com> <3B7D0516.69267C9E@era.ericsson.se> From: Alexandru Petrescu Date: 20 Aug 2001 10:10:28 +0200 In-Reply-To: <3B7D0516.69267C9E@era.ericsson.se> Message-Id: Lines: 14 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: Mattias Pettersson writes: > Although a beautiful way, I'm afraid such a renumbering is going to > be something really heavy. Some ISPs are really reluctant to > renumbering, and here we happy Mobile IPv6-people come and suggest > mandatory renumbering every 20 second or so... :) Ok, renumbering should not happen very often. Regarding the ISP, the renumbering I was thinking of happens in the MMH-subnet only, so invisible to access network. This is to say renumbering could be an alternative for small MMH-subnets. Alex From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 20 04:41:37 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09524 for ; Mon, 20 Aug 2001 04:41: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 BAA25063; Mon, 20 Aug 2001 01:41:50 -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 BAA23038; Mon, 20 Aug 2001 01:41:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7K8dSZ02508 for mobile-ip-dist; Mon, 20 Aug 2001 01:39:28 -0700 (PDT) Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.179.15]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7K8dNL02498 for ; Mon, 20 Aug 2001 01:39:24 -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 f7K8dB213446; Mon, 20 Aug 2001 10:39:11 +0200 (MET DST) Date: Mon, 20 Aug 2001 10:36:14 +0200 (CEST) From: Erik Nordmark Subject: Re: [mobile-ip] Mobile Routers support without optimization To: James Kempf Cc: Erik.Nordmark@eng.sun.com, mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <200108171623.JAA28638@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: > The point I think I was trying to make is that the PAN network > is strictly a leaf, i.e. there is no other router somewhere > routing out of the PAN network into the Internet. Good point. I expect that everybody assumes that the mobile network is a leaf - it might be a multihomed leaf in some cases (with multiple routers towards the rest of the Internet) but it makes no sense for the mobile network to be a transit for other packets. > A simple alternative, if I understood your previous email correctly, is to > have the PAN addresses globally routable through the home subnet but don't > do route optimization to the CN. That would require a tunnel back through > the HA for packets to the PAN because the PAN network prefix wouldn't be in > the visited subnet routing tables and therefore packets with PAN network > prefixes may be subject to ingress filtering. Similarly, incoming > packets to the PAN would need to be routed through the home network, > resulting in quadralateral routing. The advantage is that push > would be possible without special hacks. Packets to the WAN/WLAN interface, > presuming the device is a multihomed host, could still benefit from route > optimization however. > > Are there any other advantages/disadvantages that I am missing? > Perhaps there is another solution? I think the design space is quite large. One case is when the MNNs are statitionary with respect to the MR and don't observe that the MR is moving. In those cases I suspect that there are limits to the amount of route optimization possible since, depending on the actual model for securing BUs, it might be hard or impossible for a 3rd party like the MR to send BUs for its MNNs. But if the MNNs are made aware that the MR is moving then they can use the regular BU mechanism for route optimization. This would more complex than MIPv6 today. For example, such MNNs would need 3 different addresses as far as I can tell: - Home Address - Long-term stable CoA associated with the MR's home prefix This only changes when the MNN moves between MRs. Traffic sent to this address will go through the MR's home agent. - Temporary CoA associated with the MR's CoA prefix (which the MR acquires as it moves). Depending on movement rate and traffic patterns the MNN can then choose which correspondents to update with the temporary CoA, the stable CoA, or not update at all. > It helped me alot in this simple case to think of the mobile device > as a multihomed host instead of a router (actually, I think that > may be more accurate anyway if the device is a cell phone with a Bluetooth > interface) because it allowed me to avoid having to think about the > effects on the routing protocols in the visited network. IMHO the current 3G model for devices connected through a cell phone are quite limited - makes the cell phone into some form of PPP relay. A router is the IETF model for devices that connect between dissimilar L2 technologies (and also in many cases between the same L2 technologies). So let's not get distracted my the limits of what folks might be currently building while trying to understand the size and shape of the design space. Erik From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 20 04:46:37 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09565 for ; Mon, 20 Aug 2001 04: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 BAA26812; Mon, 20 Aug 2001 01:47: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 BAA23548; Mon, 20 Aug 2001 01:47:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7K8k2K02631 for mobile-ip-dist; Mon, 20 Aug 2001 01:46:02 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7K8jhL02624 for ; Mon, 20 Aug 2001 01:45:44 -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 BAA14630 for ; Mon, 20 Aug 2001 01:45:46 -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 BAA06776 for ; Mon, 20 Aug 2001 01:45:44 -0700 (PDT) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f7K8jhK23906; Mon, 20 Aug 2001 10:45:43 +0200 (MEST) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id KAA20219; Mon, 20 Aug 2001 10:45:42 +0200 Message-ID: <3B80CDBD.52A03CFF@era.ericsson.se> Date: Mon, 20 Aug 2001 10:43:41 +0200 From: Mattias Pettersson Organization: Ericsson Research X-Mailer: Mozilla 4.77 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Alexandru Petrescu CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile Routers support without optimization References: <200108161945.MAA23383@heliopolis.eng.sun.com> <3B7D0516.69267C9E@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 Alexandru Petrescu wrote: > > Mattias Pettersson writes: > > Although a beautiful way, I'm afraid such a renumbering is going to > > be something really heavy. Some ISPs are really reluctant to > > renumbering, and here we happy Mobile IPv6-people come and suggest > > mandatory renumbering every 20 second or so... :) > > Ok, renumbering should not happen very often. Regarding the ISP, the > renumbering I was thinking of happens in the MMH-subnet only, so > invisible to access network. I agree. BTW, what does the MMH abbreviation mean? I seem to have missed that. > > This is to say renumbering could be an alternative for small > MMH-subnets. It's not impossible. /Mattias From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 20 06:09:26 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10078 for ; Mon, 20 Aug 2001 06:09: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 EAA27061; Mon, 20 Aug 2001 04:09: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 DAA29463; Mon, 20 Aug 2001 03:09:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7KA7QZ02960 for mobile-ip-dist; Mon, 20 Aug 2001 03:07:26 -0700 (PDT) Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.179.15]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7KA7ML02953 for ; Mon, 20 Aug 2001 03:07:22 -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 f7KA7A221664; Mon, 20 Aug 2001 12:07:10 +0200 (MET DST) Date: Mon, 20 Aug 2001 12:04:13 +0200 (CEST) From: Erik Nordmark Subject: Re: [mobile-ip] Mobile Routers support without optimization To: Mattias Pettersson Cc: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3B7D09AC.66A68701@era.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > So you prefer this Mobile IPv6 can of worms instead? I wouldn't say we > are completely clean here either... :) This is getting into discussing the pro's and con's of NATs which is, as far as I know, not the subject of trhe mobile-ip mailing list. Thus I expect the chairs to cut this discussion short :-) IMHO I think there is a very big difference between the transparency (see RFC 2775) provided by IP end-to-end and the attempt at NAT boxes to provide support for some set or some classes of applications. > We are a bit more end-to-end, but NAT has obviously been more deployed > than Mobile IP and seems to be of some use at least. What aspect of Mobile-IP is not end-to-end transparent IP? Erik From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 20 06:44:36 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10472 for ; Mon, 20 Aug 2001 06:44: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 EAA10921; Mon, 20 Aug 2001 04:44: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 DAA22861; Mon, 20 Aug 2001 03:44:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7KAhLX03092 for mobile-ip-dist; Mon, 20 Aug 2001 03:43:21 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7KAhHL03085 for ; Mon, 20 Aug 2001 03:43: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 DAA17515 for ; Mon, 20 Aug 2001 03:43:18 -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 DAA16280 for ; Mon, 20 Aug 2001 03:43:17 -0700 (PDT) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate.mot.com (motgate 2.1) with ESMTP id DAA00419 for ; Mon, 20 Aug 2001 03:43:16 -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 DAA24864 for ; Mon, 20 Aug 2001 03:35:20 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r3.mot.com with ESMTP; Mon, 20 Aug 2001 05:43:02 -0500 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id EE2382ECAC; Mon, 20 Aug 2001 12:42:28 +0200 (CEST) To: mobile-ip@sunroof.eng.sun.com Cc: James Kempf , Erik.Nordmark@eng.sun.com Subject: Re: [mobile-ip] Mobile Routers support without optimization References: From: Alexandru Petrescu Date: 20 Aug 2001 12:43:12 +0200 In-Reply-To: Message-Id: Lines: 20 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: Erik Nordmark writes: > Good point. I expect that everybody assumes that the mobile network > is a leaf - it might be a multihomed leaf in some cases (with > multiple routers towards the rest of the Internet) but it makes no > sense for the mobile network to be a transit for other packets. Yes, leaf, no need for mobile network to transit other packets. However, the "mobile network" should not mean only "PAN" but also "LAN": the aircraft case, more than 3-4 hosts behind MMH, probably with a simple router linking the cockpit with first class passengers (one prefix) and second class passengers (another prefix, same length as first, longer than cockpit's). > I think the design space is quite large. One case is when the MNNs > are statitionary with respect to the MR and don't observe that the > MR is moving. Yes, this case is the most probable, should be treated first. Alex From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 20 06: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 ESMTP id GAA10513 for ; Mon, 20 Aug 2001 06:48:14 -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 DAA29491; Mon, 20 Aug 2001 03:48: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 DAA23142; Mon, 20 Aug 2001 03:47:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7KAkcm03161 for mobile-ip-dist; Mon, 20 Aug 2001 03:46:38 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7KAkYL03151 for ; Mon, 20 Aug 2001 03:46:34 -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 DAA23080 for ; Mon, 20 Aug 2001 03:46:35 -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 DAA03487 for ; Mon, 20 Aug 2001 03:46:34 -0700 (PDT) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate.mot.com (motgate 2.1) with ESMTP id DAA02090 for ; Mon, 20 Aug 2001 03:46:34 -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 DAA14002 for ; Mon, 20 Aug 2001 03:46:33 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r2.mot.com with ESMTP for mobile-ip@sunroof.eng.sun.com; Mon, 20 Aug 2001 05:46:22 -0500 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id CFF8C2ECAC for ; Mon, 20 Aug 2001 12:45:47 +0200 (CEST) To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile Routers support without optimization References: <200108161945.MAA23383@heliopolis.eng.sun.com> <3B7D0516.69267C9E@era.ericsson.se> <3B80CDBD.52A03CFF@era.ericsson.se> From: Alexandru Petrescu Date: 20 Aug 2001 12:46:31 +0200 In-Reply-To: <3B80CDBD.52A03CFF@era.ericsson.se> Message-Id: Lines: 8 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: Mattias Pettersson writes: > BTW, what does the MMH abbreviation mean? I seem to have missed > that. I think James coined it as Mobile Multihomed Host. Could have been MMHH Mobile Multi-Homed Host. Alex From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 20 09:13:58 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18012 for ; Mon, 20 Aug 2001 09:13:57 -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 GAA08833; Mon, 20 Aug 2001 06:13:54 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA16321; Mon, 20 Aug 2001 06:13:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7KDC6H03753 for mobile-ip-dist; Mon, 20 Aug 2001 06:12:06 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7KDC2L03746 for ; Mon, 20 Aug 2001 06:12: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 GAA13901; Mon, 20 Aug 2001 06:12:04 -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 HAA22641; Mon, 20 Aug 2001 07:11:59 -0600 (MDT) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f7KDC2K06338; Mon, 20 Aug 2001 15:12:02 +0200 (MEST) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id PAA27533; Mon, 20 Aug 2001 15:12:01 +0200 Message-ID: <3B810C17.6F678574@era.ericsson.se> Date: Mon, 20 Aug 2001 15:09:43 +0200 From: Mattias Pettersson Organization: Ericsson Research X-Mailer: Mozilla 4.77 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Erik Nordmark CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile Routers support without optimization References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Erik Nordmark wrote: > IMHO I think there is a very big difference between the transparency > (see RFC 2775) provided by IP end-to-end and the attempt at NAT boxes > to provide support for some set or some classes of applications. > > > We are a bit more end-to-end, but NAT has obviously been more deployed > > than Mobile IP and seems to be of some use at least. > > What aspect of Mobile-IP is not end-to-end transparent IP? > I shouldn't have brought this issue up, of course. The route optimized Mobile IPv6 is a good thing. It is e2e, the end-nodes are fully aware of what is happening. There are no nodes in between that have essential functionality (except when a HA is initially needed as a consequence of CN-initiated traffic). Mobile IPv6 without route optimization is hiding to the CN that there is a HA in between. The HA is doing proxy ND and proxy DAD for the MN. We play make-believe that the MN is always at home. We do it for global and site-local addresses, but not for link-local. Mobile IPv6 is a pretty good protocol, but I think it suffers from that we want to emulate that the MN is a fixed node. My recommendation: hide movement less. Let end-nodes be aware of mobility. Anyway, there are different proposals for things in this direction. I should stop boring you [the WG] with these insults. /Mattias From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 20 09:27:43 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19018 for ; Mon, 20 Aug 2001 09:27: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 GAA13312; Mon, 20 Aug 2001 06:27: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 GAA17689; Mon, 20 Aug 2001 06:27:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7KDQ2O03850 for mobile-ip-dist; Mon, 20 Aug 2001 06:26:02 -0700 (PDT) Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.179.15]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7KDPwL03843 for ; Mon, 20 Aug 2001 06:25:58 -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 f7KDPj208909; Mon, 20 Aug 2001 15:25:45 +0200 (MET DST) Date: Mon, 20 Aug 2001 15:22:49 +0200 (CEST) From: Erik Nordmark Subject: Re: [mobile-ip] Mobile Routers support without optimization To: Mattias Pettersson Cc: Erik Nordmark , mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3B810C17.6F678574@era.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > What aspect of Mobile-IP is not end-to-end transparent IP? > > > > I shouldn't have brought this issue up, of course. Of course. :-) You seem to argue that a different approach to mobility can be made better than mobile IP as currently defined. (I may or may not agree with that - it is not important for this point.) This is very different than in the mail I replied to where you seemed to say that Mobile IP was similar to NAT in some respects. As far as I can tell, mobile IP is transparent to IP packets but you seem to be claiming otherwise? Erik > The route optimized Mobile IPv6 is a good thing. It is e2e, the > end-nodes are fully aware of what is happening. There are no nodes in > between that have essential functionality (except when a HA is initially > needed as a consequence of CN-initiated traffic). > > Mobile IPv6 without route optimization is hiding to the CN that there is > a HA in between. The HA is doing proxy ND and proxy DAD for the MN. We > play make-believe that the MN is always at home. We do it for global and > site-local addresses, but not for link-local. > > Mobile IPv6 is a pretty good protocol, but I think it suffers from that > we want to emulate that the MN is a fixed node. My recommendation: hide > movement less. Let end-nodes be aware of mobility. > > Anyway, there are different proposals for things in this direction. I > should stop boring you [the WG] with these insults. > > /Mattias From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 20 09:30:26 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19369 for ; Mon, 20 Aug 2001 09:30: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 GAA14501; Mon, 20 Aug 2001 06:30: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 GAA17961; Mon, 20 Aug 2001 06:29:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7KDSu403912 for mobile-ip-dist; Mon, 20 Aug 2001 06:28:56 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7KDSqL03905 for ; Mon, 20 Aug 2001 06:28: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 GAA15258 for ; Mon, 20 Aug 2001 06:28:55 -0700 (PDT) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA22458 for ; Mon, 20 Aug 2001 06:28:54 -0700 (PDT) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id GAA03317 for ; Mon, 20 Aug 2001 06:28:54 -0700 (MST)] Received: [from m-il06-r3.mot.com (m-il06-r3.mot.com [129.188.137.194]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id GAA28749 for ; Mon, 20 Aug 2001 06:28:54 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r3.mot.com with ESMTP; Mon, 20 Aug 2001 08:28:40 -0500 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id F0BD42ECAC; Mon, 20 Aug 2001 15:27:56 +0200 (CEST) To: mobile-ip@sunroof.eng.sun.com Cc: James Kempf , Erik.Nordmark@eng.sun.com Subject: Re: [mobile-ip] Mobile Routers support without optimization References: From: Alexandru Petrescu Date: 20 Aug 2001 15:28:41 +0200 Message-Id: Lines: 43 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: Erik Nordmark writes: > One case is when the MNNs are statitionary with respect to the MR > and don't observe that the MR is moving. In those cases I suspect > that there are limits to the amount of route optimization possible > since, depending on the actual model for securing BUs, it might be > hard or impossible for a 3rd party like the MR to send BUs for its > MNNs. A 3rd party like MR _could_ verifiably send BUs for its MNN's, as a prefix: the CN could ensure the prefix belongs to MR by verifying special requirements on the HA address, the MR home address and the MNN home address. > But if the MNNs are made aware that the MR is moving then they can > use the regular BU mechanism for route optimization. Provided that you require MNN's to send BU's only for CN's for route optimization, and not to HA, this can still fit the original motivation behind MR: send only one BU for the whole prefix (to HA only in this case). > This would more complex than MIPv6 today. For example, such MNNs would need > 3 different addresses as far as I can tell: > - Home Address > - Long-term stable CoA associated with the MR's home prefix > This only changes when the MNN moves between MRs. > Traffic sent to this address will go through the MR's home agent. > - Temporary CoA associated with the MR's CoA prefix (which the MR acquires as > it moves). > > Depending on movement rate and traffic patterns the MNN can then choose > which correspondents to update with the temporary CoA, the stable CoA, > or not update at all. Interesting, this should be checked. These features would probably fall under a stronger requirement than the initial. Here the MNN's can detach and reattach somewhere else. It's even stronger than your previous paragraph in which MNN's were only aware of mobility of the subnet. Alex From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 20 09:40:06 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19985 for ; Mon, 20 Aug 2001 09:40:05 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA10458; Mon, 20 Aug 2001 07:40: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 GAA20241; Mon, 20 Aug 2001 06:40:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7KDcgD04053 for mobile-ip-dist; Mon, 20 Aug 2001 06:38:42 -0700 (PDT) Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.179.15]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7KDccL04046 for ; Mon, 20 Aug 2001 06:38:38 -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 f7KDc8210092; Mon, 20 Aug 2001 15:38:08 +0200 (MET DST) Date: Mon, 20 Aug 2001 15:35:10 +0200 (CEST) From: Erik Nordmark Subject: Re: [mobile-ip] Mobile Routers support without optimization To: Alexandru Petrescu Cc: mobile-ip@sunroof.eng.sun.com, James Kempf , Erik.Nordmark@eng.sun.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > A 3rd party like MR _could_ verifiably send BUs for its MNN's, as a > prefix: the CN could ensure the prefix belongs to MR by verifying > special requirements on the HA address, the MR home address and the > MNN home address. I have not seen a draft specify how this can be done securely. Do you have a pointer to a draft? > Provided that you require MNN's to send BU's only for CN's for route > optimization, and not to HA, this can still fit the original > motivation behind MR: send only one BU for the whole prefix (to HA > only in this case). Sure, as I've said in other emails, the authorization issues for the MR to HA communication can be solved - this is essentially a pre-configured relationship in any case. Erik From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 20 09:48:47 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20552 for ; Mon, 20 Aug 2001 09:48:47 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA21546; Mon, 20 Aug 2001 06:48:34 -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 GAA21025; Mon, 20 Aug 2001 06:43:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7KDgeo04115 for mobile-ip-dist; Mon, 20 Aug 2001 06:42:40 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7KDgbL04104 for ; Mon, 20 Aug 2001 06:42: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 GAA03411; Mon, 20 Aug 2001 06:42:39 -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 GAA21323; Mon, 20 Aug 2001 06:42:38 -0700 (PDT) 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 f7KDgav16827; Mon, 20 Aug 2001 15:42:36 +0200 (MEST) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id PAA28631; Mon, 20 Aug 2001 15:42:34 +0200 Message-ID: <3B81133D.26E02CCC@era.ericsson.se> Date: Mon, 20 Aug 2001 15:40:13 +0200 From: Mattias Pettersson Organization: Ericsson Research X-Mailer: Mozilla 4.77 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Erik Nordmark CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile Routers support without optimization References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Erik Nordmark wrote: > > You seem to argue that a different approach to mobility can be made > better than mobile IP as currently defined. (I may or may not agree with > that - it is not important for this point.) That was a bonus. > > This is very different than in the mail I replied to where > you seemed to say that Mobile IP was similar to NAT in some respects. > > As far as I can tell, mobile IP is transparent to IP packets > but you seem to be claiming otherwise? The triangular routed case below has a box in the middle that is invisible to the CN (like a NAT). The packets pass though unmodified (HA is not that evil), but some packets are not forwarded (link-local). /Mattias > > Erik > > > The route optimized Mobile IPv6 is a good thing. It is e2e, the > > end-nodes are fully aware of what is happening. There are no nodes in > > between that have essential functionality (except when a HA is initially > > needed as a consequence of CN-initiated traffic). > > > > Mobile IPv6 without route optimization is hiding to the CN that there is > > a HA in between. The HA is doing proxy ND and proxy DAD for the MN. We > > play make-believe that the MN is always at home. We do it for global and > > site-local addresses, but not for link-local. > > > > Mobile IPv6 is a pretty good protocol, but I think it suffers from that > > we want to emulate that the MN is a fixed node. My recommendation: hide > > movement less. Let end-nodes be aware of mobility. > > > > Anyway, there are different proposals for things in this direction. I > > should stop boring you [the WG] with these insults. > > > > /Mattias From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 20 10:48:16 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22627 for ; Mon, 20 Aug 2001 10:48:15 -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 IAA29286; Mon, 20 Aug 2001 08:46:51 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA00905; Mon, 20 Aug 2001 07:46:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7KEj9j04449 for mobile-ip-dist; Mon, 20 Aug 2001 07:45:09 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7KEj5L04442 for ; Mon, 20 Aug 2001 07:45: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 HAA14830 for ; Mon, 20 Aug 2001 07:45:06 -0700 (PDT) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA27841 for ; Mon, 20 Aug 2001 08:45:01 -0600 (MDT) Received: by megisto-sql1.megisto.com with Internet Mail Service (5.5.2650.21) id ; Mon, 20 Aug 2001 10:44:17 -0400 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Re: mobile-ip] Re: mobile-ip] RFC2002bis Date: Mon, 20 Aug 2001 10:44:16 -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 text was posted to the mailing list. You commented on it I believe. MUST for HMAC-MD5, SHOULD for MD5 prefix_suffix for those nodes requiring backward compatibility. > -----Original Message----- > From: Madhavi W. Chandra [mailto:mchandra@cisco.com] > Sent: Monday, August 13, 2001 6:04 PM > To: Basavaraj.Patil@nokia.com > Cc: mobile-ip@sunroof.eng.sun.com; mchandra@cisco.com > Subject: [mobile-ip] Re: mobile-ip] Re: mobile-ip] RFC2002bis > > > On Mon, Aug 13, 2001 at 04:54:21PM -0500, > Basavaraj.Patil@nokia.com wrote: > > Hi, > > > > >> > > >> The working group chairs recently asked the working group, > > >> by way of the mailing list, whether this incompatible > > >> change would be acceptable. The discussion was quite > > >> limited, somewhat to my surprise. This has been taken > > >> as evidence that going with HMAC_MD5 is more-or-less > > >> O.K. Thus, it has been decided to go ahead with the > > >> change. On the other hand, it is conceivable that not > > >> all interested parties have been notified of the possible > > >> change, or have had time to reply. If there are dissenters > > >> to this change, now would be the time to express that > > >> opinion. > > > > > >A quick question...when this was discussed on the mailing list last > > >month, Kent and Gopal raised the issue of making MD5 also a MUST > > >in RFC2002bis. Discussion followed whether MD5 should be a MUST > > >or a SHOULD for backwards compatibility...with the > understanding that > > >HMAC_MD5 would be a MUST. So, is the idea now not to even > mention this > > > > >use of MD5? Please clarify. > > > > > > > The intent is to have HMAC-MD5 as the MUST for the authentication > > algorithm. But MD5 will still be mentioned in the updated I-D. > > OK...but, mentioned HOW? MUST or SHOULD? The issue is that > even though IESG advised on HMAC_MD5 as default, we need to ensure > backwards compatibility. And I am still unclear on the ramifications > that Charlie outlined. > > Bottom line...breaking backwards compatibility is not acceptable or > advisable, especially since there are MIP deployments out there. > > Thanks, > Madhavi > > > > > >Thanks, > > >Madhavi > > > > -Basavaraj > From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 20 11:57:21 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24838 for ; Mon, 20 Aug 2001 11:57:20 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA24231; Mon, 20 Aug 2001 09:54: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 IAA17025; Mon, 20 Aug 2001 08:54:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7KFrBG04718 for mobile-ip-dist; Mon, 20 Aug 2001 08:53:11 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7KFr7L04711 for ; Mon, 20 Aug 2001 08:53: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 IAA06134 for ; Mon, 20 Aug 2001 08:53:09 -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 JAA22877 for ; Mon, 20 Aug 2001 09:53:04 -0600 (MDT) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate.mot.com (motgate 2.1) with ESMTP id IAA17317 for ; Mon, 20 Aug 2001 08:53:08 -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 IAA24520 for ; Mon, 20 Aug 2001 08:53:07 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r3.mot.com with ESMTP; Mon, 20 Aug 2001 10:52:50 -0500 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id D06EC2ECAC; Mon, 20 Aug 2001 17:52:08 +0200 (CEST) To: mobile-ip@sunroof.eng.sun.com Cc: James Kempf , Erik.Nordmark@eng.sun.com Subject: Re: [mobile-ip] Mobile Routers support without optimization References: From: Alexandru Petrescu Date: 20 Aug 2001 17:52:54 +0200 In-Reply-To: Message-Id: Lines: 21 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: Erik Nordmark writes: > > A 3rd party like MR _could_ verifiably send BUs for its MNN's, as a > > prefix: the CN could ensure the prefix belongs to MR by verifying > > special requirements on the HA address, the MR home address and the > > MNN home address. > > I have not seen a draft specify how this can be done securely. > Do you have a pointer to a draft? I was not referring a specific draft. I just wanted to say that if we put strong aggregation requirements on the HA address, the MR home address and the MNN address, I think the legitimate prefix can be deduced at the CN. Part of this has been mentionned previously in the thread. Of course there are limits to this. For example, if I impose that the HA address and the MR home address differ on the first bit following that legitimate subnet prefix-1 then stateless autoconfiguration would fall appart. Alex From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 20 12: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 ESMTP id MAA25607 for ; Mon, 20 Aug 2001 12:22: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 KAA17771; Mon, 20 Aug 2001 10:22: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 JAA24638; Mon, 20 Aug 2001 09:21:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7KGKFj04873 for mobile-ip-dist; Mon, 20 Aug 2001 09:20:15 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7KGJvL04854 for ; Mon, 20 Aug 2001 09:20:12 -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 JAA21825; Mon, 20 Aug 2001 09:19:58 -0700 (PDT) Message-Id: <200108201619.JAA21825@heliopolis.eng.sun.com> Date: Mon, 20 Aug 2001 09:19:58 -0700 (PDT) From: James Kempf Subject: Re: [mobile-ip] Mobile Routers support without optimization To: James.Kempf@Sun.COM, Erik.Nordmark@eng.sun.com Cc: Erik.Nordmark@eng.sun.com, mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: KbibZr54L3NIUjtHnqYTqw== 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: Erik, >I think the design space is quite large. >One case is when the MNNs are statitionary with respect to the MR >and don't observe that the MR is moving. In those cases I suspect >that there are limits to the amount of route optimization possible >since, depending on the actual model for securing BUs, it might be hard >or impossible for a 3rd party like the MR to send BUs for its MNNs. > Alex and I had an email exchange last week where I think we worked out how it would be possible to do it. The MR exchanges a BU with the CNs. The BU contains the MR's CoA and a prefix for the subnet that the MR is routing. The CNs set up a tunnel to the MR in which they send packets routed to the MNNs behind the MR. Similarly, the MR needs to set up a tunnel to the CNs for outgoing packets, because the mobile network prefix will not be in the routing tables of the wired network. There is still triangle (actually quadralateral) routing but the advantage over doing the routing through the HA is that the leg from the CNs to the MR goes more or less through the "natural" path it would take if there were no tunnel. If all traffic is tunnelled through the HA, the off leg is much longer. The security properties in this case seem, on first glance, to be similar to regular MIP. The only issue is whether the MR is allowed to route the prefix it claims it is allowed to route. Even though the CN can authenticate the BU and CoA, it does not necessarily mean that the node claiming to be a MR is allowed to route the prefix. Perhaps something could be set up through the HA when the CN first makes contact with the MNN so that the HA could inform the CN that the MR is allowed to route that prefix (or not, as the case may be). Is there any thing missing in this solution? >But if the MNNs are made aware that the MR is moving then they can use >the regular BU mechanism for route optimization. >This would more complex than MIPv6 today. For example, such MNNs would need >3 different addresses as far as I can tell: > - Home Address > - Long-term stable CoA associated with the MR's home prefix > This only changes when the MNN moves between MRs. > Traffic sent to this address will go through the MR's home agent. > - Temporary CoA associated with the MR's CoA prefix (which the MR acquires as > it moves). > >Depending on movement rate and traffic patterns the MNN can then choose >which correspondents to update with the temporary CoA, the stable CoA, >or not update at all. > It seems somewhat impractical to require that nodes behind a mobile router be mobile aware. What if I buy a laser printer for my cruise ship network? Or bring one along on a cruise? It probably isn't mobile aware. I agree that there are cases where the MNNs will be mobile aware, in particular, when they are capable of being stand-alone MNs in the standard MIP sense. In those cases, your scheme of three addresses might work, though it seems somewhat complex to me. And it would require additional mechanism over and above standard MIP. In the case where a standard MIP capable MN attaches to a mobile network, it would seem simpler if the MR acted as a standard AR in the MIP sense. The MN would get a CoA using either stateful or stateless address autoconfig, reporting it to its HA. The CoA is on the mobile network, and the MR uses the procedure outlined above to route optimize (or a NAT, yuk!), or perhaps it doesn't route optimize and routes everything through the HA. The only change needed would be some way for the MR to tell the MN to supress sending BUs, since the MR will be taking care of that. >IMHO the current 3G model for devices connected through a cell phone >are quite limited - makes the cell phone into some form >of PPP relay. >A router is the IETF model for devices that connect between dissimilar L2 >technologies (and also in many cases between the same L2 technologies). > >So let's not get distracted my the limits of what folks might be currently >building while trying to understand the size and shape of the design space. > While I certainly agree that the 3G model is limited, I think much of the emphasis to come up with a solution to the MR problem is driven by that model. My feeling is that if we can come up with a solution that solves the short term problem based on some simple extensions of MIP, perhaps we can then move to a more comprehensive solution for mobile routers that has wider applicability. If we try to solve the long term problem by casting everything into the MIP framework, I'm afraid we may be ruling out solutions that would handle complex cases far more easily and may also provide better solutions to the simple cases (in the long run). Contrawise, if we ignore the short term solution, we may end up with people doing suboptimal or architecturally questionable things (like NATs?). jak From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 20 12:51:23 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26587 for ; Mon, 20 Aug 2001 12:51: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 KAA13040; Mon, 20 Aug 2001 10:51:49 -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 JAA07479; Mon, 20 Aug 2001 09:48:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7KGkDk05013 for mobile-ip-dist; Mon, 20 Aug 2001 09:46:13 -0700 (PDT) Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.179.15]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7KGk9L05006 for ; Mon, 20 Aug 2001 09:46:09 -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 f7KGjv201776; Mon, 20 Aug 2001 18:45:57 +0200 (MET DST) Date: Mon, 20 Aug 2001 18:43:00 +0200 (CEST) From: Erik Nordmark Subject: Re: [mobile-ip] Mobile Routers support without optimization To: Alexandru Petrescu Cc: mobile-ip@sunroof.eng.sun.com, James Kempf , Erik.Nordmark@eng.sun.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > I was not referring a specific draft. I just wanted to say that if we > put strong aggregation requirements on the HA address, the MR home > address and the MNN address, I think the legitimate prefix can be > deduced at the CN. Part of this has been mentionned previously in the > thread. I know this has been mentioned and hand-waved around before. However, I've seen nothing of substance on how this is doable in a secure fashion under reasonable trust models. Are you assuming that any CN would (for instance) accept a BU for a /64 prefix from anybody? How can the CN verify the authority for such a BU? Erik From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 20 12:59:36 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26796 for ; Mon, 20 Aug 2001 12:59: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 KAA19833; Mon, 20 Aug 2001 10:59:53 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA10473; Mon, 20 Aug 2001 09:59:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7KGvwe05114 for mobile-ip-dist; Mon, 20 Aug 2001 09:57:58 -0700 (PDT) Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.179.15]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7KGvsL05107 for ; Mon, 20 Aug 2001 09:57:54 -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 f7KGvf202894; Mon, 20 Aug 2001 18:57:41 +0200 (MET DST) Date: Mon, 20 Aug 2001 18:54:44 +0200 (CEST) From: Erik Nordmark Subject: Re: [mobile-ip] Mobile Routers support without optimization To: James Kempf Cc: Erik.Nordmark@eng.sun.com, mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <200108201619.JAA21825@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: > Alex and I had an email exchange last week where I think we worked > out how it would be possible to do it. The MR exchanges a BU > with the CNs. And how do you propose solve the authorization issue for the BU? To the WG: I'm seriously starting to feel like a broken record - do people still feel like security can be added as an afterthought? Unless security (authentication and authorization) is thought of up front I don't see how the WG can make progress. > The security properties in this case seem, on first glance, to > be similar to regular MIP. The only issue is whether the MR > is allowed to route the prefix it claims it is allowed to > route. Even though the CN can authenticate the BU and CoA, it > does not necessarily mean that the node claiming to be a MR > is allowed to route the prefix. Perhaps something could be > set up through the HA when the CN first makes contact > with the MNN so that the HA could inform the CN that the MR > is allowed to route that prefix (or not, as the case may be). And when the HA and MR conspire to fool a random CN? > It seems somewhat impractical to require that nodes behind a > mobile router be mobile aware. What if I buy a laser printer for > my cruise ship network? Or bring one along on a cruise? It probably isn't > mobile aware. But you might not need to optimize for random CN's accessing your printer :-) Seriously, there might be some relationship between devices being globally accessible and wanting to be MNs in their own right, which might feed into thinking about where optimizations make sense. > I agree that there are cases where the MNNs will be mobile aware, in > particular, when they are capable of being stand-alone MNs in the standard > MIP sense. In those cases, your scheme of three addresses might > work, though it seems somewhat complex to me. And it would require > additional mechanism over and above standard MIP. It isn't clear to me that it requires additional e2e protocols. It would definitely require different behavior on such an MNN. (But I'm thing about the requirements space more than the solution space at the moment.) Erik From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 20 13:03:07 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26903 for ; Mon, 20 Aug 2001 13:03:07 -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 LAA23110; Mon, 20 Aug 2001 11:03: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 KAA11441; Mon, 20 Aug 2001 10:02:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7KH18o05192 for mobile-ip-dist; Mon, 20 Aug 2001 10:01:08 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7KH14L05185 for ; Mon, 20 Aug 2001 10:01: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 KAA09669 for ; Mon, 20 Aug 2001 10:01:06 -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 LAA20861 for ; Mon, 20 Aug 2001 11: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 KAA10158 for ; Mon, 20 Aug 2001 10:01:05 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f7KH15T05507 for ; Mon, 20 Aug 2001 10:01:05 -0700 X-mProtect: Mon, 20 Aug 2001 10:01:05 -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 smtpdWT8rxp; Mon, 20 Aug 2001 10:01:03 PDT Message-ID: <3B81424F.CF3096E1@iprg.nokia.com> Date: Mon, 20 Aug 2001 10:01:03 -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] IPsec, IKE, MIPv6 and concensus References: <034BEFD03799D411A59F00508BDF754603008BCA@esealnt448.al.sw.ericsson.se> <3B7C4A7B.2DCECEDC@iprg.nokia.com> <15232.12080.628273.833183@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: > > Vijay Devarapalli writes: > > "Hesham Soliman (ERA)" wrote: > > > > > Problem (1) is addressed by several proposals. Needless to say that > > > 1 and 2 are not dependant on each other (or need not be). > > > > > > So the questions that should be answered IMO are: > > > > > > 1. Do we want to completely disallow the use of IKE ? > > > > NO. > > > > > > > > 2. Do we want to completely disallow the use of IPsec ? > > > > YES. use authentication data suboption for the BU. > > Since this requires a new DOI for IKE, your i never said it did not. vijay > answers are mutually contradictory. > > Mike From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 20 13:39:19 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28086 for ; Mon, 20 Aug 2001 13:39: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 LAA24114; Mon, 20 Aug 2001 11:39: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 KAA19325; Mon, 20 Aug 2001 10:39:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7KHb7x05487 for mobile-ip-dist; Mon, 20 Aug 2001 10:37:07 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7KHb4L05480 for ; Mon, 20 Aug 2001 10:37: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 KAA25667; Mon, 20 Aug 2001 10:37:06 -0700 (PDT) Message-Id: <200108201737.KAA25667@heliopolis.eng.sun.com> Date: Mon, 20 Aug 2001 10:37:06 -0700 (PDT) From: James Kempf Subject: Re: [mobile-ip] Mobile Routers support without optimization To: James.Kempf@Sun.COM, Erik.Nordmark@eng.sun.com Cc: Erik.Nordmark@eng.sun.com, mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: QMZeeVsXbvHgwvnzv/rlGg== 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: Erik, > >> Alex and I had an email exchange last week where I think we worked >> out how it would be possible to do it. The MR exchanges a BU >> with the CNs. > >And how do you propose solve the authorization issue for the BU? > Read further down the email and you'll see. >To the WG: > >I'm seriously starting to feel like a broken record - do people still feel >like security can be added as an afterthought? >Unless security (authentication and authorization) is thought of up front >I don't see how the WG can make progress. > Please, Erik, I understand! :-) I'm just trying to explore the solution space. If we find a solution that looks like it won't work due to security, then let's discard it. It is not clear to me that this one won't work at this point. >> The security properties in this case seem, on first glance, to >> be similar to regular MIP. The only issue is whether the MR >> is allowed to route the prefix it claims it is allowed to >> route. Even though the CN can authenticate the BU and CoA, it >> does not necessarily mean that the node claiming to be a MR >> is allowed to route the prefix. Perhaps something could be >> set up through the HA when the CN first makes contact >> with the MNN so that the HA could inform the CN that the MR >> is allowed to route that prefix (or not, as the case may be). > > >And when the HA and MR conspire to fool a random CN? > Basically, if I understand correctly, most solutions for the MIPv6 BU security problem are not proposing that the CN and MN obtain an authentication that the MN is who it says it is but just that the MN is the same one the CN was talking to before, and thus that that the MN is allowed to tell the CN via a BU to change the routing. In order to have the CN authenticate that the MN is who it says it is, there would need to be some out of band exchange of secure information that the CN could later fall back on to authenticate the MN, correct? And this is clearly too onerous for a random CN/MN exchange. I think trying to prevent the HA and MR from fooling a random CN falls into the same category as requiring the CN to authenticate that the MN is who it says it is. This would require an out of band exchange of secure information. Now, there may be good reasons why this requrement should be imposed on MR/CN route optimization and not on MH/CN route optimization, but if so, I think we need to spell them out. A similar requirement to MH/CN route optimization might go as follows. Since the subnet prefix that the MR sends in the BU must be on the home subnet of the MR, one can require that the HA route a subnet that includes, under it, the subnet routed by the MR. Since the HR controls the routes to that prefix, it should be able to tell the CN whether the MN is authorized to provide routing updates. The CN can verify that the MR is the same one that it talked to before by the solution for MIP host BU security. The additional requirement is some sort of security exchange initially between the CN and HA that allows the HA to inform the CN that the MH home address is for a MR and that the MR is allowed to change routing for the subnet. > >> It seems somewhat impractical to require that nodes behind a >> mobile router be mobile aware. What if I buy a laser printer for >> my cruise ship network? Or bring one along on a cruise? It probably isn't >> mobile aware. > >But you might not need to optimize for random CN's accessing your printer :-) > >Seriously, there might be some relationship between devices being globally >accessible and wanting to be MNs in their own right, which might feed >into thinking about where optimizations make sense. > The issue I see is whether there needs to be something "extra" in MNNs on mobile subnets. The "extra" is in addition to a static IPv6 node or a MIPv6 node. Anything "extra" complicates implementations and is a barrier to deployment and usability. So if there does need to be something "extra". IMHO it had better be really necessary, and it might be an argument for waiting and coming up with a comprehensive solution to the MR problem. So it would seem that a solution which doesn't require something "extra" would be preferable, though maybe not achievable after detailed examination. jak From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 20 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 ESMTP id OAA29027 for ; Mon, 20 Aug 2001 14:11:39 -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 MAA21625; Mon, 20 Aug 2001 12:11:52 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA26185; Mon, 20 Aug 2001 11:10:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7KI8VV05737 for mobile-ip-dist; Mon, 20 Aug 2001 11:08:31 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7KI8SL05726 for ; Mon, 20 Aug 2001 11:08: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 LAA18666 for ; Mon, 20 Aug 2001 11:08:30 -0700 (PDT) Received: from e34.bld.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA05506 for ; Mon, 20 Aug 2001 11:08:30 -0700 (PDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e34.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id OAA24732 for ; Mon, 20 Aug 2001 14:06:20 -0400 Received: from d03nm066.boulder.ibm.com (d03nm066.boulder.ibm.com [9.99.140.50]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7KI84U144440 for ; Mon, 20 Aug 2001 12:08:05 -0600 Subject: [mobile-ip] Improvement in Proxy DAD functionality for Mobility Support in IPv6 To: mobile-ip@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Krishna Kumar" Date: Mon, 20 Aug 2001 11:06:32 -0700 X-MIMETrack: Serialize by Router on D03NM066/03/M/IBM(Release 5.0.8 |June 18, 2001) at 08/20/2001 12:08:02 PM 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 am one of the contributors to the Mobile IP implementation on Linux, along with the Main developers - the HUT Team. While examining the working of Proxy DAD, I would like to propose an improvement in this functionality, which is not addressed in the draft. Section 9.2 of the draft says that when the MN requests the HA to no longer serve as it's HA (returns home) : "In addition, the home agent MUST stop intercepting packets on the mobile node's home link addressed to the mobile node (Section 9.3)."... I feel this step should also apply for the HA when the binding cache entry expires. My reasoning behind this is : 1. The HA does not need to listen to expired entry's solicited multicast addresses after it's expiry. This way the list of multicast addresses doesn't become too large to manage on the HA. Basically if the HA is up for days/months/years and 100's (or more, futuristically) of MN's have moved from the Home Agent network during that time (and not returned to the HA but have shutdown or stopped using mobility), then the list of addresses in the multicast list can become very large. Searching, operating, adding or deleting an entry in this big list can take increasing times, as the uptime of the HA increases, leading to a performance hit. 2. If the MN goes to a foreign network and is shutdown or stops using the mobile service, the HA would still listen to all the MC addresses of each of these MN's home addresses. Then the HA would process the neighbor solicitation, and go through the binding cache as the spec says to see if a binding exists, and finds nothing. Basically we are doing a lot of processing when it is not necessary. The HA is not even serving as the HA for this MN if the entry has expired and there is no good reason to keep listening to the MC address. 3. From an implementation point (please bear with me!), another problem happens if the implementation of mobility is by using a loadable module. If the mobility module were to be 'unloaded' on the HA after the HA served many MN's (which moved to foreign networks and 'expired'), then potentially the HA would be listening to many multicast solicited addresses. So removing mobility support on the HA would not restore this system to it's ORIGINAL state before the module was loaded. I would like to suggest that the draft be modified to say that when an entry in the binding cache expires, the home agent MUST stop intercepting packets on the mobile node's home link addressed to the mobile node. I would appreciate any comments on this issue. Thanks, - KK Krishna Kumar (503) 578-3602 kumarkr@us.ibm.com From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 20 15:07:30 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00390 for ; Mon, 20 Aug 2001 15:07:30 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA09284; Mon, 20 Aug 2001 13:07: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 MAA09701; Mon, 20 Aug 2001 12:06:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7KJ4c206046 for mobile-ip-dist; Mon, 20 Aug 2001 12:04:38 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7KJ4ZL06039 for ; Mon, 20 Aug 2001 12:04: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 MAA08760 for ; Mon, 20 Aug 2001 12:04:36 -0700 (PDT) Received: from postfix2-1.free.fr (postfix2-1.free.fr [213.228.0.9]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA03207 for ; Mon, 20 Aug 2001 12:04:35 -0700 (PDT) Received: from imp3-1.free.fr (imp3-1.free.fr [213.228.0.28]) by postfix2-1.free.fr (Postfix) with ESMTP id 4157813A; Mon, 20 Aug 2001 21:04:34 +0200 (CEST) Received: from imp3-1.free.fr (www-data@localhost [127.0.0.1]) by localhost (8.12.0.Beta16/8.12.0.Beta16/Debian 8.12.0.Beta16) with ESMTP id f7KJ4XEb010453; Mon, 20 Aug 2001 21:04:33 +0200 Received: (from www-data@localhost) by imp3-1.free.fr (8.12.0.Beta16/8.12.0.Beta16/Debian 8.12.0.Beta16) id f7KJ4Vkc010452; Mon, 20 Aug 2001 21:04:31 +0200 To: Erik.Nordmark@eng.sun.com Subject: Re: [mobile-ip] Mobile Routers support without optimization Message-ID: <998334271.3b815f3fa08bc@imp3-1.free.fr> Date: Mon, 20 Aug 2001 21:04:31 +0200 (MEST) From: petrescu@crm.mot.com Cc: mobile-ip@sunroof.eng.sun.com, James Kempf MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.42 X-Originating-IP: 213.228.21.49 Sender: owner-mobile-ip@sunroof.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 [manually reposting, mail system is down until tomorrow, sorry for duplicates] Erik: > Are you assuming that any CN would (for instance) accept a BU for a /64 prefix > from anybody? How can the CN verify the authority for such a BU? What I'm having in mind is very simple and probably too dumb to be considered as a "prefix authorization solution". Basically, the CN can send packets to MR's Home Address and to MNN's Home Address. Those can only be routed to the right addresses. If those two addresses are required (imposed) to be: matching the first 64 bits and differring at the 65th then the CN can conclude that the maximum prefix it can trust for this MR is the respective /65. petrescu@acm.org (please put this in replies, thanks) Alex From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 20 15:55:32 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01796 for ; Mon, 20 Aug 2001 15:55: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 MAA13759; Mon, 20 Aug 2001 12:55: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 MAA28814; Mon, 20 Aug 2001 12:54:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7KJqLj06270 for mobile-ip-dist; Mon, 20 Aug 2001 12:52:21 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7KJq2L06263 for ; Mon, 20 Aug 2001 12:52: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 MAA17352; Mon, 20 Aug 2001 12:51:35 -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 MAA22982; Mon, 20 Aug 2001 12:51:29 -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 f7KJnZD24858; Mon, 20 Aug 2001 12:49: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 ACX03587; Mon, 20 Aug 2001 12:51:21 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA19207; Mon, 20 Aug 2001 12:51:19 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15233.27191.649020.944044@thomasm-u1.cisco.com> Date: Mon, 20 Aug 2001 12:51:19 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Cc: James Kempf , Erik.Nordmark@eng.sun.com Subject: Re: [mobile-ip] Mobile Routers support without optimization In-Reply-To: References: <200108201619.JAA21825@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 Erik Nordmark writes: > > Alex and I had an email exchange last week where I think we worked > > out how it would be possible to do it. The MR exchanges a BU > > with the CNs. > > And how do you propose solve the authorization issue for the BU? > > To the WG: > > I'm seriously starting to feel like a broken record - do people still feel > like security can be added as an afterthought? > Unless security (authentication and authorization) is thought of up front > I don't see how the WG can make progress. It's probably useful to go back to first principles here. That is, who in the triangular path between MN, HA and CN actually knows whether MN should be allowed to assert the prefix it is trying to bind (assuming no global prefix PKI, of course)? One thing is for certain, it's not necessarily the HA. In fact, I'm going to guess that it's probably at the edge of the CN's BGP AS that you really have concrete knowledge. Ie does the HA's AS advertise this (summarized) prefix or not? Indeed, it's not entirely clear that the CN is really the one that should be the target of the BU. Mike From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 20 16:13:50 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02608 for ; Mon, 20 Aug 2001 16:13:49 -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 NAA21353; Mon, 20 Aug 2001 13:13: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 NAA02106; Mon, 20 Aug 2001 13:13:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7KKBNq06452 for mobile-ip-dist; Mon, 20 Aug 2001 13:11:23 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7KKBJL06445 for ; Mon, 20 Aug 2001 13:11:19 -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 NAA02394; Mon, 20 Aug 2001 13:11:16 -0700 (PDT) Message-Id: <200108202011.NAA02394@heliopolis.eng.sun.com> Date: Mon, 20 Aug 2001 13:11:16 -0700 (PDT) From: James Kempf Subject: Re: [mobile-ip] Mobile Routers support without optimization To: mobile-ip@sunroof.eng.sun.com, mat@cisco.com Cc: James.Kempf@sun.com, Erik.Nordmark@eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: evXHr+yhux18pJeK98lg+g== 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: >It's probably useful to go back to first >principles here. That is, who in the triangular >path between MN, HA and CN actually knows whether >MN should be allowed to assert the prefix it is >trying to bind (assuming no global prefix PKI, of >course)? One thing is for certain, it's not >necessarily the HA. In fact, I'm going to guess >that it's probably at the edge of the CN's BGP AS >that you really have concrete knowledge. Ie does >the HA's AS advertise this (summarized) prefix or >not? > Hmm, good point. >Indeed, it's not entirely clear that the CN is >really the one that should be the target of the >BU. > I guess what I'd question is why the CN's border router is any more authoritative than the HA. Here's what I think might be an answer. BGP updates are authenticated, so the CN's border router can trust the routing table updates it receives from the HA's AS. And the CN can trust its own border router, so a transitive chain of trust, is established between the HA's AS and the CN's AS. Is that enough? The only issue is that if the BGP routes are aggregated, the MR's prefix won't show up in the CN AS routing tables, though some superprefix will. If as per my followup message to Erik, one constrains the MR subnet prefix to be a subprefix of the HA 's prefix, and the HA prefix to be a subprefix of a prefix in the BGP routing tables, then would that be enough to let the CN validate? The only issue I can think of is that the HA might send out a message with a bogus return address that had the prefix for another subnet in order to spoof the CN. But, similarly, the MR could send out a bogus prefix in the BU. In either case, the bogus prefix would be a prefix that was routable via the BGP routing tables for CN's AS, but neither HA nor MR would be authorized to route it. I think this problem would similarly hold if the BU was sent to the BGP border router, unless the BU has the same level of authentication as the BGP route updates. Basically, I don't see any way around requiring some out-of-band exchange of security material if we want to verify that the MR and HA are allowed to route a particular prefix. jak From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 20 16:30:13 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03060 for ; Mon, 20 Aug 2001 16:30: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 NAA00305; Mon, 20 Aug 2001 13:30: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 NAA05977; Mon, 20 Aug 2001 13:30:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7KKS6606695 for mobile-ip-dist; Mon, 20 Aug 2001 13:28:06 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7KKS2L06688 for ; Mon, 20 Aug 2001 13:28:02 -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 NAA25055; Mon, 20 Aug 2001 13:28:03 -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 NAA23139; Mon, 20 Aug 2001 13:28: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 NAA27727; Mon, 20 Aug 2001 13:28:02 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f7KKS1F15043; Mon, 20 Aug 2001 13:28:01 -0700 X-mProtect: Mon, 20 Aug 2001 13:28:01 -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 smtpdUTmalf; Mon, 20 Aug 2001 13:27:59 PDT Message-ID: <3B8172CF.75D99E8@iprg.nokia.com> Date: Mon, 20 Aug 2001 13:27: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: Mobile IP Working Group CC: Phil Roberts , "Basavaraj Patil (NTC/Dallas)" , Thomas Narten , Abha Ahuja , Erik Nordmark Subject: [mobile-ip] draft-ietf-mobileip-rfc2002-bis-07.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, Following the request of the Mobile IP working group chairs, which I believe is in accordance with the wishes of the IESG area directors, I have submitted a new Internet Draft for RFC2002bis for distribution to the usual IETF directories. This draft mandates HMAC_MD5 as the authentication algorithm which must be part of every Mobile IPv4 implementation which intends to be compliant with the new specfication. I am acting purely as document editor in this matter. The new specification has been made available at the following URL: http://people.nokia.net/charliep/txt/mobileip/mobiliep.txt Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 20 16:32:52 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03111 for ; Mon, 20 Aug 2001 16:32: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 OAA10618; Mon, 20 Aug 2001 14:33: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 NAA19204; Mon, 20 Aug 2001 13:33:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7KKW1n06804 for mobile-ip-dist; Mon, 20 Aug 2001 13:32:01 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7KKVvL06792 for ; Mon, 20 Aug 2001 13:31: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 NAA26095 for ; Mon, 20 Aug 2001 13:31:58 -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 OAA09467 for ; Mon, 20 Aug 2001 14:31:53 -0600 (MDT) Received: (qmail 956 invoked by uid 500); 20 Aug 2001 20:19:55 -0000 Date: Mon, 20 Aug 2001 13:19:55 -0700 From: Pat Calhoun To: mobile-ip@sunroof.eng.sun.com Cc: Pat Calhoun , charliep@iprg.nokia.com Subject: Re: [mobile-ip] Re: MN-FA/MN-HA Key Material clarification needed Message-ID: <20010820131955.F32693@charizard.diameter.org> References: <006901c1261c$0e954d50$e704a8c0@MIKAELSPC> <20010816164556.J4357@charizard.diameter.org> <001101c126db$20733900$e704a8c0@MIKAELSPC> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <001101c126db$20733900$e704a8c0@MIKAELSPC>; from mikael.wolf@ipunplugged.com on Fri, Aug 17, 2001 at 07:11:48AM +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: Will change to HMAC-SHA-1, instead of SHA-1. PatC On Fri, Aug 17, 2001 at 07:11:48AM +0200, Mikael Wolf wrote: > But anyone can compute a correct digest using SHA-1, i.e., > just using a hash function does not provide any authentication. > > You mention that the key is used to create the authentication > extensions, but how the key should be used is not clear; SHA-1 > in itself does not use a key. In contrast, HMAC-SHA-1 does > specifiy how to use a key together with SHA-1 to provide > authentication. Therefore, I would expect the Algorithm Identifier > to specify HMAC-SHA-1 ( and possibly SHA-1/prefix+suffix? ) > as supported algorithm(s), and not SHA-1. > > Mikael. > > ----- Original Message ----- > From: "Pat Calhoun" > To: "Mikael Wolf" > Cc: ; ; > > Sent: Friday, August 17, 2001 1:45 AM > Subject: Re: MN-FA/MN-HA Key Material clarification needed > > > > Chapter 3 defines the hashing algorithms used in the computation > > of the relevant authentication extensions, not how to encrypt the > > key. So, the key material is used to create the key, and the key is > > used to create the auth extensions. > > > > Hope this is clearer, > > > > PatC > > On Thu, Aug 16, 2001 at 08:24:08AM +0200, Mikael Wolf wrote: > > > draft-ietf-mobileip-aaa-key-08.txt, chapter 3, > > > specifies the algorithms to be used for producing > > > the authentication information included in the Mobile > > > Home Authentication extension or the Mobile Foreign > > > Authentication extension; one of them is SHA-1 (#3). > > > > > > However, a hash function cannot be used as a MAC > > > since it does not rely on a secret key (contradictory to > > > what is stated in chapter 3). > > > > > > Please clarify how SHA-1 should be used provide > > > authentication. > > > > > > Thanks, > > > Mikael. > > > > > > > > > From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 20 16:40:40 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03291 for ; Mon, 20 Aug 2001 16:40: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 NAA04954; Mon, 20 Aug 2001 13: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 NAA21012; Mon, 20 Aug 2001 13:40:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7KKd0906981 for mobile-ip-dist; Mon, 20 Aug 2001 13:39:00 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7KKcvL06974 for ; Mon, 20 Aug 2001 13:38:57 -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 NAA27683 for ; Mon, 20 Aug 2001 13:38: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 NAA28106 for ; Mon, 20 Aug 2001 13:38:58 -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 NAA28498 for ; Mon, 20 Aug 2001 13:38:58 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f7KKcvg02595 for ; Mon, 20 Aug 2001 13:38:57 -0700 X-mProtect: Mon, 20 Aug 2001 13:38:57 -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 smtpdSBumaV; Mon, 20 Aug 2001 13:38:56 PDT Message-ID: <3B817560.FF84055B@iprg.nokia.com> Date: Mon, 20 Aug 2001 13:38:56 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Mobile IP Working Group Subject: [mobile-ip] Mobile IPv6 draft revision 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, Following the recent discussion, I believe a new revision to the existing Mobile IPv6 draft ...-14 is needed. The new draft would have the following features: - Removal of all text related to Mobile Routers, including the 'R' bit of the Binding Update - Reorganizing the Binding Update format so that: = authentication data is able to be included as a suboption = Specify that the Binding Update needs a new header number = Specify that the Binding Update must follow AH whenever AH is present. This will allow use of AH in the future, but allow the use of other authentication algorithms which can be specified directly to depend on specialized key exchange protocols as has been discussed recently. - other minor fixes that have been reported. I believe these fixes conform to recent consensus, do not represent a significant upheaval to existing implementations, and may help to make future discussion more productive. Comments? Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 20 16:53:38 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03618 for ; Mon, 20 Aug 2001 16:53: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 NAA10575; Mon, 20 Aug 2001 13:53: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 NAA23540; Mon, 20 Aug 2001 13:52:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7KKnfE07126 for mobile-ip-dist; Mon, 20 Aug 2001 13:49:41 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7KKnaL07119 for ; Mon, 20 Aug 2001 13:49: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 NAA09428 for ; Mon, 20 Aug 2001 13:49:35 -0700 (PDT) Received: from netmail.alcatel.com (netmail.alcatel.com [128.251.168.50]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA06751 for ; Mon, 20 Aug 2001 14:49:53 -0600 (MDT) Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6]) by netmail.alcatel.com (8.9.1/8.9.1) with ESMTP id PAA04659 for ; Mon, 20 Aug 2001 15:49:33 -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 f7KKnWf14889 for ; Mon, 20 Aug 2001 15:49:32 -0500 (CDT) Message-ID: <3B8168D3.353E9448@usa.alcatel.com> Date: Mon, 20 Aug 2001 15:45:23 -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] Mobile IPv6 draft revision References: <3B817560.FF84055B@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Charlie, What about security? I suggest waiting a bit until this is resolved and then issue a super-duper final version to go for other steps rather than keep increasing the version numbers 13, 14, 15, etc. "Charles E. Perkins" wrote: > Hello folks, > > Following the recent discussion, I believe a new revision to the > existing Mobile IPv6 draft ...-14 is needed. The new draft would > have the following features: > > - Removal of all text related to Mobile Routers, including the > 'R' bit of the Binding Update > > - Reorganizing the Binding Update format so that: > = authentication data is able to be included as a suboption > = Specify that the Binding Update needs a new header number > = Specify that the Binding Update must follow AH whenever > AH is present. > This will allow use of AH in the future, but allow the use > of other authentication algorithms which can be specified > directly to depend on specialized key exchange protocols > as has been discussed recently. > > - other minor fixes that have been reported. > > I believe these fixes conform to recent consensus, do not > represent a significant upheaval to existing implementations, > and may help to make future discussion more productive. > > Comments? > > Regards, > Charlie P. Kind regards, -- Behcet From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 20 17:06:56 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04338 for ; Mon, 20 Aug 2001 17:06: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 PAA04860; Mon, 20 Aug 2001 15:07: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 OAA27347; Mon, 20 Aug 2001 14:07:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7KL5bK07250 for mobile-ip-dist; Mon, 20 Aug 2001 14:05:37 -0700 (PDT) Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.179.15]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7KL5WL07243 for ; Mon, 20 Aug 2001 14:05:33 -0700 (PDT) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f7KL5H219754; Mon, 20 Aug 2001 23:05:18 +0200 (MET DST) Date: Mon, 20 Aug 2001 23:02:17 +0200 (CEST) From: Erik Nordmark Subject: Re: [mobile-ip] Mobile Routers support without optimization To: James Kempf Cc: mobile-ip@sunroof.eng.sun.com, mat@cisco.com, Erik.Nordmark@eng.sun.com In-Reply-To: "Your message with ID" <200108202011.NAA02394@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: > The only issue is that if the BGP routes are aggregated, > the MR's prefix won't show up in the CN AS routing > tables, though some superprefix will. If as per my > followup message to Erik, one constrains the MR subnet > prefix to be a subprefix of the HA 's prefix, and the HA prefix > to be a subprefix of a prefix in the BGP routing tables, > then would that be enough to let the CN validate? How about an example where this breaks. At home I have a small subnet from my ISP (a /48 with IPv6). The ISP advertises a large chunk (because it is a large ISP) so it might be a /19 that is visible in BGP. I then have a /64 for e.g. my PAN carved out from from my /64. Then it seems like, even given the BGP information, a CN could pontentially think my MR has authority to express binding for the whole /19 that the ISP advertises in BGP. So I frankly can't see how you can use this approach unless you remove the route aggregation used in the Internet. What am I missing? Erik From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 20 17: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 ESMTP id RAA04507 for ; Mon, 20 Aug 2001 17:13: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 OAA18752; Mon, 20 Aug 2001 14:13: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 OAA28558; Mon, 20 Aug 2001 14:13:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7KLCIY07355 for mobile-ip-dist; Mon, 20 Aug 2001 14:12:18 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7KLCEL07348 for ; Mon, 20 Aug 2001 14:12: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 OAA05377; Mon, 20 Aug 2001 14:12:14 -0700 (PDT) Message-Id: <200108202112.OAA05377@heliopolis.eng.sun.com> Date: Mon, 20 Aug 2001 14:12:14 -0700 (PDT) From: James Kempf Subject: Re: [mobile-ip] Mobile Routers support without optimization To: James.Kempf@sun.com, Erik.Nordmark@eng.sun.com Cc: mobile-ip@sunroof.eng.sun.com, mat@cisco.com, Erik.Nordmark@eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: ZreoWOQfdVXc+IjxTMS6Zw== 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: >> The only issue is that if the BGP routes are aggregated, >> the MR's prefix won't show up in the CN AS routing >> tables, though some superprefix will. If as per my >> followup message to Erik, one constrains the MR subnet >> prefix to be a subprefix of the HA 's prefix, and the HA prefix >> to be a subprefix of a prefix in the BGP routing tables, >> then would that be enough to let the CN validate? > >How about an example where this breaks. >At home I have a small subnet from my ISP (a /48 with IPv6). >The ISP advertises a large chunk (because it is a large ISP) >so it might be a /19 that is visible in BGP. > >I then have a /64 for e.g. my PAN carved out from from my /64. > >Then it seems like, even given the BGP information, a CN could pontentially >think my MR has authority to express binding for the whole /19 that the ISP >advertises in BGP. > OK, good point. The only thing one can tell from the BGP tables is that the ISP is allowed to route the /19. It's not possible to tell whether the MR is allowed to route the whole thing or just a subset, so it could lie and hijack the whole thing. So, basically, I'll fall back on my assertion that there is no way for the CN to authenticate that a MR or HA are allowed to route a particular prefix without some out of band authentication mechanism. jak From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 20 17:14:55 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04538 for ; Mon, 20 Aug 2001 17:14: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 PAA10666; Mon, 20 Aug 2001 15:15: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 OAA28931; Mon, 20 Aug 2001 14:15:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7KLDjZ07373 for mobile-ip-dist; Mon, 20 Aug 2001 14:13:45 -0700 (PDT) Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.179.15]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7KLDfL07366 for ; Mon, 20 Aug 2001 14:13:41 -0700 (PDT) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f7KLDP220100; Mon, 20 Aug 2001 23:13:26 +0200 (MET DST) Date: Mon, 20 Aug 2001 23:10:22 +0200 (CEST) From: Erik Nordmark Subject: Re: [mobile-ip] Mobile Routers support without optimization To: petrescu@crm.mot.com, petrescu@acm.org Cc: Erik.Nordmark@eng.sun.com, mobile-ip@sunroof.eng.sun.com, James Kempf In-Reply-To: "Your message with ID" <998334271.3b815f3fa08bc@imp3-1.free.fr> 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: > What I'm having in mind is very simple and probably too dumb to be considered > as a "prefix authorization solution". > > Basically, the CN can send packets to MR's Home Address and to MNN's > Home Address. Those can only be routed to the right addresses. If those > two addresses are required (imposed) to be: matching the first 64 bits > and differring at the 65th then the CN can conclude that the maximum > prefix it can trust for this MR is the respective /65. This seems to be erring in allowing updates for too short prefixes in certain cases. So if the MR and MNN are from different parts of the space (the train model as opposed to the PAN model) then MR's home address could be 1234:5:6:7: and the MNN is 8999:5:6:7: then the addresses differ in the first bit. Hence by the above rules the MR should be able to send a BU for /0! What did I get wrong? Erik From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 20 21: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 ESMTP id VAA09945 for ; Mon, 20 Aug 2001 21:41:02 -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 TAA19036; Mon, 20 Aug 2001 19:41: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 SAA02751; Mon, 20 Aug 2001 18:41:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7L1dEn08468 for mobile-ip-dist; Mon, 20 Aug 2001 18:39:14 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7L1dAm08461 for ; Mon, 20 Aug 2001 18:39:11 -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 SAA21172 for ; Mon, 20 Aug 2001 18:39: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 SAA18499 for ; Mon, 20 Aug 2001 18:39:12 -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 f7L1dBK04588 for ; Tue, 21 Aug 2001 03:39:11 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Tue Aug 21 03:39:10 2001 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 21 Aug 2001 03:32:35 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008BFB@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Mobile IPv6 draft revision Date: Tue, 21 Aug 2001 03:39:04 +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 Charlie, A couple of questions/comments below > - Reorganizing the Binding Update format so that: > = authentication data is able to be included as a suboption > => Is this needed ? Based on the point below we can eliminate this completely. There was a concern on how this would work with IKE. Will that be addressed ? > = Specify that the Binding Update needs a new header number > => Should this one be kept for MIPv6 options as well ? Like the home adderss option for example. Hesham From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 20 21:48:08 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10018 for ; Mon, 20 Aug 2001 21:48:03 -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 SAA18833; Mon, 20 Aug 2001 18: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 SAA03698; Mon, 20 Aug 2001 18:48:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7L1kn208590 for mobile-ip-dist; Mon, 20 Aug 2001 18:46:49 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7L1kjm08583 for ; Mon, 20 Aug 2001 18:46: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 SAA19019 for ; Mon, 20 Aug 2001 18:46: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 TAA21660 for ; Mon, 20 Aug 2001 19:47: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 SAA18471 for ; Mon, 20 Aug 2001 18:46:46 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f7L1kkk15861 for ; Mon, 20 Aug 2001 18:46:46 -0700 X-mProtect: Mon, 20 Aug 2001 18:46:46 -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 smtpdQfb1Ev; Mon, 20 Aug 2001 18:46:44 PDT Message-ID: <3B81BD56.90F0C58A@iprg.nokia.com> Date: Mon, 20 Aug 2001 18:45:58 -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] Mobile IPv6 draft revision References: <034BEFD03799D411A59F00508BDF754603008BFB@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, > > - Reorganizing the Binding Update format so that: > > = authentication data is able to be included as a suboption > > > => Is this needed ? Based on the point below we can eliminate > this completely. There was a concern on how this would > work with IKE. Will that be addressed ? I don't know what to put in the draft about IKE. I understand we're not supposed to be messing with IKE, and I am pretty sure it's too much work to mandate for all correspondent nodes. > > = Specify that the Binding Update needs a new header number > > > => Should this one be kept for MIPv6 options as well ? > Like the home adderss option for example. The home address option does not have to be authenticated. I reckon that the Binding Acknowledgement would need to have a new header number also -- or else if there is a need to conserve those numbers it could have the same header number as the Binding Update. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 20 21:52:40 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10105 for ; Mon, 20 Aug 2001 21:52:39 -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 TAA23970; Mon, 20 Aug 2001 19:53: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 SAA04283; Mon, 20 Aug 2001 18:53:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7L1oZx08680 for mobile-ip-dist; Mon, 20 Aug 2001 18:50:35 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7L1oVm08665 for ; Mon, 20 Aug 2001 18:50: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 SAA19398 for ; Mon, 20 Aug 2001 18:50: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 SAA20692 for ; Mon, 20 Aug 2001 18:50:01 -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 f7L1o0v27648 for ; Tue, 21 Aug 2001 03:50:00 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Tue Aug 21 03:49:59 2001 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 21 Aug 2001 03:43:24 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008BFC@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] draft-soliman-mobileip-flow-move-00.txt as a WG item ? Date: Tue, 21 Aug 2001 03:49: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: Folks, After some discussion with the chairs I'm writing this mail to ask whether anyone has any objection to allowing this draft to be resubmitted as a WG item: http://standards.ericsson.net/hesham//draft-soliman-mobileip-flow-move-00.txt The draft was not presented in London, however the draft was originally part of HMIPv6 (load balancing) but was removed to reduce the scope of HMIPv6. This was based on feedback from the WG in Minneapolis. Abstract 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. Some of the comments that were received before London and will be added to the new revision: - Split the flow movement suboption to 2: One relying on the flow label and another using port numbers. This will save a significant amount of BW over the air. - Add a new section to describe the modifications to the Binding Cache's Conceptual data structure. Any objections ? Regs, Hesham From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 20 21: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 ESMTP id VAA10148 for ; Mon, 20 Aug 2001 21:56: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 SAA21159; Mon, 20 Aug 2001 18:57: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 SAA05117; Mon, 20 Aug 2001 18:57:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7L1u3h08864 for mobile-ip-dist; Mon, 20 Aug 2001 18:56:03 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7L1txm08853 for ; Mon, 20 Aug 2001 18:55:59 -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 SAA19878 for ; Mon, 20 Aug 2001 18:56:02 -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 TAA24351 for ; Mon, 20 Aug 2001 19:56:18 -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 f7L1u0v28015 for ; Tue, 21 Aug 2001 03:56:00 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Tue Aug 21 03:55:59 2001 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 21 Aug 2001 03:49:24 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008BFD@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Mobile IPv6 draft revision Date: Tue, 21 Aug 2001 03:55: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 Charlie, > > > - Reorganizing the Binding Update format so that: > > > = authentication data is able to be included as a suboption > > > > > => Is this needed ? Based on the point below we can eliminate > > this completely. There was a concern on how this would > > work with IKE. Will that be addressed ? > > I don't know what to put in the draft about IKE. I understand we're > not supposed to be messing with IKE, and I am pretty sure it's too > much work to mandate for all correspondent nodes. > => I wasn't suggesting mandating it, but to allow it as an option. I didn't raise the IKE DOI issue and I don't know enough about IKE to help here but I thought it was worth reminding you about this since you're updating the draft. > > > = Specify that the Binding Update needs a new header number > > > > > => Should this one be kept for MIPv6 options as well ? > > Like the home adderss option for example. > > The home address option does not have to be authenticated. > => I undersand but it would make sense to avoid having another header if we alow the authentication data in the BU option. This is the hypothetical scenario: The BU carries its own authentication data. In this case the Home address option need not be in the DST-1 header. So it can be placed in the same "new" ext header. Provided that there was nothing else in a DST header we've saved the overhead of one ext header. > I reckon that the Binding Acknowledgement would need to have > a new header number also -- or else if there is a need to conserve > those numbers it could have the same header number as the > Binding Update. > => Definitely use the same ext header. There is no reason for a separate one as far as I can see. Hesham From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 20 21:58:45 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10167 for ; Mon, 20 Aug 2001 21:58: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 TAA24490; Mon, 20 Aug 2001 19:54: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 SAA04612; Mon, 20 Aug 2001 18:54:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7L1qVR08722 for mobile-ip-dist; Mon, 20 Aug 2001 18:52:31 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7L1qRm08715 for ; Mon, 20 Aug 2001 18:52:27 -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 SAA04229 for ; Mon, 20 Aug 2001 18:52:30 -0700 (PDT) Received: from iol.unh.edu (mars.iol.unh.edu [132.177.121.222]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA22623 for ; Mon, 20 Aug 2001 18:52:29 -0700 (PDT) Received: from BRINSTAR (norfair.iol.unh.edu [132.177.118.42]) by iol.unh.edu (8.9.3/8.9.3) with SMTP id VAA24495 for ; Mon, 20 Aug 2001 21:52:28 -0400 (EDT) From: "John Leser" To: Subject: [mobile-ip] Mobile Router Route Optimization Date: Mon, 20 Aug 2001 21:52:01 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal In-Reply-To: Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi folks, Just to throw some more fuel on the fire, I question the value of allowing an MR to bind anything other than /128 with a CN. As an alternative, let's say the MR, when it detects that an MNN is communicating with some CN, sends a BU just for that MNN's address to the CN. In effect, it sends a normal BU on behalf of the MNN, but using the MR's COA. The obvious downside is that when multiple MNNs are communicating with the same CN, more BUs will be sent. (One BU per MNN, per CN, rather than just one per CN). The two upsides are that CN binding cache lookup remains simple (exact address match), and that BU authentication isn't any harder than it is in the non-router case (MR must have whatever credentials needed to bind each MNN's address, just as it would for its own address). The MR would still bind prefixes with its home agent, which is much easier, assuming we expect the HA to have been preconfigured with the prefixes to expect from each MR. This is the expectation, as I've gathered from discussion on this list. -John From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 20 23:41:25 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12375 for ; Mon, 20 Aug 2001 23:41: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 VAA03273; Mon, 20 Aug 2001 21: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 UAA01013; Mon, 20 Aug 2001 20:41:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7L3dtA09197 for mobile-ip-dist; Mon, 20 Aug 2001 20:39:55 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7L3dqm09190 for ; Mon, 20 Aug 2001 20:39:52 -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 UAA28656; Mon, 20 Aug 2001 20:39: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 UAA27183; Mon, 20 Aug 2001 20:39: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 UAA22766; Mon, 20 Aug 2001 20:39:52 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f7L3dqx01382; Mon, 20 Aug 2001 20:39:52 -0700 X-mProtect: Mon, 20 Aug 2001 20:39:52 -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 smtpdRI07ja; Mon, 20 Aug 2001 20:39:50 PDT Message-ID: <3B81D753.C24F36A5@iprg.nokia.com> Date: Mon, 20 Aug 2001 20:36:52 -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 CC: James Kempf , Erik.Nordmark@eng.sun.com Subject: Re: [mobile-ip] Mobile Routers support without optimization 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 Erik, Erik Nordmark wrote: > > The point I think I was trying to make is that the PAN network > > is strictly a leaf, i.e. there is no other router somewhere > > routing out of the PAN network into the Internet. > > Good point. I expect that everybody assumes that the mobile network > is a leaf - it might be a multihomed leaf in some cases (with multiple > routers towards the rest of the Internet) but it makes no sense for the > mobile network to be a transit for other packets. While I am willing to agree with the probable result of your statement, I don't agree with the statement itself. It _does_ make sense for a mobile network to be a transit network. On the other hand, we don't have to solve that problem in this working group. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 21 02:54:49 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01156 for ; Tue, 21 Aug 2001 02: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 XAA16050; Mon, 20 Aug 2001 23:55: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 XAA02499; Mon, 20 Aug 2001 23:55:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7L6rKG09633 for mobile-ip-dist; Mon, 20 Aug 2001 23:53:20 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7L6rHm09626 for ; Mon, 20 Aug 2001 23:53:17 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA18049 for ; Mon, 20 Aug 2001 23:53:18 -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 AAA06431 for ; Tue, 21 Aug 2001 00:53:36 -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 f7L6rFv26714 for ; Tue, 21 Aug 2001 08:53:15 +0200 (MEST) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id IAA21932; Tue, 21 Aug 2001 08:53:15 +0200 Message-ID: <3B8204EB.4A265734@era.ericsson.se> Date: Tue, 21 Aug 2001 08:51:23 +0200 From: Mattias Pettersson Organization: Ericsson Research X-Mailer: Mozilla 4.77 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile Router Route Optimization 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 John Leser wrote: > > Hi folks, > > Just to throw some more fuel on the fire, I question the value of allowing > an MR to bind anything other than /128 with a CN. > > As an alternative, let's say the MR, when it detects that an MNN is > communicating with some CN, sends a BU just for that MNN's address to the > CN. In effect, it sends a normal BU on behalf of the MNN, but using the > MR's COA. The obvious downside is that when multiple MNNs are communicating > with the same CN, more BUs will be sent. (One BU per MNN, per CN, rather > than just one per CN). The two upsides are that CN binding cache lookup > remains simple (exact address match), and that BU authentication isn't any > harder than it is in the non-router case (MR must have whatever credentials > needed to bind each MNN's address, just as it would for its own address). > > The MR would still bind prefixes with its home agent, which is much easier, > assuming we expect the HA to have been preconfigured with the prefixes to > expect from each MR. This is the expectation, as I've gathered from > discussion on this list. > Hi John, This is exactly my position too. /Mattias From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 21 03:00:38 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01308 for ; Tue, 21 Aug 2001 03:00:38 -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 AAA17245; Tue, 21 Aug 2001 00:01:22 -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 AAA03079; Tue, 21 Aug 2001 00:01:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7L6xvZ09734 for mobile-ip-dist; Mon, 20 Aug 2001 23:59:57 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7L6xrm09727 for ; Mon, 20 Aug 2001 23:59:53 -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 XAA22825 for ; Mon, 20 Aug 2001 23:59:55 -0700 (PDT) Received: from iproxy1.ericsson.dk (iproxy1.ericsson.dk [130.228.248.98]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA08532 for ; Tue, 21 Aug 2001 01:00:13 -0600 (MDT) Received: from unixmail.ted.dk.eu.ericsson.se (knud.ted.dk.eu.ericsson.se [192.66.4.246]) by iproxy1.ericsson.dk (8.10.1/8.10.1) with ESMTP id f7L6xqc25932 for ; Tue, 21 Aug 2001 08:59:52 +0200 (MET DST) Received: from ted.ericsson.dk (petg.ted.dk.eu.ericsson.se [192.66.4.85]) by unixmail.ted.dk.eu.ericsson.se (8.10.1/8.10.1/TEDmain-1.0) with ESMTP id f7L6xlL02527; Tue, 21 Aug 2001 08:59:47 +0200 (MEST) Message-ID: <3B8206E3.CDDA87F2@ted.ericsson.dk> Date: Tue, 21 Aug 2001 08:59:47 +0200 From: Peter Grimstrup Organization: Ericsson Telebit A/S X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile IPv6 draft revision References: <034BEFD03799D411A59F00508BDF754603008BFD@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 A few comments mainly from an implementation point of view: In draft-13, the MIPv6 protocol data was put into up to *2* Destination Option Headers. These headers had to be placed correctly in between the other ext-headers (before/after AH). Another (not yet defined) dest-opt header could be in the packet. That wasn't very clean. I should like to see new header extension types defined in the same breathing as the requirement on ordering of all the extension headers. That said, if possible, I favour putting *all* MIPv6 data (incl. Home Address Option) into *one* new extension header type. Peter "Hesham Soliman (ERA)" wrote: > > > > > = Specify that the Binding Update needs a new header number > > > > > > > => Should this one be kept for MIPv6 options as well ? > > > Like the home adderss option for example. > > > > The home address option does not have to be authenticated. > > > => I undersand but it would make sense to avoid having another > header if we alow the authentication data in the BU option. > This is the hypothetical scenario: > The BU carries its own authentication data. In this case the Home > address option need not be in the DST-1 header. So it can be placed > in the same "new" ext header. Provided that there was nothing else > in a DST header we've saved the overhead of one ext header. > > > I reckon that the Binding Acknowledgement would need to have > > a new header number also -- or else if there is a need to conserve > > those numbers it could have the same header number as the > > Binding Update. > > > => Definitely use the same ext header. There is no reason for > a separate one as far as I can see. > > Hesham -- Peter Grimstrup Systems Developer Ericsson Telebit A/S tel: +45 89 38 52 75 Skanderborgvej 232 fax: +45 89 38 51 01 DK 8260 Viby J, Denmark e-mail: peter.grimstrup@ted.ericsson.dk From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 21 03:54:35 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02294 for ; Tue, 21 Aug 2001 03:54: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 BAA09186; Tue, 21 Aug 2001 01: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 AAA20973; Tue, 21 Aug 2001 00:54:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7L7qJ309893 for mobile-ip-dist; Tue, 21 Aug 2001 00:52:19 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7L7qGm09886 for ; Tue, 21 Aug 2001 00:52: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 AAA27491 for ; Tue, 21 Aug 2001 00:52:18 -0700 (PDT) From: jarno.rajahalme@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA04921 for ; Tue, 21 Aug 2001 00:52:16 -0700 (PDT) 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 f7L7qd312473 for ; Tue, 21 Aug 2001 10:52:39 +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, 21 Aug 2001 10:52:14 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MSVXWWV>; Tue, 21 Aug 2001 10:52:14 +0300 Message-ID: <009CA59D1752DD448E07F8EB2F911757197FD7@esebe004.NOE.Nokia.com> To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] IPsec, IKE, MIPv6 and concensus Date: Tue, 21 Aug 2001 10:52:00 +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: Hesham wrote: > > Before London, we agreed that (2) can be solved in 2 > different ways: > > > > A. Use a new Ext Header value for MIPv6 BUs. This will not > > involve any modifications to the IPsec implementations. > > > > => note this extension header must be final (and of course UDP with > > a well known port does the job in 256 time cheaper way :-). > > > => Sure. I was just trying to minimise the impct on MIPv6 > implementations. Since everything is already Kernel based. > Just a note that it would not be impossible to build UDP based protocols in kernel. But why does the Mobile IP signaling _need_ to be in the kernel in the first place? > > Of course both A and B rely on eliminating piggybacking > of the BUs. > > > > => Yeh! > > This is not true at all. There is always the case when there is no IPsec SA required for the payload itself and there would be absolutely no harm done by piggybacking. Only when the payload and the BU need different SAs could piggybacking not be done. Jarno From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 21 04:07:58 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02419 for ; Tue, 21 Aug 2001 04:07: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 CAA16850; Tue, 21 Aug 2001 02:08: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 BAA23964; Tue, 21 Aug 2001 01:08:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7L86YO10017 for mobile-ip-dist; Tue, 21 Aug 2001 01:06:34 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7L86Pm10010 for ; Tue, 21 Aug 2001 01:06: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 BAA25387 for ; Tue, 21 Aug 2001 01:06:24 -0700 (PDT) From: jarno.rajahalme@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA11655 for ; Tue, 21 Aug 2001 01:06:23 -0700 (PDT) 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 f7L86k323588 for ; Tue, 21 Aug 2001 11:06:46 +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, 21 Aug 2001 11:06:21 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MSVXXWK>; Tue, 21 Aug 2001 11:06:21 +0300 Message-ID: <009CA59D1752DD448E07F8EB2F91175715D485@esebe004.NOE.Nokia.com> To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Mobile Router conversation Date: Tue, 21 Aug 2001 11:06:14 +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: Mattias Pettersson wrote: > > That > > said, I can understand completely the desire to try to come up > > with a solution within the MIP framework, especially for cases > > such as a PAN, since they look like they may be coming along sooner > > than expected. > > > > Throw in a NAT, if you want a quick solution... ;) > This is very important point, IMO, since NAT in the mobile router will most likely be the implementation effort benchmark considered by vendors implementing mobile routers for PANs. And for IPv4 probably the only implementation choice available. Just keep this in mind when considering the candidate solutions, Jarno From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 21 04:25:00 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02548 for ; Tue, 21 Aug 2001 04:25: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 CAA26780; Tue, 21 Aug 2001 02:25:45 -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 BAA11263; Tue, 21 Aug 2001 01:25:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7L8NZV10137 for mobile-ip-dist; Tue, 21 Aug 2001 01:23:35 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7L8NTm10125 for ; Tue, 21 Aug 2001 01:23:29 -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 BAA27162 for ; Tue, 21 Aug 2001 01:23:32 -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 CAA17383 for ; Tue, 21 Aug 2001 02:23:49 -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 f7L8NTK21605 for ; Tue, 21 Aug 2001 10:23:29 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Tue Aug 21 10:23:28 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Tue, 21 Aug 2001 10:23:29 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008C02@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] IPsec, IKE, MIPv6 and concensus Date: Tue, 21 Aug 2001 10:23: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: > > > Before London, we agreed that (2) can be solved in 2 > > different ways: > > > > > > A. Use a new Ext Header value for MIPv6 BUs. This will not > > > involve any modifications to the IPsec implementations. > > > > > > => note this extension header must be final (and of course UDP with > > > a well known port does the job in 256 time cheaper way :-). > > > > > => Sure. I was just trying to minimise the impct on MIPv6 > > implementations. Since everything is already Kernel based. > > > > Just a note that it would not be impossible to build UDP based protocols in > kernel. But why does the Mobile IP signaling _need_ to be in the kernel in > the first place? > => It's not a matter of why it needs to be in the kernel, it already _is_ in the kernel. It's quite natural to have it in the kernel if the signalling does not require any upper layer protocols. At least that's how the implementations I saw and worked with do it. > > > Of course both A and B rely on eliminating piggybacking > > of the BUs. > > > > > > => Yeh! > > > > > This is not true at all. There is always the case when there is no IPsec SA > required for the payload itself and there would be absolutely no harm done > by piggybacking. Only when the payload and the BU need different SAs could > piggybacking not be done. > => Yes but you can't design a standard that only works sometimes. Hesham From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 21 04:48:09 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02815 for ; Tue, 21 Aug 2001 04:48: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 BAA17309; Tue, 21 Aug 2001 01:48: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 BAA15083; Tue, 21 Aug 2001 01:48:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7L8kXg10260 for mobile-ip-dist; Tue, 21 Aug 2001 01:46:33 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7L8kTm10253 for ; Tue, 21 Aug 2001 01:46:29 -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 BAA14753 for ; Tue, 21 Aug 2001 01:46:32 -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 BAA01744 for ; Tue, 21 Aug 2001 01:46:30 -0700 (PDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (motgate 2.1) with ESMTP id BAA15250 for ; Tue, 21 Aug 2001 01:46:29 -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 BAA24185 for ; Tue, 21 Aug 2001 01:46:29 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r4.mot.com with ESMTP; Tue, 21 Aug 2001 03:46:28 -0500 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 246862ECF8; Tue, 21 Aug 2001 10:45:39 +0200 (CEST) To: mobile-ip@sunroof.eng.sun.com Cc: James Kempf , Erik.Nordmark@eng.sun.com Subject: Re: [mobile-ip] Mobile Routers support without optimization References: <3B81D753.C24F36A5@iprg.nokia.com> From: Alexandru Petrescu Date: 21 Aug 2001 10:46:25 +0200 In-Reply-To: <3B81D753.C24F36A5@iprg.nokia.com> Message-Id: Lines: 15 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: Charlie Perkins writes: > It _does_ make sense for a mobile network to be a transit network. Could you, please, give an example of it? I can only imagine that the moving subnet has other sub-subnets under it and it would transit packets to those sub-subnets. Those would still be leafs. > On the other hand, we don't have to solve that problem in this > working group. Yes, is there another better adapted place where one could discuss about this? Alex From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 21 05:13:25 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03021 for ; Tue, 21 Aug 2001 05:13: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 DAA24980; Tue, 21 Aug 2001 03:13: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 CAA09387; Tue, 21 Aug 2001 02:13:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7L9CGl10394 for mobile-ip-dist; Tue, 21 Aug 2001 02:12:16 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7L9C6m10387 for ; Tue, 21 Aug 2001 02:12: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 CAA09237 for ; Tue, 21 Aug 2001 02:12:09 -0700 (PDT) Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA23512 for ; Tue, 21 Aug 2001 02:12:09 -0700 (PDT) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate3.mot.com (motgate3 2.1) with ESMTP id CAA02323 for ; Tue, 21 Aug 2001 02:03:28 -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 CAA15852 for ; Tue, 21 Aug 2001 02:03:15 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r2.mot.com with ESMTP; Tue, 21 Aug 2001 04:11:02 -0500 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 1D4392ED01; Mon, 20 Aug 2001 19:30:43 +0200 (CEST) To: mobile-ip@sunroof.eng.sun.com Cc: James Kempf , Erik.Nordmark@eng.sun.com Subject: Re: [mobile-ip] Mobile Routers support without optimization References: From: Alexandru Petrescu Date: 20 Aug 2001 19:31:29 +0200 In-Reply-To: Message-Id: Lines: 26 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.0.103 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f7L9CDm10388 Sender: owner-mobile-ip@sunroof.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 Erik Nordmark writes: > Are you assuming that any CN would (for instance) accept a BU for a > /64 prefix from anybody? How can the CN verify the authority for > such a BU? Let me give it a try, thanks for reading it. MNN-away from home sends packet to CN; MR-away-from-home intercepts and sends BU to CN containing that MNN's home address, MR's home address and probably others. Upon receipt of BU, CN sends request packets to MR's home address and MNN's home address that are intercepted by HA. HA replies to CN ok. The requirement is to have MR's home address and MNN's home address match their first /64 bits and differ on later bits. The position of first differing bit (say the 65th bit) gives the length of prefix that MR can claim. The MR can claim /65. In other words, when receiving a prefix BU, a CN should accept it only if (1) it has answers from HA for MNN's home address and for MR's home address and (2) if MNN's home address and MR's home address respect the above requirement. I hope it's not too naïve, Alex From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 21 05:43:33 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03371 for ; Tue, 21 Aug 2001 05:43:32 -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 CAA06283; Tue, 21 Aug 2001 02:44: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 CAA11978; Tue, 21 Aug 2001 02:43:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7L9gtU10619 for mobile-ip-dist; Tue, 21 Aug 2001 02:42:55 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7L9gpm10612 for ; Tue, 21 Aug 2001 02:42:51 -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 CAA11882 for ; Tue, 21 Aug 2001 02:42:54 -0700 (PDT) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA06299 for ; Tue, 21 Aug 2001 02:42:54 -0700 (PDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id CAA23022 for ; Tue, 21 Aug 2001 02:42:54 -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 CAA26503 for ; Tue, 21 Aug 2001 02:42:53 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r1.mot.com with ESMTP; Tue, 21 Aug 2001 04:42:52 -0500 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 44BA32ECAC; Tue, 21 Aug 2001 11:42:04 +0200 (CEST) To: mobile-ip@sunroof.eng.sun.com Cc: Erik.Nordmark@eng.sun.com, James Kempf Subject: Re: [mobile-ip] Mobile Routers support without optimization References: From: Alexandru Petrescu Date: 21 Aug 2001 11:42:51 +0200 In-Reply-To: Message-Id: Lines: 38 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: Erik Nordmark writes: > > What I'm having in mind is very simple and probably too dumb to be considered > > as a "prefix authorization solution". > > > Basically, the CN can send packets to MR's Home Address and to MNN's > > Home Address. Those can only be routed to the right addresses. If those > > two addresses are required (imposed) to be: matching the first 64 bits > > and differring at the 65th then the CN can conclude that the maximum > > prefix it can trust for this MR is the respective /65. > > This seems to be erring in allowing updates for too short prefixes > in certain cases. > > So if the MR and MNN are from different parts of the space (the train model > as opposed to the PAN model) then MR's home address could be > 1234:5:6:7: > and the MNN is > 8999:5:6:7: > then the addresses differ in the first bit. > Hence by the above rules the MR should be able to send a BU for /0! Yes, that is correct. Numero uno: this boils down to decide if we put a requirement on a moving network to accept or not the visits of other moving networks or of other mobile nodes. Let's decide. Numero due: similarly to the requirement on MR's home address and MNN's home address, another can be put between MR's HA address, MR's Home Address and MNN's home address. This could solve the case you mention above. Note that in the example you give above, I presume that PAN visits train. In that case, CN will probe different HA's (train MR's and PAN MR's), thus my tests would work. I need to know, if we talk only PAN case, is it possible to impose such a restriction (MR's home address and MNN's home address fit on claimed prefix -1)? Alex From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 21 06:01:52 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03574 for ; Tue, 21 Aug 2001 06:01: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 DAA11893; Tue, 21 Aug 2001 03:02: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 DAA21268; Tue, 21 Aug 2001 03:02:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7LA0gO10745 for mobile-ip-dist; Tue, 21 Aug 2001 03:00:42 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LA0cm10738 for ; Tue, 21 Aug 2001 03:00: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 DAA07461 for ; Tue, 21 Aug 2001 03:00:38 -0700 (PDT) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA13301 for ; Tue, 21 Aug 2001 03:00:38 -0700 (PDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id DAA01587 for ; Tue, 21 Aug 2001 03:00:38 -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 DAA19643 for ; Tue, 21 Aug 2001 03:00:37 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r3.mot.com with ESMTP; Tue, 21 Aug 2001 05:00:17 -0500 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id C70582ECAC; Tue, 21 Aug 2001 11:59:38 +0200 (CEST) To: mobile-ip@sunroof.eng.sun.com Cc: charliep@iprg.nokia.com Subject: Re: [mobile-ip] Mobile IPv6 draft revision References: <3B817560.FF84055B@iprg.nokia.com> From: Alexandru Petrescu Date: 21 Aug 2001 12:00:25 +0200 In-Reply-To: <3B817560.FF84055B@iprg.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: "Charles E. Perkins" writes: > I believe these fixes conform to recent consensus, do not > represent a significant upheaval to existing implementations, > and may help to make future discussion more productive. > > Comments? How about a consistency requirement for HA to join all-routers mc address, in some cases? The cases where it is required to send RA's. Thanks, Alex From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 21 06:06:28 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03612 for ; Tue, 21 Aug 2001 06:06:27 -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 EAA25580; Tue, 21 Aug 2001 04:07: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 DAA21910; Tue, 21 Aug 2001 03:06:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7LA5xM10861 for mobile-ip-dist; Tue, 21 Aug 2001 03:05:59 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LA5um10854 for ; Tue, 21 Aug 2001 03:05:56 -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 DAA07953 for ; Tue, 21 Aug 2001 03:05:56 -0700 (PDT) From: jarno.rajahalme@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA04027 for ; Tue, 21 Aug 2001 04:06:12 -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 f7LA6H311740 for ; Tue, 21 Aug 2001 13:06:17 +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, 21 Aug 2001 13:05:52 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MSVX90B>; Tue, 21 Aug 2001 13:04:51 +0300 Message-ID: <009CA59D1752DD448E07F8EB2F911757197FD8@esebe004.NOE.Nokia.com> To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] IPsec, IKE, MIPv6 and concensus Date: Tue, 21 Aug 2001 13:04: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: Hesham wrote: > > > > Of course both A and B rely on eliminating piggybacking > > > of the BUs. > > > > > > > > => Yeh! > > > > > > > > This is not true at all. There is always the case when > there is no IPsec SA > > required for the payload itself and there would be > absolutely no harm done > > by piggybacking. Only when the payload and the BU need > different SAs could > > piggybacking not be done. > > > => Yes but you can't design a standard that only works > sometimes. > The scenario is: - Need to send a BU to a CN - If there is an outgoing packet to the CN in a queue, and - the packet is not associated with any SA - then can piggyback the BU with the packet in the queue - else send BU as a separate packet If the spec allowed for this, would it be broken in some way? Sure this is a performance optimization only, and the degree of the benefit depends heavily on the type of L2's in both ends, feature interaction with HC, etc., but if done right there is nothing that would make the standard "only work sometimes". It is quite customary that standards have options that are not always used. Additionally, you would not need to implement this, if you don't want. The recipient would need to be able to process piggybacked BUs, but for that no-one needs to do *anything*, if there is a e.g. a separate next header value for the BU etc. Not a single line of code required. If Mobile IP signaling stays in the network layer headers, the standard actually does not need to state anything about piggybacking. It would _just work_, if implemented? That is, unless the spec. actually mandates NO transport layer stuff after the Mobile IP header. So it seems that it would suffice for the spec to state if transport level stuff is allowed after the Mobile IP header(s) or not. Jarno From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 21 06:44:09 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03919 for ; Tue, 21 Aug 2001 06:44: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 DAA24002; Tue, 21 Aug 2001 03:44: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 DAA24892; Tue, 21 Aug 2001 03:44:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7LAgxl11050 for mobile-ip-dist; Tue, 21 Aug 2001 03:42:59 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LAgtm11043 for ; Tue, 21 Aug 2001 03:42: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 DAA09404 for ; Tue, 21 Aug 2001 03:42:56 -0700 (PDT) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA18838 for ; Tue, 21 Aug 2001 04:43:13 -0600 (MDT) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id DAA19859 for ; Tue, 21 Aug 2001 03:42:54 -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 DAA18517 for ; Tue, 21 Aug 2001 03:42:54 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r4.mot.com with ESMTP; Tue, 21 Aug 2001 05:39:54 -0500 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 823402ECAC; Tue, 21 Aug 2001 12:39:05 +0200 (CEST) To: mobile-ip@sunroof.eng.sun.com Cc: James.Kempf@Sun.COM, Erik.Nordmark@eng.sun.com Subject: Re: [mobile-ip] Mobile Routers support without optimization References: <200108201737.KAA25667@heliopolis.eng.sun.com> From: Alexandru Petrescu Date: 21 Aug 2001 12:39:52 +0200 In-Reply-To: <200108201737.KAA25667@heliopolis.eng.sun.com> Message-Id: Lines: 22 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: James Kempf writes: > Since the subnet prefix that the MR sends in the BU must be on the > home subnet of the MR, one can require that the HA route a subnet > that includes, under it, the subnet routed by the MR. Since the HR > controls the routes to that prefix, it should be able to tell the CN > whether the MN is authorized to provide routing updates. The CN can > verify that the MR is the same one that it talked to before by the > solution for MIP host BU security. Me too I see it this way. As I said earlier, I'm wondering it's feasible to put a requirement that "the subnet prefix that the MR sends in the BU must be on the home subnet of the MR". As a counterexample against this requirement, there's a case when I take two ISP's, one gives me a prefix, the other gives me another prefix. I keep one prefix for my home and the other for my PAN. But this is also something like being at home at linking the two ISP's together, not very nice. Alex From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 21 07:00:41 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04097 for ; Tue, 21 Aug 2001 07:00: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 EAA28975; Tue, 21 Aug 2001 04:01: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 EAA25803; Tue, 21 Aug 2001 04:00:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7LAwNf11166 for mobile-ip-dist; Tue, 21 Aug 2001 03:58:23 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LAwKm11159 for ; Tue, 21 Aug 2001 03:58:20 -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 DAA16863 for ; Tue, 21 Aug 2001 03:58:21 -0700 (PDT) From: fritsche@iabg.de Received: from iabgfw.iabg.de (iabgfw.iabg.de [194.139.245.2]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA03344 for ; Tue, 21 Aug 2001 03:58:20 -0700 (PDT) Received: by iabgfw.iabg.de; id MAA24527; Tue, 21 Aug 2001 12:58:17 +0200 (MET DST) Received: from unknown(10.255.255.2) by iabgfw.iabg.de via smap (V5.5) id xma024524; Tue, 21 Aug 01 12:58:11 +0200 Received: from iabgvw.iabg.de ([10.255.255.8]) by iabgmh.iabg.de (Post.Office MTA v3.5.1 release 219 ID# 127-59214U1600L300S0V35) with ESMTP id de for ; Tue, 21 Aug 2001 12:58:09 +0200 Received: from iabgdns.iabg.de (localhost [127.0.0.1]) by iabgvw.iabg.de (8.8.8+Sun/8.8.8) with ESMTP id MAA05336 for ; Tue, 21 Aug 2001 12:58:04 +0200 (MET DST) Received: from ziegenlippe (ziegenlippe.iabg.de [10.15.0.185]) by iabgdns.iabg.de (8.8.8+Sun/8.8.8) with SMTP id MAA18428 for ; Tue, 21 Aug 2001 12:58:11 +0200 (MET DST) Message-Id: <200108211058.MAA18428@iabgdns.iabg.de> Comments: Authenticated sender is To: mobile-ip@sunroof.eng.sun.com Date: Tue, 21 Aug 2001 12:58:11 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: RE: [mobile-ip] IPsec, IKE, MIPv6 and concensus In-reply-to: <009CA59D1752DD448E07F8EB2F911757197FD8@esebe004.NOE.Nokia.com> X-mailer: Pegasus Mail for Win32 (v2.54DE) Sender: owner-mobile-ip@sunroof.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 > Jarno wrote: > > > > > Of course both A and B rely on eliminating piggybacking > > > > of the BUs. > > > > > > > > > > => Yeh! > > > > > > > > > > > This is not true at all. There is always the case when > > there is no IPsec SA > > > required for the payload itself and there would be > > absolutely no harm done > > > by piggybacking. Only when the payload and the BU need > > different SAs could > > > piggybacking not be done. > > > > > => Yes but you can't design a standard that only works > > sometimes. > > > > The scenario is: > > - Need to send a BU to a CN > - If there is an outgoing packet to the CN in a queue, and > - the packet is not associated with any SA > - then can piggyback the BU with the packet in the queue > - else send BU as a separate packet But what will happen if at a later time it becomes necessary to have a SA also for the payload? IPSec will detect, that there is already one (with no idea, that it has been established for Mobile IP BUs), which probably will not match the security policy for the payload. So should the Mobile IP SA be overridden? How do you inform Mobile IP about that? You won't have such problems without piggybacking. > If the spec allowed for this, would it be broken in some way? > > Sure this is a performance optimization only, and the degree of the benefit > depends heavily on the type of L2's in both ends, feature interaction with > HC, etc., but if done right there is nothing that would make the standard > "only work sometimes". It is quite customary that standards have options > that are not always used. > > Additionally, you would not need to implement this, if you don't want. The > recipient would need to be able to process piggybacked BUs, but for that > no-one needs to do *anything*, if there is a e.g. a separate next header > value for the BU etc. Not a single line of code required. > > If Mobile IP signaling stays in the network layer headers, the standard > actually does not need to state anything about piggybacking. It would _just > work_, if implemented? That is, unless the spec. actually mandates NO > transport layer stuff after the Mobile IP header. > > So it seems that it would suffice for the spec to state if transport level > stuff is allowed after the Mobile IP header(s) or not. > > Jarno > Wolfgang From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 21 07:55:41 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06317 for ; Tue, 21 Aug 2001 07:55: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 FAA21497; Tue, 21 Aug 2001 05:56:20 -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 EAA14494; Tue, 21 Aug 2001 04:55:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7LBsgN11387 for mobile-ip-dist; Tue, 21 Aug 2001 04:54:42 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LBscm11380 for ; Tue, 21 Aug 2001 04:54:38 -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 EAA14404 for ; Tue, 21 Aug 2001 04:54:40 -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 EAA22888 for ; Tue, 21 Aug 2001 04:54:39 -0700 (PDT) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id EAA18481 for ; Tue, 21 Aug 2001 04:54:38 -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 EAA09198 for ; Tue, 21 Aug 2001 04:54:38 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r2.mot.com with ESMTP for mobile-ip@sunroof.eng.sun.com; Tue, 21 Aug 2001 06:54:36 -0500 Received: from crm.mot.com (nero.crm.mot.com [140.101.173.36]) by thorgal.crm.mot.com (Postfix) with ESMTP id 0A58F2ECAC for ; Tue, 21 Aug 2001 13:53:48 +0200 (CEST) Message-Id: <3B824BF7.2FDFA92@crm.mot.com> Date: Tue, 21 Aug 2001 13:54:31 +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 Subject: Re: [mobile-ip] IPsec, IKE, MIPv6 and concensus References: <200108211058.MAA18428@iabgdns.iabg.de> Content-Type: multipart/mixed; boundary="------------44C4ADD12D18D979B928CBB3" Sender: owner-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. --------------44C4ADD12D18D979B928CBB3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit fritsche@iabg.de wrote: > > But what will happen if at a later time it becomes necessary to have > a SA also for the payload? IPSec will detect, that there is already > one (with no idea, that it has been established for Mobile IP BUs), > which probably will not match the security policy for the payload. So > should the Mobile IP SA be overridden? How do you inform Mobile IP > about that? > There is an idea I suggested a few weeks ago... We may want to solve that issue creating new algorithm numbers for IPsec, let's say MIP-SHA1 and MIP-MD5. Those algorithms would be considered as "very week" by IPsec policy management entity, so when a security association is to be established with a peer from which a BU has already been received, the SA parameters will be renegociated. Alexis. --------------44C4ADD12D18D979B928CBB3 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 --------------44C4ADD12D18D979B928CBB3-- From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 21 08:37:19 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08550 for ; Tue, 21 Aug 2001 08:37: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 FAA28748; Tue, 21 Aug 2001 05:37: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 FAA18031; Tue, 21 Aug 2001 05:36:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7LCZ0t11612 for mobile-ip-dist; Tue, 21 Aug 2001 05:35:00 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LCYum11605 for ; Tue, 21 Aug 2001 05:34: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 FAA19014 for ; Tue, 21 Aug 2001 05:34:58 -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 FAA11226 for ; Tue, 21 Aug 2001 05:34:57 -0700 (PDT) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate.mot.com (motgate 2.1) with ESMTP id FAA00682 for ; Tue, 21 Aug 2001 05:34:56 -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 FAA24573 for ; Tue, 21 Aug 2001 05:34:56 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r4.mot.com with ESMTP; Tue, 21 Aug 2001 07:34:55 -0500 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 6CFC02ECAC; Tue, 21 Aug 2001 14:34:06 +0200 (CEST) To: mobile-ip@sunroof.eng.sun.com Cc: Erik.Nordmark@eng.sun.com, James Kempf Subject: Re: [mobile-ip] Mobile Routers support without optimization References: From: Alexandru Petrescu Date: 21 Aug 2001 14:34:53 +0200 In-Reply-To: Message-Id: Lines: 15 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: Alexandru Petrescu writes: > Numero due: similarly to the requirement on MR's home address and > MNN's home address, another can be put between MR's HA address, MR's > Home Address and MNN's home address. This could solve the case you > mention above. This "delta" thing between addresses will probably allow an attacker to falsely claim a whole prefix when all he has is in fact some addresses of that prefix. This however leads to the question: "could a provider assign a prefix (except 2 addresses) to somebody and the 2 addresses to somebody else?" Alex From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 21 09:12:09 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10577 for ; Tue, 21 Aug 2001 09:12: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 GAA09490; Tue, 21 Aug 2001 06:12: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 GAA27178; Tue, 21 Aug 2001 06:12:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7LDAx011836 for mobile-ip-dist; Tue, 21 Aug 2001 06:10:59 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LDAtm11829 for ; Tue, 21 Aug 2001 06:10: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 GAA06530 for ; Tue, 21 Aug 2001 06:10:58 -0700 (PDT) From: jarno.rajahalme@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA01675 for ; Tue, 21 Aug 2001 07:11:14 -0600 (MDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7LDBI323033 for ; Tue, 21 Aug 2001 16:11:18 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 21 Aug 2001 16:10:49 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MSVYKCR>; Tue, 21 Aug 2001 16:10:49 +0300 Message-ID: <009CA59D1752DD448E07F8EB2F911757197FDA@esebe004.NOE.Nokia.com> To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] IPsec, IKE, MIPv6 and concensus Date: Tue, 21 Aug 2001 16:10:38 +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: Wolfgang wrote: > > Jarno wrote: > > The scenario is: > > > > - Need to send a BU to a CN > > - If there is an outgoing packet to the CN in a queue, and > > - the packet is not associated with any SA > > - then can piggyback the BU with the packet in the queue > > - else send BU as a separate packet > > But what will happen if at a later time it becomes necessary to have > a SA also for the payload? IPSec will detect, that there is already > one (with no idea, that it has been established for Mobile IP BUs), > which probably will not match the security policy for the payload. So > should the Mobile IP SA be overridden? How do you inform Mobile IP > about that? > The decision whether to piggyback or to send a separate packet must be done separately for each signaling message sent by mobile IP, so I do not understand what you mean with "at a later time". What the actual implementation solution for resolving the possible race condition between two SPD entries (one for Mobile IP, other for the payload) is not important (for this discussion), and does not need to be standardized. It suffices to state that (for example): "Mobile IP header (TBD) may be followed by transport headers only if the transport protocol message can be sent with the Security Association used for protecting Mobile IP itself." If you do not want to find a solution how to do this, never piggyback. It is a tradeoff with possible complexity of checking the SPD in the right places, and getting the efficiency of piggybacking. But this tradeoff should have no interoperability consequences, so there is no need for standardizing anything new for this. > You won't have such problems without piggybacking. > Again, this issue can be left to the implementers of to decide. No-one is forced to piggyback. Reception of piggybacked transport PDU should happen with current standards. Or am I still missing something? What adverse effects you see with piggybacking, with the assumption that the originating host knows when it can/not piggyback? Jarno From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 21 09:47:39 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12920 for ; Tue, 21 Aug 2001 09:47: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 HAA05010; Tue, 21 Aug 2001 07:47: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 GAA01585; Tue, 21 Aug 2001 06:47:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7LDfxh12006 for mobile-ip-dist; Tue, 21 Aug 2001 06:41:59 -0700 (PDT) Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.179.15]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LDftm11999 for ; Tue, 21 Aug 2001 06:41:55 -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 f7LDfr227953; Tue, 21 Aug 2001 15:41:53 +0200 (MET DST) Date: Tue, 21 Aug 2001 15:38:44 +0200 (CEST) From: Erik Nordmark Subject: Re: [mobile-ip] Mobile Routers support without optimization To: Alexandru Petrescu Cc: mobile-ip@sunroof.eng.sun.com, Erik.Nordmark@eng.sun.com, James Kempf In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > Yes, that is correct. Numero uno: this boils down to decide if we put > a requirement on a moving network to accept or not the visits of other > moving networks or of other mobile nodes. Let's decide. I don't think it matters what we decide on that one. The key thing is that we need rules that the CN can use to do authorization checks. Those rules better not be circumventable by having any subset of HA, MR, and MNN conspire to fool the CN. Or stated differently, given that the CN doesn't trust anything but the ability of the routing system to deliver packets, on a best effort basis, to the destination IP address, how can the CN develop any trust in a remote entity stating that it should receive packets for a whole prefix? I don't see how techniques like SUCV can help here - they inherently bind a key to a single IP address and I don't even think it is meaningful to bind a key to a prefix. > Numero due: similarly to the requirement on MR's home address and > MNN's home address, another can be put between MR's HA address, MR's > Home Address and MNN's home address. This could solve the case you > mention above. The CN would still need to trust untrustworthy entities. Erik > Note that in the example you give above, I presume that PAN visits > train. In that case, CN will probe different HA's (train MR's and PAN > MR's), thus my tests would work. > > I need to know, if we talk only PAN case, is it possible to impose > such a restriction (MR's home address and MNN's home address fit on > claimed prefix -1)? > > Alex > From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 21 09:57:56 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13675 for ; Tue, 21 Aug 2001 09:57: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 HAA12579; Tue, 21 Aug 2001 07:58: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 GAA02945; Tue, 21 Aug 2001 06:58:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7LDutB12224 for mobile-ip-dist; Tue, 21 Aug 2001 06:56:55 -0700 (PDT) Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.179.15]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LDupm12217 for ; Tue, 21 Aug 2001 06:56:51 -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 f7LDuk229591; Tue, 21 Aug 2001 15:56:46 +0200 (MET DST) Date: Tue, 21 Aug 2001 15:53:37 +0200 (CEST) From: Erik Nordmark Subject: Re: [mobile-ip] Mobile Routers support without optimization To: Alexandru Petrescu Cc: mobile-ip@sunroof.eng.sun.com, Erik.Nordmark@eng.sun.com, James Kempf In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > This "delta" thing between addresses will probably allow an attacker > to falsely claim a whole prefix when all he has is in fact some > addresses of that prefix. > > This however leads to the question: "could a provider assign a prefix > (except 2 addresses) to somebody and the 2 addresses to somebody > else?" [Using IPv4 prefixes since they are shorter than IPv6 - and net 10 to avoid pointing any assigned IP address space.] A provider might assign 10.1.0.0/16 to user A 10.2.0.0/16 to user B 10.3.0.0/16 to user A This creates "holes" thus in your proposal this can be used by A to claim the space assigned to B. Erik From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 21 10:04:38 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14235 for ; Tue, 21 Aug 2001 10:04:38 -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 HAA29569; Tue, 21 Aug 2001 07:04:24 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA03804; Tue, 21 Aug 2001 07:03:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7LE1cn12353 for mobile-ip-dist; Tue, 21 Aug 2001 07:01:38 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LE1Ym12346 for ; Tue, 21 Aug 2001 07:01: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 HAA03583 for ; Tue, 21 Aug 2001 07:01: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 IAA14802 for ; Tue, 21 Aug 2001 08:01:32 -0600 (MDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f7LE1YK14149; Tue, 21 Aug 2001 16:01:34 +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 f7LE1X506689; Tue, 21 Aug 2001 17:01:33 +0300 (EET DST) Message-ID: <3B8269BD.64565AEB@lmf.ericsson.se> Date: Tue, 21 Aug 2001 17:01:33 +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: jarno.rajahalme@nokia.com, hesham.soliman@era.ericsson.se CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] IPsec, IKE, MIPv6 and concensus References: <009CA59D1752DD448E07F8EB2F911757197FDA@esebe004.NOE.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 It does seem that Jarno's scheme allows piggybacking where "security allows it". Nice idea. Then I would also like to comment on Hesham's original questions, do you want to completely disallow IPsec and IKE, or do you want to use them in some situations. Personally, I think there are situations where we'd like to use IPsec/IKE, and to have them protect also the Mobile IP signalling. Of course you have to be able to use also the PKI-less, weak authentication in the global Internet. Finally, I would also like to note that the solution space for BU protection is more fine grained than "Use IPsec for everything" and "Don't Use IPsec At All": - Application specific protection, i.e. the use of the mechanism defined in the -14 version of the v6 draft. - Existing IPsec AH with a new next header value for BUs. In this alternative we can use the current versions of IPsec AH and IP Security Architecture since BUs are not piggybacked to other packets. It may be possible to use this with Jarno's idea, allowing piggybacking if security isn't needed. - IPsec AH with policy extensions. Certain extensions to the current requirements for security policy data bases and SA selectors are needed in order to protect BUs that are embedded in the Destinations Options header of packets possibly containing also other payloads. - Application specific protection with optional, additional IPsec protection. For instance, we use the -14 mechanism and the weak authentication in all situations, but apply additional also IPsec and IKE where a suitable PKI exists, such as in corporations. This application may affect simply just all packets, in which case the policy granularity issues are not a concern. Standard IPsec applies here also in this case. Frankly, I'm not quite sure which of these alternatives I would prefer. I kind of like the second alternative, though the first isn't bad either. Fourth would also be a good option, and I'm not sure people have discussed it yet much. I don't particularly like the third option. In all of these options, we should better document exactly how we can do the things we want, and what the limitations are. For instance, in the first alternative we should make crystal clear to everyone that we won't be doing strong authentication ever, unless the weak authentication protocols are extended to support also strong authentication [which would be a bad idea in my opinion]. In the fourth alternative we need a clear section in the spec that tells people an additional layer of security can be run in certain situations, and exactly how. Jari From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 21 11:00:41 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18865 for ; Tue, 21 Aug 2001 11:00: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 IAA28370; Tue, 21 Aug 2001 08:55: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 HAA20383; Tue, 21 Aug 2001 07:55:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7LErtk12603 for mobile-ip-dist; Tue, 21 Aug 2001 07:53:55 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LErmm12596 for ; Tue, 21 Aug 2001 07:53: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 HAA09866 for ; Tue, 21 Aug 2001 07:53:49 -0700 (PDT) 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 IAA29456 for ; Tue, 21 Aug 2001 08:54:05 -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 f7LErqi07473 for ; Tue, 21 Aug 2001 09:53:52 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 21 Aug 2001 09:53:47 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 21 Aug 2001 09:53:47 -0500 content-class: urn:content-classes:message Subject: RE: [mobile-ip] Improvement in Proxy DAD functionality for Mobility Support in IPv6 Date: Tue, 21 Aug 2001 09:53:46 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF441E843E@daebe007.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [mobile-ip] Improvement in Proxy DAD functionality for Mobility Support in IPv6 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Thread-Index: AcEpo2f6etg2qJWUEdWxLgAIx6TWeAAradNQ From: "Patil Basavaraj (NET/Dallas)" To: Cc: , "Perkins Charles (IPRG/MtView)" X-OriginalArrivalTime: 21 Aug 2001 14:53:47.0137 (UTC) FILETIME=[14B77710:01C12A51] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f7LErnm12597 Sender: owner-mobile-ip@sunroof.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 >Section 9.2 of the draft says that when the MN requests the HA to no >longer serve as it's HA (returns home) : > >"In addition, the home agent MUST stop intercepting packets on the >mobile node's home link addressed to the mobile node (Section 9.3)."... > >I feel this step should also apply for the HA when the binding cache >entry expires. > > >I would like to suggest that the draft be modified to say that when an >entry in the binding cache expires, the home agent MUST stop >intercepting packets on the mobile node's home link addressed to >the mobile node. > I guess your suggestion is to add further clarification in section 9.2 detailing the behavior when the lifetime of a binding expires. If the lifetime of the binding for an MN expires, does the HA send out a "gratuitous" Neighbor Advertisement message on the home link? >I would appreciate any comments on this issue. > >Thanks, > >- KK > >Krishna Kumar -Basavaraj From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 21 11:24:59 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20164 for ; Tue, 21 Aug 2001 11:24: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 JAA24079; Tue, 21 Aug 2001 09:24: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 IAA25367; Tue, 21 Aug 2001 08:24:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7LFMpk12881 for mobile-ip-dist; Tue, 21 Aug 2001 08:22:51 -0700 (PDT) Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.179.15]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LFMkm12874 for ; Tue, 21 Aug 2001 08:22:47 -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 f7LFMh210986; Tue, 21 Aug 2001 17:22:43 +0200 (MET DST) Date: Tue, 21 Aug 2001 17:19:35 +0200 (CEST) From: Erik Nordmark Subject: Re: [mobile-ip] Mobile IPv6 draft revision To: Peter Grimstrup Cc: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3B8206E3.CDDA87F2@ted.ericsson.dk> 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 should like to see new header extension types defined in the same > breathing as the requirement on ordering of all the extension headers. > That said, if possible, I favour putting *all* MIPv6 data (incl. Home Address > Option) into *one* new extension header type. Currently the Home Address option is sent from MNs to CNs and all CNs must know how to interpret this in order for communication to work. (The TCP connection should be identified using the address in the Home Address option and not the IPv6 source address of the packet, etc). I think some (I don't know how many) of the shipping IPv6 implementations do this. I don't know if a sufficiently large number of IPv6 implementations of CNs will support this to make things interoperate with MIPv6 MNs. However, if the WG takes the path of putting the information currently in the Home Address option into the new extension header as you propose, then some new mechanisms need to be constructed to be able to detect when a CN doesn't understand the new extension header. (Note that this is not an issue for the CN not understanding the BU - ignoring the BU just has the effect of not optimizing the routing.) A possible way of handling this would be for the MN to notice when it receives an ICMP parameter problem with code payload type unknown that the CN might not support it. The the MN, instead of using the new extension header to carry the home address, would need to tunnel the packet through the HA (reverse tunnel). Of course, if the WG is interested in this level surgery it would also make sense to seriously consider the proposal that Bill Sommerfeld made not long ago of replacing the use of routing header and home address option with just IP in IP encapsulation, perhaps with optimized encapsulation formats when only one extra IP address is needed in the packet. Erik From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 21 11:30:41 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20449 for ; Tue, 21 Aug 2001 11:30: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 JAA29102; Tue, 21 Aug 2001 09:30:31 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA26701; Tue, 21 Aug 2001 08:30:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7LFT2D12967 for mobile-ip-dist; Tue, 21 Aug 2001 08:29:02 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LFSwm12960 for ; Tue, 21 Aug 2001 08:28: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 IAA08548 for ; Tue, 21 Aug 2001 08:29:00 -0700 (PDT) Message-Id: <200108211529.IAA08548@heliopolis.eng.sun.com> Date: Tue, 21 Aug 2001 08:29:00 -0700 (PDT) From: James Kempf Subject: Re: [mobile-ip] draft-soliman-mobileip-flow-move-00.txt as a WG item ? To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: iZK2CRqjarUXQ1kj6LwePw== 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 would prefer to wait on making this a working group item. While intertechnology handover is an important topic, it is not clear at this point what the requirements are and whether a change in MIPv6 is really necessary. It might rather be an item for Seamoby, for example. I have not had time to review this draft in detail, and would prefer a more comprehensive discussion on intertechnology handover prior to committing to working group items, as opposed to picking and choosing particular mechanisms piecemeal. The latter approach has poorly served the working group in the past. jak >From: "Hesham Soliman (ERA)" >To: "'mobile-ip@sunroof.eng.sun.com'" >Subject: [mobile-ip] draft-soliman-mobileip-flow-move-00.txt as a WG item ? >Date: Tue, 21 Aug 2001 03:49:52 +0200 > >Folks, > >After some discussion with the chairs I'm writing this mail to >ask whether anyone has any objection to allowing this draft to >be resubmitted as a WG item: >http://standards.ericsson.net/hesham//draft-soliman-mobileip-flow-move-00.txt > >The draft was not presented in London, however the draft was originally >part of HMIPv6 (load balancing) but was removed to reduce the scope >of HMIPv6. This was based on feedback from the WG in Minneapolis. > >Abstract > > 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. > > >Some of the comments that were received before London and >will be added to the new revision: > >- Split the flow movement suboption to 2: One relying on the flow > label and another using port numbers. This will save a significant > amount of BW over the air. > >- Add a new section to describe the modifications to the Binding > Cache's Conceptual data structure. > >Any objections ? > >Regs, >Hesham From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 21 11:31:02 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20490 for ; Tue, 21 Aug 2001 11:31: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 IAA09497; Tue, 21 Aug 2001 08:31: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 IAA26759; Tue, 21 Aug 2001 08:30:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7LFTPP12980 for mobile-ip-dist; Tue, 21 Aug 2001 08:29:25 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LFTLm12973 for ; Tue, 21 Aug 2001 08:29: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 IAA15648 for ; Tue, 21 Aug 2001 08:29:22 -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 JAA24409 for ; Tue, 21 Aug 2001 09:29:39 -0600 (MDT) Received: from inrialpes.fr (galibier.inrialpes.fr [194.199.24.97]) by ebene.inrialpes.fr (8.11.3/8.11.3) with ESMTP id f7LFPxi25899 for ; Tue, 21 Aug 2001 17:25:59 +0200 (MEST) Message-ID: <3B827E2A.90A7A19D@inrialpes.fr> Date: Tue, 21 Aug 2001 17:28:42 +0200 From: Thierry Ernst Organization: INRIA Rhone-Alpes X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile Router Route Optimization 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 John Leser wrote: > > Hi folks, > > Just to throw some more fuel on the fire, I question the value of allowing > an MR to bind anything other than /128 with a CN. > > As an alternative, let's say the MR, when it detects that an MNN is > communicating with some CN, sends a BU just for that MNN's address to the > CN. In effect, it sends a normal BU on behalf of the MNN, but using the > MR's COA. The obvious downside is that when multiple MNNs are communicating > with the same CN, more BUs will be sent. (One BU per MNN, per CN, rather > than just one per CN). We thought about that in the first place. I think that such solution would lead to flooding the network with BUs. All your family is in the same car and each member has a session with grand-ma. Why would all members send a BU to grand-ma when you could aggregate it ? Prefix-scope BUs leaves room for more optimizations. > The two upsides are that CN binding cache lookup > remains simple (exact address match), and that BU authentication isn't any > harder than it is in the non-router case (MR must have whatever credentials > needed to bind each MNN's address, just as it would for its own address). I disagree. Authentication is not an upside. A node should not be allowed to send a BU 'on behalf' of another node. Here, it's not a matter of authorization, but a matter of authentication. Are you willing the MR to authenticate on behalf of yourself ? I am not sure the MR has whatever credentials for this, particularly if the MNN is a VMN, nor that it would be such a good idea.You are in a flight, would you allow the aircraft company to authenticate on-behalf of you ? I can imagine transient issues. In the prefix-scope BU proposal, the BU is sent by the MR and the MR is authenticated as being the one it claims to be. Whether or not MR has the right to advertise the BU is an authorization issue, not authentication issue. I would prefer this scenario. BTW, couldn't we rely on certificates to authorize a MR to send a BU for a prefix /p ? I am not a securiry guy, then this might not make sense, but no one gave my a no-reply to this when I first mentioned it. Thierry. > The MR would still bind prefixes with its home agent, which is much easier, > assuming we expect the HA to have been preconfigured with the prefixes to > expect from each MR. This is the expectation, as I've gathered from > discussion on this list. > > -John -- * 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 Tue Aug 21 11:33:19 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20664 for ; Tue, 21 Aug 2001 11:33:18 -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 JAA02138; Tue, 21 Aug 2001 09:33: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 IAA27630; Tue, 21 Aug 2001 08:33:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7LFW1q13078 for mobile-ip-dist; Tue, 21 Aug 2001 08:32:01 -0700 (PDT) Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.179.15]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LFVvm13067 for ; Tue, 21 Aug 2001 08:31:57 -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 f7LFVs211915; Tue, 21 Aug 2001 17:31:54 +0200 (MET DST) Date: Tue, 21 Aug 2001 17:28:46 +0200 (CEST) From: Erik Nordmark Subject: RE: [mobile-ip] IPsec, IKE, MIPv6 and concensus To: jarno.rajahalme@nokia.com Cc: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <009CA59D1752DD448E07F8EB2F911757197FD8@esebe004.NOE.Nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > The scenario is: > > - Need to send a BU to a CN > - If there is an outgoing packet to the CN in a queue, and > - the packet is not associated with any SA > - then can piggyback the BU with the packet in the queue > - else send BU as a separate packet > > If the spec allowed for this, would it be broken in some way? Someone (I forgot who) pointed out that even this was a problem for careful implementations of IPsec. The claim (which I understand and agree with) is that a TCP connection would like to use the same security policy for the lifetime of the connection. If you don't then how can you use IPsec to prevent a unsecure RST packet from blowing away your connection? Thus if the packet is piggyback on a TCP SYN packet the peer is likely to assume that all of that TCP connection will be secured, but that will not be the case since the SYN was only secured as a site effect of securing the piggy-backed BU. I don't know if there are similar issues for the reverse case when the connection starts off not being protected by IPsec and later a single TCP packet is protected by IPsec. > Sure this is a performance optimization only, and the degree of the benefit > depends heavily on the type of L2's in both ends, feature interaction with > HC, etc., but if done right there is nothing that would make the standard > "only work sometimes". It is quite customary that standards have options > that are not always used. But such options are a possible source of interoperability problems ... Erik From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 21 11:33:58 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20685 for ; Tue, 21 Aug 2001 11:33: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 JAA02633; Tue, 21 Aug 2001 09:33: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 IAA27751; Tue, 21 Aug 2001 08:33:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7LFW7D13095 for mobile-ip-dist; Tue, 21 Aug 2001 08:32:07 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LFW3m13084 for ; Tue, 21 Aug 2001 08:32: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 IAA08706 for ; Tue, 21 Aug 2001 08:32:05 -0700 (PDT) Message-Id: <200108211532.IAA08706@heliopolis.eng.sun.com> Date: Tue, 21 Aug 2001 08:32:05 -0700 (PDT) From: James Kempf Subject: Re: [mobile-ip] Mobile Router Route Optimization To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: uRqT+vJlvmt21bv7hTbKuw== 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: John, Good points. The alternative, of course, is that the MR could run a NAT and all the hosts behind the MR have private addresses. When the MR moves, the MR can do route optimization for the external addresses. None of the nodes behind the MR need to be mobile aware in this case. The question is what has the larger downside: triangle routing or not having the benefits of end-to-end, like push? jak >From: "John Leser" >To: >Subject: [mobile-ip] Mobile Router Route Optimization >Date: Mon, 20 Aug 2001 21:52:01 -0400 >X-Priority: 3 (Normal) >X-MSMail-Priority: Normal >X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 >Importance: Normal > >Hi folks, > >Just to throw some more fuel on the fire, I question the value of allowing >an MR to bind anything other than /128 with a CN. > >As an alternative, let's say the MR, when it detects that an MNN is >communicating with some CN, sends a BU just for that MNN's address to the >CN. In effect, it sends a normal BU on behalf of the MNN, but using the >MR's COA. The obvious downside is that when multiple MNNs are communicating >with the same CN, more BUs will be sent. (One BU per MNN, per CN, rather >than just one per CN). The two upsides are that CN binding cache lookup >remains simple (exact address match), and that BU authentication isn't any >harder than it is in the non-router case (MR must have whatever credentials >needed to bind each MNN's address, just as it would for its own address). > >The MR would still bind prefixes with its home agent, which is much easier, >assuming we expect the HA to have been preconfigured with the prefixes to >expect from each MR. This is the expectation, as I've gathered from >discussion on this list. > >-John > From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 21 11: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 ESMTP id LAA21646 for ; Tue, 21 Aug 2001 11:54: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 IAA21813; Tue, 21 Aug 2001 08:53: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 IAA00690; Tue, 21 Aug 2001 08:47:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7LFk4713431 for mobile-ip-dist; Tue, 21 Aug 2001 08:46:04 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LFk0m13424 for ; Tue, 21 Aug 2001 08:46:00 -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 IAA18934 for ; Tue, 21 Aug 2001 08:46:02 -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 IAA13320 for ; Tue, 21 Aug 2001 08:46:00 -0700 (PDT) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate.mot.com (motgate 2.1) with ESMTP id IAB14089 for ; Tue, 21 Aug 2001 08:45:59 -0700 (MST)] Received: [from m-il06-r3.mot.com (m-il06-r3.mot.com [129.188.137.194]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id IAA20140 for ; Tue, 21 Aug 2001 08:45:58 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r3.mot.com with ESMTP for mobile-ip@sunroof.eng.sun.com; Tue, 21 Aug 2001 10:45:52 -0500 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id E83072ECF8 for ; Tue, 21 Aug 2001 17:45:06 +0200 (CEST) To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile Router Route Optimization References: <3B827E2A.90A7A19D@inrialpes.fr> From: Alexandru Petrescu Date: 21 Aug 2001 17:45:54 +0200 In-Reply-To: <3B827E2A.90A7A19D@inrialpes.fr> Message-Id: Lines: 14 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.0.103 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f7LFk1m13425 Sender: owner-mobile-ip@sunroof.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 Thierry Ernst writes: [...] > BTW, couldn't we rely on certificates to authorize a MR to send a BU for > a prefix /p ? I am not a securiry guy, then this might not make sense, > but no one gave my a no-reply to this when I first mentioned it. Thierry, d'après ma compréhension, quand les gens disent "certificates" alors c'est du pulbic-key infrastructure... Mais je ne sais pas sûr... Alex From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 21 11:57:26 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21751 for ; Tue, 21 Aug 2001 11:57: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 JAA23857; Tue, 21 Aug 2001 09:57: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 IAA20930; Tue, 21 Aug 2001 08:56:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7LFtUj13559 for mobile-ip-dist; Tue, 21 Aug 2001 08:55:30 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LFtRm13552 for ; Tue, 21 Aug 2001 08:55: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 IAA20684 for ; Tue, 21 Aug 2001 08:55:28 -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 IAA20124 for ; Tue, 21 Aug 2001 08:55:26 -0700 (PDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (motgate 2.1) with ESMTP id IAA22617 for ; Tue, 21 Aug 2001 08:55:26 -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 IAA27415 for ; Tue, 21 Aug 2001 08:55:25 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r1.mot.com with ESMTP for mobile-ip@sunroof.eng.sun.com; Tue, 21 Aug 2001 10:55:24 -0500 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id C95D42ECAC for ; Tue, 21 Aug 2001 17:54:34 +0200 (CEST) To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile Router Route Optimization References: <3B827E2A.90A7A19D@inrialpes.fr> From: Alexandru Petrescu Date: 21 Aug 2001 17:55:22 +0200 In-Reply-To: Message-Id: Lines: 19 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.0.103 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f7LFtRm13553 Sender: owner-mobile-ip@sunroof.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 writes: > Thierry Ernst writes: > > [...] > > > BTW, couldn't we rely on certificates to authorize a MR to send a BU for > > a prefix /p ? I am not a securiry guy, then this might not make sense, > > but no one gave my a no-reply to this when I first mentioned it. > > Thierry, d'après ma compréhension, quand les gens disent > "certificates" alors c'est du pulbic-key infrastructure... > > Mais je ne sais pas sûr... Sorry for that message, it should have been To: Thierry only. It says that probably "certificates" are related to PKI. Alex From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 21 12: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 ESMTP id MAA21937 for ; Tue, 21 Aug 2001 12:01: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 KAA27838; Tue, 21 Aug 2001 10:01: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 JAA21963; Tue, 21 Aug 2001 09:01:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7LFxuL13658 for mobile-ip-dist; Tue, 21 Aug 2001 08:59:56 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LFxfm13646; Tue, 21 Aug 2001 08: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 IAA02765; Tue, 21 Aug 2001 08:59:43 -0700 (PDT) Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA13478; Tue, 21 Aug 2001 10:00:01 -0600 (MDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id LAA78724; Tue, 21 Aug 2001 11:57:31 -0400 Received: from d03nm066.boulder.ibm.com (d03nm066.boulder.ibm.com [9.99.140.50]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7LFxRA201854; Tue, 21 Aug 2001 09:59:27 -0600 Subject: RE: [mobile-ip] Improvement in Proxy DAD functionality for Mobility Support in IPv6 To: mobile-ip@sunroof.eng.sun.com Cc: "Perkins Charles (IPRG/MtView)" , mobile-ip@sunroof.eng.sun.com, owner-mobile-ip@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Krishna Kumar" Date: Tue, 21 Aug 2001 08:57:50 -0700 X-MIMETrack: Serialize by Router on D03NM066/03/M/IBM(Release 5.0.8 |June 18, 2001) at 08/21/2001 10:03:39 AM 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 Basavaraj, >I guess your suggestion is to add further clarification in section 9.2 >detailing the behavior when the lifetime of a binding expires. You are right. Currently, the behavior when the lifetime expires is to just delete the binding entry. It can be modified to add that the home agent MUST stop intercepting packets on the mobile node's home link addressed to the mobile node. > If the ifetime of the binding for an MN expires, does the HA send out a >"gratuitous" Neighbor Advertisement message on the home link? No, that does not happen. The MN, if it is up and still needs mobility support, would have sent a Binding Update to the HA before the entry expired, but the HA doesn't assume the MN is up unless it gets a fresh Binding Update. Thanks, - KK >>Section 9.2 of the draft says that when the MN requests the HA to no >>longer serve as it's HA (returns home) : >> >>"In addition, the home agent MUST stop intercepting packets on the >>mobile node's home link addressed to the mobile node (Section 9.3)."... >> >>I feel this step should also apply for the HA when the binding cache >>entry expires. >> >> >>I would like to suggest that the draft be modified to say that when an >>entry in the binding cache expires, the home agent MUST stop >>intercepting packets on the mobile node's home link addressed to >>the mobile node. From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 21 12:03:13 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22048 for ; Tue, 21 Aug 2001 12:03: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 JAA26531; Tue, 21 Aug 2001 09:02: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 IAA21239; Tue, 21 Aug 2001 08:58:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7LFv0A13585 for mobile-ip-dist; Tue, 21 Aug 2001 08:57:00 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LFuum13578 for ; Tue, 21 Aug 2001 08:56:56 -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 IAA20979 for ; Tue, 21 Aug 2001 08:56:56 -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 JAA11599 for ; Tue, 21 Aug 2001 09:57: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 f7LFuqQ23165 for ; Tue, 21 Aug 2001 08:56: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 ACY04525; Tue, 21 Aug 2001 08:56:51 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA19488; Tue, 21 Aug 2001 08:56:51 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15234.33987.437007.588741@thomasm-u1.cisco.com> Date: Tue, 21 Aug 2001 08:56:51 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile Router Route Optimization In-Reply-To: <3B827E2A.90A7A19D@inrialpes.fr> References: <3B827E2A.90A7A19D@inrialpes.fr> 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 Thierry Ernst writes: > John Leser wrote: > > As an alternative, let's say the MR, when it detects that an MNN is > > communicating with some CN, sends a BU just for that MNN's address to the > > CN. In effect, it sends a normal BU on behalf of the MNN, but using the > > MR's COA. The obvious downside is that when multiple MNNs are communicating > > with the same CN, more BUs will be sent. (One BU per MNN, per CN, rather > > than just one per CN). > > We thought about that in the first place. I think that such solution > would lead to flooding the network with BUs. All your family is in the > same car and each member has a session with grand-ma. Why would all > members send a BU to grand-ma when you could aggregate it ? > Prefix-scope BUs leaves room for more optimizations. Keeping the end nodes as ignorant as possible of routing is certainly a worthwhile goal, but I'm not convinced that it should be the prime requirement. Recall that this problem is also related to network renumbering so at some level the MN is going to need to integrate its mobility with network renumbering anyway. > I disagree. Authentication is not an upside. A node should not be > allowed to send a BU 'on behalf' of another node. Here, it's not a > matter of authorization, but a matter of authentication. Are you > willing the MR to authenticate on behalf of yourself ? I am not sure > the MR has whatever credentials for this, particularly if the MNN is a > VMN, nor that it would be such a good idea.You are in a flight, would > you allow the aircraft company to authenticate on-behalf of you ? I can > imagine transient issues. If you consider it, this is exactly what the relationship between a router and host/router is: the host delegates responsibility for the packet's fate to the next router, and so on. This is, I think, the root of why this is so difficult. In the current net the trust is built by localized decisions where the objects which need to trust each other are usually well known to each other. Once you bring in any form of tunnel (which route optimization is) you break the localization property unless you can somehow find a way to leverage the current transitive trust model. > > In the prefix-scope BU proposal, the BU is sent by the MR and the MR is > authenticated as being the one it claims to be. Whether or not MR has > the right to advertise the BU is an authorization issue, not > authentication issue. I would prefer this scenario. > > BTW, couldn't we rely on certificates to authorize a MR to send a BU for > a prefix /p ? I am not a securiry guy, then this might not make sense, > but no one gave my a no-reply to this when I first mentioned it. This runs afoul of the same need-a-global-PKI problem that sent MIPv6 back to the WG to figure something else out. Considering the likelihood of very small MR's (your car MR, for example), any certificate based solution would run into the same objections. Mike > > Thierry. > > > The MR would still bind prefixes with its home agent, which is much easier, > > assuming we expect the HA to have been preconfigured with the prefixes to > > expect from each MR. This is the expectation, as I've gathered from > > discussion on this list. > > > > -John > > -- > * 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 Tue Aug 21 12:10:35 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22367 for ; Tue, 21 Aug 2001 12:10: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 KAA07184; Tue, 21 Aug 2001 10:10:49 -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 JAA24300; Tue, 21 Aug 2001 09:10:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7LG9Mx13996 for mobile-ip-dist; Tue, 21 Aug 2001 09:09:22 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LG9Jm13986 for ; Tue, 21 Aug 2001 09:09:19 -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 JAA10505; Tue, 21 Aug 2001 09:09:15 -0700 (PDT) Message-Id: <200108211609.JAA10505@heliopolis.eng.sun.com> Date: Tue, 21 Aug 2001 09:09:15 -0700 (PDT) From: James Kempf Subject: Re: [mobile-ip] Mobile Routers support without optimization To: petrescu@crm.mot.com, Erik.Nordmark@eng.sun.com Cc: mobile-ip@sunroof.eng.sun.com, Erik.Nordmark@eng.sun.com, James.Kempf@Sun.COM MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: QtSkjpLtiGCCjtqO3upvpg== 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: Erik, >> This "delta" thing between addresses will probably allow an attacker >> to falsely claim a whole prefix when all he has is in fact some >> addresses of that prefix. >> >> This however leads to the question: "could a provider assign a prefix >> (except 2 addresses) to somebody and the 2 addresses to somebody >> else?" > >[Using IPv4 prefixes since they are shorter than IPv6 - and net 10 >to avoid pointing any assigned IP address space.] > >A provider might assign > 10.1.0.0/16 to user A > 10.2.0.0/16 to user B > 10.3.0.0/16 to user A > >This creates "holes" thus in your proposal this can be used by A to claim >the space assigned to B. > Suppose the protocol requires the CN to authenticate what prefix A and B are allowed to claim with the HA? The issue then becomes whether the HA can be trusted. Now, suppose the protocol requires that the HA be authenticable via a chain of trust through the routing update authentication mechanism used to authenticate OSPF and BGP routes? jak From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 21 12:12:10 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22418 for ; Tue, 21 Aug 2001 12:12: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 JAA01374; Tue, 21 Aug 2001 09:10: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 JAA23035; Tue, 21 Aug 2001 09:06:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7LG4ww13807 for mobile-ip-dist; Tue, 21 Aug 2001 09:04:58 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LG4sm13800 for ; Tue, 21 Aug 2001 09:04:55 -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 JAA10300; Tue, 21 Aug 2001 09:04:55 -0700 (PDT) Message-Id: <200108211604.JAA10300@heliopolis.eng.sun.com> Date: Tue, 21 Aug 2001 09:04:55 -0700 (PDT) From: James Kempf Subject: Re: [mobile-ip] Mobile Routers support without optimization To: petrescu@crm.mot.com, Erik.Nordmark@eng.sun.com Cc: mobile-ip@sunroof.eng.sun.com, Erik.Nordmark@eng.sun.com, James.Kempf@Sun.COM MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: oyLibQUpt6TrwSL9w7oiRw== 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: Erik, >The key thing is that we need rules that the CN can use to do >authorization checks. >Those rules better not be circumventable by having any subset >of HA, MR, and MNN conspire to fool the CN. > >Or stated differently, given that the CN doesn't trust anything >but the ability of the routing system to deliver packets, on a best >effort basis, to the destination IP address, how can the CN develop any >trust in a remote entity stating that it should receive packets for >a whole prefix? > IHMO, the answer is "by the same means that any router trusts the OSPF or BGP updates from other routers that tell it to send packets to a remote entity for a whole prefix." Or "by a different means that allows the CN via some out-of-band authentication technique to verify that the HA and CN control the prefix in question and therefore have the right to change it". This requirement is fairly strict and go beyond the mobile host requirements of simply proving that the sender of the BU is who you were corresponding with in the past. But perhaps that is as it should be, the consequences of hijacking a routing prefix are much more dire than hijacking an address. jak From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 21 12:13:33 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22455 for ; Tue, 21 Aug 2001 12:13:33 -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 JAA02362; Tue, 21 Aug 2001 09:12: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 JAA23444; Tue, 21 Aug 2001 09:07:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7LG6P913857 for mobile-ip-dist; Tue, 21 Aug 2001 09:06:25 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LG6Lm13850 for ; Tue, 21 Aug 2001 09:06: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 JAA04306 for ; Tue, 21 Aug 2001 09:06:23 -0700 (PDT) Received: from birch.ee.vt.edu (birch.ee.vt.edu [128.173.88.34]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA02826 for ; Tue, 21 Aug 2001 10:06:18 -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 MAA06045 for ; Tue, 21 Aug 2001 12:06:21 -0400 (EDT) Received: (from wells@localhost) by eagle.ee.vt.edu (8.10.2+Sun/8.10.2) id f7LG6Lc25290 for mobile-ip@sunroof.eng.sun.com; Tue, 21 Aug 2001 12:06:21 -0400 (EDT) Date: Tue, 21 Aug 2001 12:06:21 -0400 From: John Wells To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Mobile networking on v4? Message-ID: <20010821120621.A25090@horus.imag.fr> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="17pEHd4RhPHOinZp" 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: --17pEHd4RhPHOinZp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi all, Does anyone know of any v4 work on mobile networking? It would seem that most if not all if not all of this work is concentrated on v6; if v4 resources exist or don't, I'd like to know. Thanks, John --=20 John WELLS Virginia Tech Networking and Visualization Lab PGP Public key: http://www.ee.vt.edu/~wells/pgpkey.txt --17pEHd4RhPHOinZp 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 iD8DBQE7gob8tvPFKAfa3SIRAkUhAJ4rR9fsOC7d/esTAl9P0fCbbpyo7ACggTTB T9CSwqAFlfhArakL45kJOCo= =lxBC -----END PGP SIGNATURE----- --17pEHd4RhPHOinZp-- From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 21 12:19:01 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22617 for ; Tue, 21 Aug 2001 12:19:00 -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 JAA05832; Tue, 21 Aug 2001 09:19: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 JAA25933; Tue, 21 Aug 2001 09:18:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7LGGpx14193 for mobile-ip-dist; Tue, 21 Aug 2001 09:16:51 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LGGlm14186 for ; Tue, 21 Aug 2001 09:16:47 -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 JAA24849 for ; Tue, 21 Aug 2001 09:16:32 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA15935 for ; Tue, 21 Aug 2001 09:16:31 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.5/8.11.5) with ESMTP id f7LGGTL02542 for ; Tue, 21 Aug 2001 18:16:29 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id SAA17940 for ; Tue, 21 Aug 2001 18:16:29 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id f7LGGTl38688 for ; Tue, 21 Aug 2001 18:16:29 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200108211616.f7LGGTl38688@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Improvement in Proxy DAD functionality for Mobility Support in IPv6 In-reply-to: Your message of Mon, 20 Aug 2001 11:06:32 PDT. Date: Tue, 21 Aug 2001 18:16:29 +0200 X-Virus-Scanned: by amavisd-milter (http://www.amavis.org/) at laposte.enst-bretagne.fr Sender: owner-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 would like to suggest that the draft be modified to say that when an entry in the binding cache expires, the home agent MUST stop intercepting packets on the mobile node's home link addressed to the mobile node. => I fully agree. I believe this was already in the text but between lines... Regards Francis.Dupont@enst-bretagne.fr PS: the HA should flush the whole context too, including keys. From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 21 12: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 ESMTP id MAA22799 for ; Tue, 21 Aug 2001 12:26:21 -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 KAA21663; Tue, 21 Aug 2001 10:26: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 JAA27733; Tue, 21 Aug 2001 09:26:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7LGP6p14295 for mobile-ip-dist; Tue, 21 Aug 2001 09:25:06 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LGP2m14288 for ; Tue, 21 Aug 2001 09:25: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 JAA04301 for ; Tue, 21 Aug 2001 09:25:04 -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 JAA20357 for ; Tue, 21 Aug 2001 09:25:04 -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 JAA22486 for ; Tue, 21 Aug 2001 09:25:03 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f7LGP2722278 for ; Tue, 21 Aug 2001 09:25:02 -0700 X-mProtect: Tue, 21 Aug 2001 09:25: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 smtpdzxwD75; Tue, 21 Aug 2001 09:25:00 PDT Message-ID: <3B828B5C.33AD2040@iprg.nokia.com> Date: Tue, 21 Aug 2001 09:25:00 -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@sunroof.eng.sun.com Subject: Re: [mobile-ip] Improvement in Proxy DAD functionality for Mobility Support in IPv6 References: <200108211616.f7LGGTl38688@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Francis, Francis Dupont wrote: > > I would like to suggest that the draft be modified to say that when an > entry in the binding cache expires, the home agent MUST stop > intercepting packets on the mobile node's home link addressed to > the mobile node. > > => I fully agree. I believe this was already in the text but between lines... Right. > PS: the HA should flush the whole context too, including keys. This would be bad for mobile nodes that want to sleep but use the same security association when they wake up a few hours later. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 21 12:48:43 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23516 for ; Tue, 21 Aug 2001 12:48: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 KAA13282; Tue, 21 Aug 2001 10:48:52 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA02574; Tue, 21 Aug 2001 09:48:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7LGlV214469 for mobile-ip-dist; Tue, 21 Aug 2001 09:47:31 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LGlRm14462 for ; Tue, 21 Aug 2001 09:47: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 JAA02553 for ; Tue, 21 Aug 2001 09:47:25 -0700 (PDT) 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 KAA16873 for ; Tue, 21 Aug 2001 10:47:43 -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 f7LGlSi22552 for ; Tue, 21 Aug 2001 11:47:28 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 21 Aug 2001 11:47:23 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 21 Aug 2001 11:47:23 -0500 content-class: urn:content-classes:message Subject: RE: [mobile-ip] Improvement in Proxy DAD functionality for Mobility Support in IPv6 Date: Tue, 21 Aug 2001 11:47:23 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF441E8447@daebe007.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Thread-Topic: [mobile-ip] Improvement in Proxy DAD functionality for Mobility Support in IPv6 Thread-Index: AcEqXgsihVmmW5ZPEdWrxAAIx6S5QwAAuL4g From: "Patil Basavaraj (NET/Dallas)" To: X-OriginalArrivalTime: 21 Aug 2001 16:47:23.0352 (UTC) FILETIME=[F37F5580:01C12A60] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f7LGlRm14463 Sender: owner-mobile-ip@sunroof.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 >>Francis Dupont Wrote: >> PS: the HA should flush the whole context too, including keys. > >Charles Perkins wrote: >This would be bad for mobile nodes that want to sleep but use the same >security association when they wake up a few hours later. > This seems to be an implementation issue. You could specify a large lifetime for the binding and allow MNs to sleep. I think flushing the entire context in case of lifetime expiry of a binding makes sense. >Regards, >Charlie P. -Basavaraj From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 21 13:00:07 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23830 for ; Tue, 21 Aug 2001 13:00: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 KAA26861; Tue, 21 Aug 2001 10:00:44 -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 JAA04736; Tue, 21 Aug 2001 09:58:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7LGvWN14613 for mobile-ip-dist; Tue, 21 Aug 2001 09:57:32 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LGvSm14606 for ; Tue, 21 Aug 2001 09:57: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 JAA04424 for ; Tue, 21 Aug 2001 09:57:30 -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 JAA08238 for ; Tue, 21 Aug 2001 09:57:29 -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 JAA24547 for ; Tue, 21 Aug 2001 09:57:29 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f7LGvS215016 for ; Tue, 21 Aug 2001 09:57:28 -0700 X-mProtect: Tue, 21 Aug 2001 09:57:28 -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 smtpdJTl5T7; Tue, 21 Aug 2001 09:57:26 PDT Message-ID: <3B8292F7.62522382@iprg.nokia.com> Date: Tue, 21 Aug 2001 09:57:27 -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@sunroof.eng.sun.com Subject: Re: [mobile-ip] Improvement in Proxy DAD functionality for Mobility Support in IPv6 References: <697DAA22C5004B4596E033803A7CEF441E8447@daebe007.NOE.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 Basavaraj, > >This would be bad for mobile nodes that want to sleep but use the same > >security association when they wake up a few hours later. > > > > This seems to be an implementation issue. You could specify a large > lifetime for the binding and allow MNs to sleep. I think flushing the > entire context in case of lifetime expiry of a binding makes sense. But these are two different things. The binding has to do with getting packets to go places. The security association has to do with authenticating bindings. Just because the home agent is supposed to stop redirecting packets doesn't mean that it needs to purge the whole means by which binding updates are authenticated. Why make them the same? They aren't even managed in the same part of the code. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 21 13:16:23 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24386 for ; Tue, 21 Aug 2001 13:16: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 LAA09458; Tue, 21 Aug 2001 11:17:04 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA08813; Tue, 21 Aug 2001 10:16:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7LHEuP14782 for mobile-ip-dist; Tue, 21 Aug 2001 10:14:56 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LHErm14775 for ; Tue, 21 Aug 2001 10:14:53 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA08453 for ; Tue, 21 Aug 2001 10:14:49 -0700 (PDT) Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA07160 for ; Tue, 21 Aug 2001 11:14:45 -0600 (MDT) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate4.mot.com (motgate4 2.1) with ESMTP id KAA18474 for ; Tue, 21 Aug 2001 10:14:48 -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 KAA02588 for ; Tue, 21 Aug 2001 10:14:48 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r4.mot.com with ESMTP; Tue, 21 Aug 2001 12:14:46 -0500 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id CAF722ECAC; Tue, 21 Aug 2001 19:13:55 +0200 (CEST) To: mobile-ip@sunroof.eng.sun.com Cc: Erik.Nordmark@eng.sun.com, James Kempf Subject: Re: [mobile-ip] Mobile Routers support without optimization References: From: Alexandru Petrescu Date: 21 Aug 2001 19:14:43 +0200 In-Reply-To: Message-Id: Lines: 26 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: Erik Nordmark writes: > A provider might assign > 10.1.0.0/16 to user A > 10.2.0.0/16 to user B > 10.3.0.0/16 to user A > > This creates "holes" thus in your proposal this can be used by A to claim > the space assigned to B. Indeed. Then let me refine my constraints: (1) HA and MR should match their first n bits and be different on bit n+1 and (2) MNN should longest match n+1 bits either with HA or with MR. Thus CN can rightfuly believe a prefix at most /n+1. For the above case, if MR and HA are on 10.1/16 and MNN on 10.3/16 then MR and HA would match on first 16 bits but MNN would not match that 16 bits. Thus CN will not believe a claim on 10.2/15. For same case, if HA and MNN are on 10.1/16 and MR is on 10.3/16 then HA and MR would match the first 8 bits, MNN would match the 9 (n+1) bits but not longest (it has a longer match 16 with HA). Thus CN will not believe a claim on 10.2/9. I think this can work. Alex From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 21 13:20:39 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24544 for ; Tue, 21 Aug 2001 13:20: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 LAA13414; Tue, 21 Aug 2001 11:21: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 KAA09856; Tue, 21 Aug 2001 10:21:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7LHJfH14898 for mobile-ip-dist; Tue, 21 Aug 2001 10:19:41 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LHJcm14891 for ; Tue, 21 Aug 2001 10:19:38 -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 KAA09437 for ; Tue, 21 Aug 2001 10:19: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 KAA18718 for ; Tue, 21 Aug 2001 10:19: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 KAA26569 for ; Tue, 21 Aug 2001 10:19:39 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f7LHJbe23231 for ; Tue, 21 Aug 2001 10:19:37 -0700 X-mProtect: Tue, 21 Aug 2001 10:19: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 smtpd8suei3; Tue, 21 Aug 2001 10:19:36 PDT Message-ID: <3B829829.555B271F@iprg.nokia.com> Date: Tue, 21 Aug 2001 10:19: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] Improvement in Proxy DAD functionality for Mobility Support in IPv6 References: <697DAA22C5004B4596E033803A7CEF441E8447@daebe007.NOE.Nokia.com> <3B8292F7.62522382@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 when the binding chache entry expires, you send a binding request for the mobile node. if the mobile node does not respond you delete the binding cache entry and the proxy neighbor cache entry. you do not delete the security association the home agent shares with the mobile node. after deleting the proxy neighbor cache entry the home agent does not intercept packet, does not send out neighbor advertisements on behalf of the mobile node. this is the default behavior. Vijay "Charles E. Perkins" wrote: > > Hello Basavaraj, > > > >This would be bad for mobile nodes that want to sleep but use the same > > >security association when they wake up a few hours later. > > > > > > > This seems to be an implementation issue. You could specify a large > > lifetime for the binding and allow MNs to sleep. I think flushing the > > entire context in case of lifetime expiry of a binding makes sense. > > But these are two different things. The binding has to do with > getting packets to go places. The security association has to do > with authenticating bindings. Just because the home agent is supposed > to stop redirecting packets doesn't mean that it needs to purge the > whole means by which binding updates are authenticated. > > Why make them the same? They aren't even managed in the same part > of the code. > > Regards, > Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 21 13:32:14 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24845 for ; Tue, 21 Aug 2001 13:32:13 -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 KAA12662; Tue, 21 Aug 2001 10:31: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 KAA12725; Tue, 21 Aug 2001 10:30:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7LHSfx15092 for mobile-ip-dist; Tue, 21 Aug 2001 10:28:41 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LHSbm15085 for ; Tue, 21 Aug 2001 10:28: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 KAA14736; Tue, 21 Aug 2001 10:28:39 -0700 (PDT) Message-Id: <200108211728.KAA14736@heliopolis.eng.sun.com> Date: Tue, 21 Aug 2001 10:28:39 -0700 (PDT) From: James Kempf Subject: Re: [mobile-ip] Mobile Routers support without optimization To: mobile-ip@sunroof.eng.sun.com, petrescu@crm.mot.com Cc: Erik.Nordmark@eng.sun.com, James.Kempf@Sun.COM MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 4ChD5tHbVxa3Bz3yNSmDpg== 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: Alex, I think you are missing Erik's point. The issue is independent of whether the CN knows the subnet relationship between MN, HA, and MR. The issue is whether the CN can authenticate that the MR is authorized to route the prefix. It is impossible to verify this by an exchange between the CN, MR, and HA without some kind of out-of-band exchange of security material, or a trust relationship that taps into such an out-of-band exchange. jak >To: mobile-ip@sunroof.eng.sun.com >Cc: Erik.Nordmark@eng.sun.com, James Kempf >Subject: Re: [mobile-ip] Mobile Routers support without optimization >From: Alexandru Petrescu >Date: 21 Aug 2001 19:14:43 +0200 >User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.0.103 > >Erik Nordmark writes: >> A provider might assign >> 10.1.0.0/16 to user A >> 10.2.0.0/16 to user B >> 10.3.0.0/16 to user A >> >> This creates "holes" thus in your proposal this can be used by A to claim >> the space assigned to B. > >Indeed. Then let me refine my constraints: (1) HA and MR should match >their first n bits and be different on bit n+1 and (2) MNN should >longest match n+1 bits either with HA or with MR. Thus CN can >rightfuly believe a prefix at most /n+1. > >For the above case, if MR and HA are on 10.1/16 and MNN on 10.3/16 >then MR and HA would match on first 16 bits but MNN would not match >that 16 bits. Thus CN will not believe a claim on 10.2/15. > >For same case, if HA and MNN are on 10.1/16 and MR is on 10.3/16 then >HA and MR would match the first 8 bits, MNN would match the 9 (n+1) >bits but not longest (it has a longer match 16 with HA). Thus CN will >not believe a claim on 10.2/9. > >I think this can work. > >Alex > From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 21 13:53:11 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25521 for ; Tue, 21 Aug 2001 13:53: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 KAA24059; Tue, 21 Aug 2001 10:53:05 -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 KAA17503; Tue, 21 Aug 2001 10:52:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7LHoIg15252 for mobile-ip-dist; Tue, 21 Aug 2001 10:50:19 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LHoFm15245 for ; Tue, 21 Aug 2001 10:50:15 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA24322; Tue, 21 Aug 2001 10:50:17 -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 LAA10263; Tue, 21 Aug 2001 11:50:13 -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 f7LHoKQ07484; Tue, 21 Aug 2001 10: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 ACY08260; Tue, 21 Aug 2001 10:50:15 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA19520; Tue, 21 Aug 2001 10:50:14 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15234.40790.768468.610613@thomasm-u1.cisco.com> Date: Tue, 21 Aug 2001 10:50:14 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Cc: petrescu@crm.mot.com, Erik.Nordmark@eng.sun.com, James.Kempf@Sun.COM Subject: Re: [mobile-ip] Mobile Routers support without optimization In-Reply-To: <200108211604.JAA10300@heliopolis.eng.sun.com> References: <200108211604.JAA10300@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: > IHMO, the answer is "by the same means that any router trusts > the OSPF or BGP updates from other routers that tell it to send packets to a > remote entity for a whole prefix." Or "by a different means that > allows the CN via some out-of-band authentication technique > to verify that the HA and CN control the prefix in question and > therefore have the right to change it". > > This requirement is fairly strict and go beyond the mobile > host requirements of simply proving that the sender of the BU > is who you were corresponding with in the past. But perhaps that > is as it should be, the consequences of hijacking a routing > prefix are much more dire than hijacking an address. There seems to be two separable attacks. First is the attack where a spoofer is not reachable on the prefix it is attempting to control at all. A simple return routability test as is being proposed for MIPv6 ought to provide adequate protection to counter that attack (we hope). The second is when a node which is reachable on the proposed prefix, but is trying to hijack a larger prefix than it is authorized for. I believe that the only nodes which can make a determination as to whether the mobile router is authorized to advertize that prefix to the CN are the routers in the path between MN and CN by way of HA. In fact, it seems that some router between HA and CN ought to know whether it summarizes a prefix which is smaller than the proposed prefix and thus be able to reject the request. That is, suppose we have a MN trying to advertize a /8 to a CN. If the CN sends the proposed BU toward MN (say with router alert on for grins), and a router in the path discovers that it summarizes a /16 toward the MN, then it would know that the request is not legitimate since it must summarize prefixes which are strictly larger than in the downstream direction. Whether this solves all potential attacks, I have no idea, but it does seem to have the potential for solving this particular attack. Mike From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 21 13:58:25 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25629 for ; Tue, 21 Aug 2001 13:58: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 LAA18495; Tue, 21 Aug 2001 11:59: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 KAA19100; Tue, 21 Aug 2001 10:58:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7LHvJ015369 for mobile-ip-dist; Tue, 21 Aug 2001 10:57:19 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LHvFm15362 for ; Tue, 21 Aug 2001 10:57:15 -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 KAA00607 for ; Tue, 21 Aug 2001 10:57:18 -0700 (PDT) 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 LAA01709 for ; Tue, 21 Aug 2001 11:57:34 -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 f7LHvKi01009 for ; Tue, 21 Aug 2001 12:57:20 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 21 Aug 2001 12:57:15 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 21 Aug 2001 12:57:14 -0500 content-class: urn:content-classes:message Subject: RE: [mobile-ip] Improvement in Proxy DAD functionality for Mobility Support in IPv6 Date: Tue, 21 Aug 2001 12:57:14 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF441E8449@daebe007.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Thread-Topic: [mobile-ip] Improvement in Proxy DAD functionality for Mobility Support in IPv6 Thread-Index: AcEqZa0AKFOo5pZXEdWrxAAIx6S5QwABLwSQ From: "Patil Basavaraj (NET/Dallas)" To: X-OriginalArrivalTime: 21 Aug 2001 17:57:15.0176 (UTC) FILETIME=[B604EA80:01C12A6A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f7LHvFm15363 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit > > when the binding chache entry expires, you send a binding > request for the mobile node. if the mobile node does not > respond you delete the binding cache entry and the proxy > neighbor cache entry. you do not delete the security > association the home agent shares with the mobile node. > after deleting the proxy neighbor cache entry the home > agent does not intercept packet, does not send out > neighbor advertisements on behalf of the mobile node. > this is the default behavior. > > Vijay > Thanks for the clarification Vijay. It does make sense to leave the SA associated with the MN intact even if the binding cache is cleared. -BP From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 21 14:03:31 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25807 for ; Tue, 21 Aug 2001 14:03: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 MAA24515; Tue, 21 Aug 2001 12:04: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 LAA21788; Tue, 21 Aug 2001 11:03:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7LI1mE15456 for mobile-ip-dist; Tue, 21 Aug 2001 11:01:48 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LI1im15445 for ; Tue, 21 Aug 2001 11:01:44 -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 LAA20632 for ; Tue, 21 Aug 2001 11:01:46 -0700 (PDT) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA12801 for ; Tue, 21 Aug 2001 11:01:46 -0700 (PDT) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id LAA00084 for ; Tue, 21 Aug 2001 11:01:45 -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 LAA22018 for ; Tue, 21 Aug 2001 11:01:45 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r1.mot.com with ESMTP; Tue, 21 Aug 2001 13:01:44 -0500 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 61E752ECAC; Tue, 21 Aug 2001 20:00:54 +0200 (CEST) To: Erik Nordmark Cc: mobile-ip@sunroof.eng.sun.com, James Kempf Subject: Re: [mobile-ip] Mobile Routers support without optimization References: From: Alexandru Petrescu Date: 21 Aug 2001 20:01:42 +0200 In-Reply-To: Message-Id: Lines: 48 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: Erik Nordmark writes: > The key thing is that we need rules that the CN can use to do > authorization checks. Those rules better not be circumventable by > having any subset of HA, MR, and MNN conspire to fool the CN. Very nice wording. I have sent two constraints in a previous email, I need example cases to test them against, and this takes time. > Or stated differently, given that the CN doesn't trust anything but > the ability of the routing system to deliver packets, on a best > effort basis, to the destination IP address, how can the CN develop > any trust in a remote entity stating that it should receive packets > for a whole prefix? Wow, sounds like a real challenge. > I don't see how techniques like SUCV can help here - they inherently > bind a key to a single IP address and I don't even think it is > meaningful to bind a key to a prefix. One can deduce the longest prefix of two addresses from the two addresses. A prefix draft would keep that: deduce the longest key of the prefix from the keys of the two addresses. So that we can route acording to keys, not to prefixes :-) Alex > > > > Numero due: similarly to the requirement on MR's home address and > > MNN's home address, another can be put between MR's HA address, MR's > > Home Address and MNN's home address. This could solve the case you > > mention above. > > The CN would still need to trust untrustworthy entities. > > Erik > > > Note that in the example you give above, I presume that PAN visits > > train. In that case, CN will probe different HA's (train MR's and PAN > > MR's), thus my tests would work. > > > > I need to know, if we talk only PAN case, is it possible to impose > > such a restriction (MR's home address and MNN's home address fit on > > claimed prefix -1)? > > > > Alex > > From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 21 14:36:04 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27046 for ; Tue, 21 Aug 2001 14:36: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 MAA27302; Tue, 21 Aug 2001 12:36:45 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA00626; Tue, 21 Aug 2001 11:36:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7LIYiU16420 for mobile-ip-dist; Tue, 21 Aug 2001 11:34:44 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LIYcm16404 for ; Tue, 21 Aug 2001 11:34:38 -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 LAA12366 for ; Tue, 21 Aug 2001 11:34:39 -0700 (PDT) Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA24967 for ; Tue, 21 Aug 2001 12:34:34 -0600 (MDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate3.mot.com (motgate3 2.1) with ESMTP id LAA25124 for ; Tue, 21 Aug 2001 11:26:52 -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 LAA09034 for ; Tue, 21 Aug 2001 11:34:37 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r1.mot.com with ESMTP; Tue, 21 Aug 2001 13:34:36 -0500 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id C28612ECAC; Tue, 21 Aug 2001 20:33:45 +0200 (CEST) To: James Kempf Cc: mobile-ip@sunroof.eng.sun.com, Erik.Nordmark@eng.sun.com Subject: Re: [mobile-ip] Mobile Routers support without optimization References: <200108211728.KAA14736@heliopolis.eng.sun.com> From: Alexandru Petrescu Date: 21 Aug 2001 20:34:34 +0200 In-Reply-To: <200108211728.KAA14736@heliopolis.eng.sun.com> Message-Id: Lines: 25 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: James Kempf writes: > The issue is independent of whether the CN knows the subnet > relationship between MN, HA, and MR. I think that knowing the true MR's prefix by probing MR-HA-MNN does say a lot about what that MR can claim. Of course, "probing" will probably contain keying material. > The issue is whether the CN can authenticate that the MR is > authorized to route the prefix. In the above, you stress "route" or "prefix"? > It is impossible to verify this by an exchange between the CN, MR, > and HA without some kind of out-of-band exchange of security > material, or a trust relationship that taps into such an out-of-band > exchange. Indeed, my "probing" is your "out-of-band". I purposefully minimized it in order to avoid the tendency to put all solutions into the hands of magic crypto. There's also the functional. Alex From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 21 14:37:17 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27103 for ; Tue, 21 Aug 2001 14:37: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 LAA18912; Tue, 21 Aug 2001 11:37: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 LAA27397; Tue, 21 Aug 2001 11:23:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7LILBn16111 for mobile-ip-dist; Tue, 21 Aug 2001 11:21:11 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LIL4m16104 for ; Tue, 21 Aug 2001 11:21: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 LAA08414 for ; Tue, 21 Aug 2001 11:21:05 -0700 (PDT) Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA11546 for ; Tue, 21 Aug 2001 12:21:00 -0600 (MDT) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate3.mot.com (motgate3 2.1) with ESMTP id LAA18687 for ; Tue, 21 Aug 2001 11:12:40 -0700 (MST)] Received: [from m-il06-r1.mot.com (m-il06-r1.mot.com [129.188.137.193]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id LAA23502 for ; Tue, 21 Aug 2001 11:20:25 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r1.mot.com with ESMTP; Tue, 21 Aug 2001 13:20:24 -0500 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 264742ECAC; Tue, 21 Aug 2001 20:19:34 +0200 (CEST) To: Michael Thomas Cc: mobile-ip@sunroof.eng.sun.com, Erik.Nordmark@eng.sun.com, James.Kempf@Sun.COM Subject: Re: [mobile-ip] Mobile Routers support without optimization References: <200108211604.JAA10300@heliopolis.eng.sun.com> <15234.40790.768468.610613@thomasm-u1.cisco.com> From: Alexandru Petrescu Date: 21 Aug 2001 20:20:22 +0200 In-Reply-To: <15234.40790.768468.610613@thomasm-u1.cisco.com> Message-Id: Lines: 14 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: Michael Thomas writes: > I believe that the only nodes which can make a > determination as to whether the mobile router is > authorized to advertize that prefix to the CN > are the routers in the path between MN and CN by > way of HA. I think there are cases where the CN can itself look at what's claimed, send probes and decide what it can trust. See my constraints on HA, MR and MNN home addresses. Please discard it I need to get rid of it. Alex From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 21 14:42:09 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27276 for ; Tue, 21 Aug 2001 14:42:09 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA02579; Tue, 21 Aug 2001 12:42: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 LAA02110; Tue, 21 Aug 2001 11:42:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7LIeVS16589 for mobile-ip-dist; Tue, 21 Aug 2001 11:40:31 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LIeRm16577 for ; Tue, 21 Aug 2001 11:40: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 LAA06270; Tue, 21 Aug 2001 11:40:28 -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 MAA28384; Tue, 21 Aug 2001 12:40:46 -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 f7LIeTQ21595; Tue, 21 Aug 2001 11:40:29 -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 ACY10163; Tue, 21 Aug 2001 11:40:25 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA19529; Tue, 21 Aug 2001 11:40:25 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15234.43801.192962.948227@thomasm-u1.cisco.com> Date: Tue, 21 Aug 2001 11:40:25 -0700 (PDT) To: Alexandru Petrescu Cc: Michael Thomas , mobile-ip@sunroof.eng.sun.com, Erik.Nordmark@eng.sun.com, James.Kempf@Sun.COM Subject: Re: [mobile-ip] Mobile Routers support without optimization In-Reply-To: References: <200108211604.JAA10300@heliopolis.eng.sun.com> <15234.40790.768468.610613@thomasm-u1.cisco.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Alexandru Petrescu writes: > Michael Thomas writes: > > I believe that the only nodes which can make a > > determination as to whether the mobile router is > > authorized to advertize that prefix to the CN > > are the routers in the path between MN and CN by > > way of HA. > > I think there are cases where the CN can itself > look at what's claimed, send probes and decide > what it can trust. See my constraints on HA, MR > and MNN home addresses. Please discard it I > need to get rid of it. Send probes to _what_? I'm afraid that you're going to be a lot more specific because the trust models along with the knowledge and incentives of various hosts/routers are vary widely. Mike From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 21 14:42:11 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27289 for ; Tue, 21 Aug 2001 14:42: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 MAA02652; Tue, 21 Aug 2001 12:42:49 -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 LAA02126; Tue, 21 Aug 2001 11:42:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7LIen516602 for mobile-ip-dist; Tue, 21 Aug 2001 11:40:49 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LIeem16595 for ; Tue, 21 Aug 2001 11:40:41 -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 LAA18251; Tue, 21 Aug 2001 11:40:33 -0700 (PDT) Message-Id: <200108211840.LAA18251@heliopolis.eng.sun.com> Date: Tue, 21 Aug 2001 11:40:33 -0700 (PDT) From: James Kempf Subject: Re: [mobile-ip] Mobile Routers support without optimization To: James.Kempf@Sun.COM, petrescu@crm.mot.com Cc: mobile-ip@sunroof.eng.sun.com, Erik.Nordmark@eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: CLA25ZLyEfZOIUEo9s0oVA== 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: > >> The issue is whether the CN can authenticate that the MR is >> authorized to route the prefix. > >In the above, you stress "route" or "prefix"? > One issue is whether the CN is allowed to route at all, the other is whether it is allowed to route the prefix. Answering the second answers the first, and the second question is the one that is of relevance here. jak From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 21 14:45:42 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27504 for ; Tue, 21 Aug 2001 14:45: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 MAA05001; Tue, 21 Aug 2001 12:45: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 LAA02772; Tue, 21 Aug 2001 11:44:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7LIhcB16685 for mobile-ip-dist; Tue, 21 Aug 2001 11:43:38 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LIhYm16665 for ; Tue, 21 Aug 2001 11:43:34 -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 LAA02447; Tue, 21 Aug 2001 11:43:34 -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 LAA17746; Tue, 21 Aug 2001 11:43:33 -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 f7LIhoT28307; Tue, 21 Aug 2001 11:43: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 ACY10307; Tue, 21 Aug 2001 11:43:32 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA19532; Tue, 21 Aug 2001 11:43:31 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15234.43987.779957.663693@thomasm-u1.cisco.com> Date: Tue, 21 Aug 2001 11:43:31 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Cc: James Kempf , Erik.Nordmark@eng.sun.com Subject: Re: [mobile-ip] Mobile Routers support without optimization In-Reply-To: References: <200108211728.KAA14736@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 Alexandru Petrescu writes: > James Kempf writes: > > The issue is independent of whether the CN knows the subnet > > relationship between MN, HA, and MR. > > I think that knowing the true MR's prefix by probing MR-HA-MNN does > say a lot about what that MR can claim. Of course, "probing" will > probably contain keying material. The problem is that HA may not a) be trustworthy or b) authoratative. Assuming this knowledge is readily available anywhere (which I'm not sure), it needs to be from a trustworthy and authoratative source. Mike From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 21 14: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 ESMTP id OAA27811 for ; Tue, 21 Aug 2001 14:52: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 LAA27350; Tue, 21 Aug 2001 11:53:20 -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 LAA04657; Tue, 21 Aug 2001 11:51:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7LInLV16876 for mobile-ip-dist; Tue, 21 Aug 2001 11:49:21 -0700 (PDT) Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LInIm16867 for ; Tue, 21 Aug 2001 11:49: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 OAA24743 for ; Tue, 21 Aug 2001 14:49:16 -0400 (EDT) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id OAA24383 for mobile-ip@sunroof.eng.sun.com; Tue, 21 Aug 2001 14:49:45 -0400 (EDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7L9SCm10554 for ; Tue, 21 Aug 2001 02:28:12 -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 CAA10742 for ; Tue, 21 Aug 2001 02:28:15 -0700 (PDT) Received: from mailer.wtmea.com ([62.140.66.90]) by venus.sun.com (8.9.3+Sun/8.9.3) with SMTP id CAA21981 for ; Tue, 21 Aug 2001 02:28:13 -0700 (PDT) Received: (qmail 9474 invoked from network); 21 Aug 2001 09:30:00 -0000 Received: from elmouftares.wtmea.com (HELO ieee.org) (62.140.66.105) by wthome.wtmea.com with SMTP; 21 Aug 2001 09:30:00 -0000 Message-ID: <3B82290A.3D1A6D18@ieee.org> Date: Tue, 21 Aug 2001 12:25:30 +0300 From: Khaled Elsayed X-Mailer: Mozilla 4.77 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: khaled@ieee.org, michah@ieee.org Subject: [mobile-ip] CFP: IEEE Communications Magazine - Internet Techology Series 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 Appologies if you receive multiple copies. HTML version of this CFP can be found at http://inetserie.tripod.com/cfp.html Call for Papers IEEE Communications Magazine Internet Technology Series Series Editors Michah Lerner (AT&T) and Khaled Elsayed (Cairo University) IP in 2005 Scalability, Programmability, and Virtualization in the Internet The scalable Internet presents challenges and paradoxes. Scalable and malleable services leverage stateless distributed control over the global address space. Transport bindings nevertheless influence service behavior through the control of access, the logical flow of information, as well as the availability of diverse content. Such systems challenge the traditional traffic engineering methods for allocation of buffers and assignment of resources. The Internet Technology series of the IEEE Communications Magazine is calling for original tutorial papers about these challenges and their resolution, and suggest the following topics: - Scalability issues in BGP and routing tables - Clouds (native IP) vs. strings (MPLS) - Internet evolution choices - Programmable routers - architectures and services - Instantiation and Virtualization – IP services provide concrete capabilities through the structuring of resources. - Virtualization of the transport service layers - such as pervasive virtual private networks - Internet services - multilevel and location-aware mobile services, including voice over IP (VoIP) IEEE Communications Magazine is read by tens of thousands of Communications Society members. The papers will be available on the Internet through Communications Magazine Interactive, the WWW edition of the magazine. Details about IEEE Communications Magazine can be found at http://www.comsoc.org/ci/. Sample publications published within the Internet Technology Series can be found in the January 2001 and July 2001 issues of the IEEE Communicarions Magazine. Tentative Schedule Manuscripts due: Nov 1, 2001 Notification of acceptance: Jan 15, 2002 (for the April 2002 issue) Final copy due: One month before final publication date Prospective Magazine issues: April, August, and Oct. 2002 How to Submit Manuscripts Article Style Information ========================= Articles should be tutorial in nature and should be written in a style comprehensible to readers outside the specialty of the article. Articles may be edited for content, and will be copyedited for compliance with the magazine's style guidelines. Page proofs will be sent to the contact author for final review prior to publication. Mathematical equations should not be used unless they are vital to the presentation. Even then, they should be kept to a minimum. If the article has numerous equations, please contact the editor handling the manuscript. References should be included only to guide readers to more information on the topic; the reference list should not include every available source (a limit of ten references is recommended). Use footnotes only where necessary. Articles should not exceed 4500 words. Figures and tables should be limited to a combined total of six. If the article exceeds these recommended limits, please contact the editor handling the manuscript. Submission ========================= Electronic submission of manuscripts as either PDF (preferred) or Postscript is required. Please send your submission to both of the series editors: Khaled Elsayed: khaled@ieee.org Michah Lerner: michah@ieee.org From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 21 14:53:08 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27832 for ; Tue, 21 Aug 2001 14:53: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 LAA27523; Tue, 21 Aug 2001 11:53: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 LAA04650; Tue, 21 Aug 2001 11:51:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7LInFu16863 for mobile-ip-dist; Tue, 21 Aug 2001 11:49:15 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LInAm16856 for ; Tue, 21 Aug 2001 11:49: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 LAA15952 for ; Tue, 21 Aug 2001 11:48:56 -0700 (PDT) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA08488 for ; Tue, 21 Aug 2001 12:48:52 -0600 (MDT) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id LAA05862 for ; Tue, 21 Aug 2001 11:48:55 -0700 (MST)] Received: [from m-il06-r3.mot.com (m-il06-r3.mot.com [129.188.137.194]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id LAA24051 for ; Tue, 21 Aug 2001 11:48:55 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r3.mot.com with ESMTP; Tue, 21 Aug 2001 13:48:46 -0500 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 1709C2ECAC; Tue, 21 Aug 2001 20:48:03 +0200 (CEST) To: Michael Thomas Cc: mobile-ip@sunroof.eng.sun.com, Erik.Nordmark@eng.sun.com, James.Kempf@Sun.COM Subject: Re: [mobile-ip] Mobile Routers support without optimization References: <200108211604.JAA10300@heliopolis.eng.sun.com> <15234.40790.768468.610613@thomasm-u1.cisco.com> <15234.43801.192962.948227@thomasm-u1.cisco.com> From: Alexandru Petrescu Date: 21 Aug 2001 20:48:51 +0200 In-Reply-To: <15234.43801.192962.948227@thomasm-u1.cisco.com> 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: Michael Thomas writes: > > I think there are cases where the CN can itself > > look at what's claimed, send probes and decide > > what it can trust. See my constraints on HA, MR > > and MNN home addresses. Please discard it I > > need to get rid of it. > > Send probes to _what_? I'm afraid that you're > going to be a lot more specific because the > trust models along with the knowledge and > incentives of various hosts/routers are vary > widely. Sorry, it was "send probes to home subnet". But it looks like you guys have taken on a much bigger endeavour, I will step aside. Alex From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 21 14:57:50 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27899 for ; Tue, 21 Aug 2001 14:57: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 LAA00054; Tue, 21 Aug 2001 11:58: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 LAA06156; Tue, 21 Aug 2001 11:55:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7LIs9117086 for mobile-ip-dist; Tue, 21 Aug 2001 11:54:09 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LIs5m17070 for ; Tue, 21 Aug 2001 11:54: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 LAA02370; Tue, 21 Aug 2001 11:54:06 -0700 (PDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA13399; Tue, 21 Aug 2001 12:54:01 -0600 (MDT) 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 f7LIqDh10193; Tue, 21 Aug 2001 11:52:13 -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 ACY10690; Tue, 21 Aug 2001 11:54:02 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA19535; Tue, 21 Aug 2001 11:54:01 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15234.44617.546341.967898@thomasm-u1.cisco.com> Date: Tue, 21 Aug 2001 11:54:01 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Cc: Alexandru Petrescu , Erik.Nordmark@eng.sun.com, James Kempf Subject: Re: [mobile-ip] Mobile Routers support without optimization 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 Erik Nordmark writes: > A provider might assign > 10.1.0.0/16 to user A > 10.2.0.0/16 to user B > 10.3.0.0/16 to user A > > This creates "holes" thus in your proposal this can be used by A to claim > the space assigned to B. What this says is that the router(s) which summarizes this route (say 10.0.0.0/14) is the one that knows that A claiming 10.0.0.0/15 (or less) is bogus. Yes? Mike From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 21 14:57:55 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27911 for ; Tue, 21 Aug 2001 14:57: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 LAA29967; Tue, 21 Aug 2001 11:58: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 LAA05537; Tue, 21 Aug 2001 11:53:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7LIqS116987 for mobile-ip-dist; Tue, 21 Aug 2001 11:52:28 -0700 (PDT) Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LIqPm16976 for ; Tue, 21 Aug 2001 11:52:25 -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 OAA01894 for ; Tue, 21 Aug 2001 14:52:26 -0400 (EDT) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id OAA24438 for mobile-ip@sunroof.eng.sun.com; Tue, 21 Aug 2001 14:52:54 -0400 (EDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7KHPDL05396 for ; Mon, 20 Aug 2001 10:25: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 KAA27387 for ; Mon, 20 Aug 2001 10:25:15 -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 KAA19296 for ; Mon, 20 Aug 2001 10:25:15 -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 f7KHOYQ20460; Mon, 20 Aug 2001 10:24:35 -0700 (PDT) Received: from RBELL-W2K.cisco.com (dhcp-128-107-163-78.cisco.com [128.107.163.78]) by mira-sjcm-3.cisco.com (Mirapoint) with ESMTP id AAH23090; Mon, 20 Aug 2001 10:24:28 -0700 (PDT) Message-Id: <4.3.2.7.2.20010820101209.01da7e10@mira-sjcm-3.cisco.com> X-Sender: rbell@mira-sjcm-3.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 20 Aug 2001 10:22:40 -0700 To: mobile-ip@sunroof.eng.sun.com From: Read Bell Subject: [mobile-ip] Re: Basavaraj.Patil@nokia.com: RE: mobile-ip] Re: mobile-ip] RFC2002bis] Cc: "Madhavi W. Chandra" , "Charles E. Perkins" , Pat Calhoun , "Kent K. Leung" , gdommety@cisco.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: Hello, I want to add my concerns about mandating the use of HMAC-MD5 to RFC2002bis. I don't think the use of SHOULD for MD5 usage is strong enough. Please take a look at this from the customers' perspective. There are currently several large networks with almost 2 million subscribers using Mobile IP with MD5 as specified in RFC2002. The fact that RFC2002 has been on the standards track for almost 5 years has resulted in production implementations requiring Mobile IP functionality based on non-standard specifications. While I understand the desire to make the final specification for Mobile IP as complete and robust as possible, the existence of a large deployment of RFC2002 based systems requires inter-operability with RFC2002. Please consider making MD5 a MUST in the spec. Thanks, --Read From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 21 15: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 ESMTP id PAA28121 for ; Tue, 21 Aug 2001 15:01: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 NAA19870; Tue, 21 Aug 2001 13:01:15 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA07543; Tue, 21 Aug 2001 12:00:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7LIx2v17305 for mobile-ip-dist; Tue, 21 Aug 2001 11:59:02 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LIwvm17289 for ; Tue, 21 Aug 2001 11:58: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 LAA18460 for ; Tue, 21 Aug 2001 11:58:55 -0700 (PDT) Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA08159 for ; Tue, 21 Aug 2001 12:59:12 -0600 (MDT) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate3.mot.com (motgate3 2.1) with ESMTP id LAA06630 for ; Tue, 21 Aug 2001 11:51:07 -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 LAA00875 for ; Tue, 21 Aug 2001 11:58:52 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r1.mot.com with ESMTP; Tue, 21 Aug 2001 13:58:51 -0500 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id F262A2ECAC; Tue, 21 Aug 2001 20:58:00 +0200 (CEST) To: mobile-ip@sunroof.eng.sun.com Cc: James Kempf , Erik.Nordmark@eng.sun.com Subject: Re: [mobile-ip] Mobile Routers support without optimization References: <200108211728.KAA14736@heliopolis.eng.sun.com> <15234.43987.779957.663693@thomasm-u1.cisco.com> From: Alexandru Petrescu Date: 21 Aug 2001 20:58:49 +0200 In-Reply-To: <15234.43987.779957.663693@thomasm-u1.cisco.com> Message-Id: Lines: 28 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: Michael Thomas writes: > Alexandru Petrescu writes: > > James Kempf writes: > > > The issue is independent of whether the CN knows the subnet > > > relationship between MN, HA, and MR. > > > > I think that knowing the true MR's prefix by probing MR-HA-MNN does > > say a lot about what that MR can claim. Of course, "probing" will > > probably contain keying material. > > The problem is that HA may not a) be trustworthy or > b) authoratative. Assuming this knowledge is readily > available anywhere (which I'm not sure), it needs to > be from a trustworthy and authoratative source. I was not saying neither that a) HA is trustworthy nor that b) authoritative. I was saying that packets get routed to HA, as HA claims they are. You can try to route packets to non-existing HA's and forge replies from somewhere else, and _this_ can be solved by putting keying material in the probes. Or you question that today's network routability can not be trusted? Alex From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 21 15:04:03 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28240 for ; Tue, 21 Aug 2001 15:04:02 -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 NAA22860; Tue, 21 Aug 2001 13:04: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 MAA08367; Tue, 21 Aug 2001 12:04:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7LJ2R217431 for mobile-ip-dist; Tue, 21 Aug 2001 12:02:28 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LJ2Nm17420 for ; Tue, 21 Aug 2001 12:02: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 MAA04158 for ; Tue, 21 Aug 2001 12:02:15 -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 NAA10430 for ; Tue, 21 Aug 2001 13:02:31 -0600 (MDT) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate.mot.com (motgate 2.1) with ESMTP id MAA25466 for ; Tue, 21 Aug 2001 12:02:12 -0700 (MST)] Received: [from m-il06-r4.mot.com (m-il06-r4.mot.com [129.188.137.196]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id MAA04036 for ; Tue, 21 Aug 2001 12:02:12 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r4.mot.com with ESMTP; Tue, 21 Aug 2001 14:02:11 -0500 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 668002ECF8; Tue, 21 Aug 2001 21:01:21 +0200 (CEST) To: Michael Thomas Cc: mobile-ip@sunroof.eng.sun.com, Erik.Nordmark@eng.sun.com, James Kempf Subject: Re: [mobile-ip] Mobile Routers support without optimization References: <15234.44617.546341.967898@thomasm-u1.cisco.com> From: Alexandru Petrescu Date: 21 Aug 2001 21:02:09 +0200 In-Reply-To: <15234.44617.546341.967898@thomasm-u1.cisco.com> Message-Id: Lines: 20 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: Michael Thomas writes: > Erik Nordmark writes: > > A provider might assign > > 10.1.0.0/16 to user A > > 10.2.0.0/16 to user B > > 10.3.0.0/16 to user A > > > > This creates "holes" thus in your proposal this can be used by A to claim > > the space assigned to B. > > What this says is that the router(s) which summarizes this > route (say 10.0.0.0/14) is the one that knows that A claiming > 10.0.0.0/15 (or less) is bogus. Also, the router that routes 10.1.0.0/16 and 10.3.0./16 to HA knows that it doesn't route 10.2.0.0/16 to HA. Thus it can do ingress filtering on replies from HA to CN probes. But probably ingress filtering should not be required. Alex From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 21 16:01:44 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29815 for ; Tue, 21 Aug 2001 16:01: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 OAA16406; Tue, 21 Aug 2001 14:02: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 NAA00517; Tue, 21 Aug 2001 13:01:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7LJvQ817861 for mobile-ip-dist; Tue, 21 Aug 2001 12:57:26 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LJvLm17854 for ; Tue, 21 Aug 2001 12:57: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 MAA29645 for ; Tue, 21 Aug 2001 12:57:23 -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 NAA11737 for ; Tue, 21 Aug 2001 13:57:18 -0600 (MDT) 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 f7LJvMQ18047 for ; Tue, 21 Aug 2001 12:57:22 -0700 (PDT) Received: (mchandra@localhost) by mchandra-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA16149 for mobile-ip@sunroof.eng.sun.com; Tue, 21 Aug 2001 15:56:57 -0400 (EDT) Date: Tue, 21 Aug 2001 15:56:57 -0400 From: "Madhavi W. Chandra" To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Re: mobile-ip] Mobile networking on v4? Message-ID: <20010821155656.A16141@cisco.com> References: <20010821120621.A25090@horus.imag.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010821120621.A25090@horus.imag.fr>; from wells@ee.vt.edu on Tue, Aug 21, 2001 at 12:06: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: Hi John, Are you referring to implementations of Mobile Networks/Routers for MIPv4? If so, Cisco has an implementation. Thanks, Madhavi On Tue, Aug 21, 2001 at 12:06:21PM -0400, John Wells wrote: > Hi all, > > Does anyone know of any v4 work on mobile networking? It would seem > that most if not all if not all of this work is concentrated on v6; if > v4 resources exist or don't, I'd like to know. > > Thanks, > John > > -- > John WELLS > Virginia Tech Networking and Visualization Lab > PGP Public key: http://www.ee.vt.edu/~wells/pgpkey.txt From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 21 16:01:54 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29833 for ; Tue, 21 Aug 2001 16:01: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 OAA16410; Tue, 21 Aug 2001 14:02: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 NAA00514; Tue, 21 Aug 2001 13:01:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7LJv8n17852 for mobile-ip-dist; Tue, 21 Aug 2001 12:57:08 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LJv3m17845 for ; Tue, 21 Aug 2001 12:57:04 -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 MAA29585 for ; Tue, 21 Aug 2001 12:57:05 -0700 (PDT) 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 MAA09813 for ; Tue, 21 Aug 2001 12:57:04 -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 f7LJv9i15179 for ; Tue, 21 Aug 2001 14:57:09 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 21 Aug 2001 14:57:04 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 21 Aug 2001 14:57:04 -0500 content-class: urn:content-classes:message Subject: RE: [mobile-ip] Mobile Routers support without optimization Date: Tue, 21 Aug 2001 14:57:04 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF441E844F@daebe007.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Thread-Topic: [mobile-ip] Mobile Routers support without optimization Thread-Index: AcEqdAe+ytiZbJZlEdWpVgBQi2kYTQABun+w From: "Patil Basavaraj (NET/Dallas)" To: X-OriginalArrivalTime: 21 Aug 2001 19:57:04.0254 (UTC) FILETIME=[730B29E0:01C12A7B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f7LJv5m17846 Sender: owner-mobile-ip@sunroof.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, Just want to remind everyone that while the topic of Mobile routers is interesting, there are other more pressing WG items that need to be resolved and completed before we can take on this subject and develop any solutions. So while the mailing list is buzzing with activity, there is no real progress being made in terms of what the WG is chartered to do and accomplish in the near term. -Basavaraj From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 21 16:40:22 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00733 for ; Tue, 21 Aug 2001 16:40: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 OAA19798; Tue, 21 Aug 2001 14:41:01 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA08692; Tue, 21 Aug 2001 13:39:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7LKc1j18246 for mobile-ip-dist; Tue, 21 Aug 2001 13:38:01 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LKbwm18239 for ; Tue, 21 Aug 2001 13:37: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 NAA00861; Tue, 21 Aug 2001 13:38:00 -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 OAA17192; Tue, 21 Aug 2001 14:37: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 f7LKcFT16223; Tue, 21 Aug 2001 13:38: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 ACY13583; Tue, 21 Aug 2001 13:37:57 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA19552; Tue, 21 Aug 2001 13:37:57 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15234.50853.496915.391551@thomasm-u1.cisco.com> Date: Tue, 21 Aug 2001 13:37:57 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Cc: petrescu@crm.mot.com, Erik.Nordmark@eng.sun.com, James.Kempf@Sun.COM Subject: Re: [mobile-ip] Mobile Routers support without optimization In-Reply-To: <200108211609.JAA10505@heliopolis.eng.sun.com> References: <200108211609.JAA10505@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 then becomes whether the HA can be trusted. Now, suppose > the protocol requires that the HA be authenticable via a chain > of trust through the routing update authentication mechanism > used to authenticate OSPF and BGP routes? The short answer is that the HA cannot be trusted as a blanket statement. The routers which may be able to produce a trustworthy answer about a particular prefix may have no involvement with mobility at present. Mike From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 21 18:16:24 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02619 for ; Tue, 21 Aug 2001 18:16:24 -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 PAA02074; Tue, 21 Aug 2001 15:15: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 PAA24290; Tue, 21 Aug 2001 15:15:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7LMED018538 for mobile-ip-dist; Tue, 21 Aug 2001 15:14:13 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LMEAm18531 for ; Tue, 21 Aug 2001 15:14: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 PAA00839; Tue, 21 Aug 2001 15:14:12 -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 PAA08663; Tue, 21 Aug 2001 15:14:10 -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 f7LMEMT26223; Tue, 21 Aug 2001 15:14: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 ACY16791; Tue, 21 Aug 2001 15:14:04 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA19566; Tue, 21 Aug 2001 15:14:04 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15234.56620.266061.947619@thomasm-u1.cisco.com> Date: Tue, 21 Aug 2001 15:14:04 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Cc: mat@cisco.com, James.Kempf@sun.com, Erik.Nordmark@eng.sun.com Subject: Re: [mobile-ip] Mobile Routers support without optimization In-Reply-To: <200108202011.NAA02394@heliopolis.eng.sun.com> References: <200108202011.NAA02394@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: > >Indeed, it's not entirely clear that the CN is > >really the one that should be the target of the > >BU. > > > > I guess what I'd question is why the CN's border router > is any more authoritative than the HA. As I've mentioned in earlier mail, it's not necessarily in the CN's AS (I've had a bit more time to think about this since I wrote the previous note). It is a router which has a stake in enforcing sanity on its subnet delegations. I'm thinking that it is either router who summarizes the subnet at an administrative domain or a top level BGP route. > Here's what I think might be an answer. BGP updates are > authenticated, so the CN's border router can trust > the routing table updates it receives from the HA's > AS. Not quite. The authentication just keeps outsiders out. If you're part of the BGP club though, anything is possible; if I want to advertise something ridiculous, nothing prevents me from doing that (that I know of). Same thing with RIP/OSPF/IS-IS... [disclaimer: BGP may have more safeguards than this, but the real point is that if you're part of the BGP club, you can do significant damage to the routing system which is ultimately only enforceable by other BGP's refusing to peer with you. If somebody knows otherwise, I'm all ears about how this is done.] > The only issue is that if the BGP routes are aggregated, > the MR's prefix won't show up in the CN AS routing > tables, though some superprefix will. If as per my > followup message to Erik, one constrains the MR subnet > prefix to be a subprefix of the HA 's prefix, and the HA prefix > to be a subprefix of a prefix in the BGP routing tables, > then would that be enough to let the CN validate? I believe that we can delink this problem from the particular routing protocols; indeed, if there were a solution it ought to work equally well with static routes. I think that the important property is that is the router which summarizes the prefix on the trusted side of the delegation boundary. > Basically, I don't see any way around requiring some > out-of-band exchange of security material if we want > to verify that the MR and HA are allowed to route > a particular prefix. Right. See my straw proposal I sent this morning. Mike From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 22 02:30:23 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26305 for ; Wed, 22 Aug 2001 02:30: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 AAA16560; Wed, 22 Aug 2001 00:31: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 XAA00601; Tue, 21 Aug 2001 23:30:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7M6TdY19259 for mobile-ip-dist; Tue, 21 Aug 2001 23:29:39 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7M6TZm19252 for ; Tue, 21 Aug 2001 23:29:35 -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 XAA20723 for ; Tue, 21 Aug 2001 23:29:39 -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 XAA21881 for ; Tue, 21 Aug 2001 23:29:38 -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 f7M6Tav29475 for ; Wed, 22 Aug 2001 08:29:36 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Wed Aug 22 08:29:32 2001 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 22 Aug 2001 08:22:55 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008C09@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] IPsec, IKE, MIPv6 and concensus Date: Tue, 21 Aug 2001 13:35: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: > Hesham wrote: > > > > > Of course both A and B rely on eliminating piggybacking > > > > of the BUs. > > > > > > > > > > => Yeh! > > > > > > > > > > > This is not true at all. There is always the case when > > there is no IPsec SA > > > required for the payload itself and there would be > > absolutely no harm done > > > by piggybacking. Only when the payload and the BU need > > different SAs could > > > piggybacking not be done. > > > > > => Yes but you can't design a standard that only works > > sometimes. > > > > The scenario is: > > - Need to send a BU to a CN > - If there is an outgoing packet to the CN in a queue, and > - the packet is not associated with any SA > - then can piggyback the BU with the packet in the queue > - else send BU as a separate packet > > If the spec allowed for this, would it be broken in some way? > > Sure this is a performance optimization only, and the degree of the benefit > depends heavily on the type of L2's in both ends, feature interaction with > HC, etc., but if done right there is nothing that would make the standard > "only work sometimes". It is quite customary that standards have options > that are not always used. > => The question is whether this complexity you mention above (L2 interaction, HC implications, Path MTU ....etc) are worth the hassles. There is no foreseen benefit really if you're using ROHC for example. Do you think the perceived gain actually outweighs the processing headache ? If it does then what you're suggesting would make a lot of sense. Hesham From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 22 03:03:16 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26755 for ; Wed, 22 Aug 2001 03:03: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 AAA01147; Wed, 22 Aug 2001 00:04: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 AAA02817; Wed, 22 Aug 2001 00:03:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7M72lQ19362 for mobile-ip-dist; Wed, 22 Aug 2001 00:02:47 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7M72im19355 for ; Wed, 22 Aug 2001 00:02: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 AAA02764; Wed, 22 Aug 2001 00:02:45 -0700 (PDT) Received: from iproxy1.ericsson.dk (iproxy1.ericsson.dk [130.228.248.98]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA28268; Wed, 22 Aug 2001 01:02:40 -0600 (MDT) Received: from unixmail.ted.dk.eu.ericsson.se (knud.ted.dk.eu.ericsson.se [192.66.4.246]) by iproxy1.ericsson.dk (8.10.1/8.10.1) with ESMTP id f7M72gc10802; Wed, 22 Aug 2001 09:02:42 +0200 (MET DST) Received: from ted.ericsson.dk (petg.ted.dk.eu.ericsson.se [192.66.4.85]) by unixmail.ted.dk.eu.ericsson.se (8.10.1/8.10.1/TEDmain-1.0) with ESMTP id f7M72bL28393; Wed, 22 Aug 2001 09:02:37 +0200 (MEST) Message-ID: <3B83590D.F8E31AAC@ted.ericsson.dk> Date: Wed, 22 Aug 2001 09:02:37 +0200 From: Peter Grimstrup Organization: Ericsson Telebit A/S X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Erik Nordmark CC: Peter Grimstrup , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile IPv6 draft revision 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 Comments inline Erik Nordmark wrote: > > > I should like to see new header extension types defined in the same > > breathing as the requirement on ordering of all the extension headers. > > That said, if possible, I favour putting *all* MIPv6 data (incl. Home Address > > Option) into *one* new extension header type. > > Currently the Home Address option is sent from MNs to CNs and all CNs must > know how to interpret this in order for communication to work. > (The TCP connection should be identified using the address in the Home Address > option and not the IPv6 source address of the packet, etc). Agree. > > I think some (I don't know how many) of the shipping IPv6 implementations > do this. I don't know if a sufficiently large number of IPv6 implementations > of CNs will support this to make things interoperate with MIPv6 MNs. > > However, if the WG takes the path of putting the information currently in > the Home Address option into the new extension header as you propose, > then some new mechanisms need to be constructed to be able to detect > when a CN doesn't understand the new extension header. > (Note that this is not an issue for the CN not understanding the BU - ignoring > the BU just has the effect of not optimizing the routing.) Points taken, then this in some way boils down to deciding when to comply to (parts of) draft-xx and when to break (to clean-up etc.) I havn't been around in this bussiness long enough to judge, but recognize that maybe more serious questions are awaiting decisions. > > A possible way of handling this would be for the MN to notice when it > receives an ICMP parameter problem with code payload type unknown > that the CN might not support it. The the MN, instead of using the > new extension header to carry the home address, would need to tunnel > the packet through the HA (reverse tunnel). > > Of course, if the WG is interested in this level surgery it would also > make sense to seriously consider the proposal that Bill Sommerfeld made > not long ago of replacing the use of routing header and home address option > with just IP in IP encapsulation, perhaps with optimized encapsulation formats > when only one extra IP address is needed in the packet. > > Erik -- Peter Grimstrup Systems Developer Ericsson Telebit A/S tel: +45 89 38 52 75 Skanderborgvej 232 fax: +45 89 38 51 01 DK 8260 Viby J, Denmark e-mail: peter.grimstrup@ted.ericsson.dk From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 22 04:40:05 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27663 for ; Wed, 22 Aug 2001 04:40: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 BAA25902; Wed, 22 Aug 2001 01:40: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 BAA09783; Wed, 22 Aug 2001 01:40:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7M8cuR19592 for mobile-ip-dist; Wed, 22 Aug 2001 01:38:56 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7M8cqm19585 for ; Wed, 22 Aug 2001 01:38:52 -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 BAA22324 for ; Wed, 22 Aug 2001 01:38:54 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA29439 for ; Wed, 22 Aug 2001 02:39:13 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.5/8.11.5) with ESMTP id f7M8coL16682 for ; Wed, 22 Aug 2001 10:38:51 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id KAA25364 for ; Wed, 22 Aug 2001 10:38:51 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id f7M8col57023 for ; Wed, 22 Aug 2001 10:38:50 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200108220838.f7M8col57023@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile IPv6 draft revision In-reply-to: Your message of Tue, 21 Aug 2001 03:39:04 +0200. <034BEFD03799D411A59F00508BDF754603008BFB@esealnt448.al.sw.ericsson.se> Date: Wed, 22 Aug 2001 10:38:50 +0200 X-Virus-Scanned: by amavisd-milter (http://www.amavis.org/) at laposte.enst-bretagne.fr Sender: owner-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: > = Specify that the Binding Update needs a new header number => Should this one be kept for MIPv6 options as well ? Like the home adderss option for example. => there is a difference : BU needs a final header number, H@ needs an intermediate header number but: - at the winter IETF meeting, Steve Deering clearly stated this (new intermediate header number) should *not* be done - all IPv6 implementations must be changed in order to deal with a new intermediate header number BTW, what to do for BAs (which have an unclear security requirement, I believe the purpose in to protect BAs for home registration, not all BAs ???) and BR... Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 22 04:44:45 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27740 for ; Wed, 22 Aug 2001 04:44: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 CAA15286; Wed, 22 Aug 2001 02:45:31 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA11782; Wed, 22 Aug 2001 01:44:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7M8hul19675 for mobile-ip-dist; Wed, 22 Aug 2001 01:43:56 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7M8hqm19668 for ; Wed, 22 Aug 2001 01:43:52 -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 BAA08802 for ; Wed, 22 Aug 2001 01:43:55 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA14443 for ; Wed, 22 Aug 2001 02:43:50 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.5/8.11.5) with ESMTP id f7M8hqL16983 for ; Wed, 22 Aug 2001 10:43:52 +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 KAA25440 for ; Wed, 22 Aug 2001 10:43:52 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id f7M8hql57053 for ; Wed, 22 Aug 2001 10:43:52 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200108220843.f7M8hql57053@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile IPv6 draft revision In-reply-to: Your message of Tue, 21 Aug 2001 03:55:53 +0200. <034BEFD03799D411A59F00508BDF754603008BFD@esealnt448.al.sw.ericsson.se> Date: Wed, 22 Aug 2001 10:43:52 +0200 X-Virus-Scanned: by amavisd-milter (http://www.amavis.org/) at laposte.enst-bretagne.fr Sender: owner-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: > > > = Specify that the Binding Update needs a new header number > > > > > => Should this one be kept for MIPv6 options as well ? > > Like the home adderss option for example. > > The home address option does not have to be authenticated. > => I undersand but it would make sense to avoid having another header if we alow the authentication data in the BU option. This is the hypothetical scenario: The BU carries its own authentication data. In this case the Home address option need not be in the DST-1 header. So it can be placed in the same "new" ext header. Provided that there was nothing else in a DST header we've saved the overhead of one ext header. => I disagree because this optimization will make BU packets special, i.e. all other MN->CN packets will carry a visible H@ in a DST header. If the MN->CN traffic is protected by IPsec this will be a mess. > I reckon that the Binding Acknowledgement would need to have > a new header number also -- or else if there is a need to conserve > those numbers it could have the same header number as the > Binding Update. > => Definitely use the same ext header. There is no reason for a separate one as far as I can see. => of course! But for Binding Requests? Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 22 04:52:46 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27902 for ; Wed, 22 Aug 2001 04:52:45 -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 BAA29941; Wed, 22 Aug 2001 01:53:32 -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 BAA13525; Wed, 22 Aug 2001 01:53:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7M8qFH19799 for mobile-ip-dist; Wed, 22 Aug 2001 01:52:15 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7M8qCm19792 for ; Wed, 22 Aug 2001 01:52:12 -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 BAA24068 for ; Wed, 22 Aug 2001 01:52:14 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA18580 for ; Wed, 22 Aug 2001 02:52:09 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.5/8.11.5) with ESMTP id f7M8qAL17556 for ; Wed, 22 Aug 2001 10:52:11 +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 KAA25551 for ; Wed, 22 Aug 2001 10:52:11 +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 f7M8qAl57132 for ; Wed, 22 Aug 2001 10:52:10 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200108220852.f7M8qAl57132@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile IPv6 draft revision In-reply-to: Your message of Tue, 21 Aug 2001 08:59:47 +0200. <3B8206E3.CDDA87F2@ted.ericsson.dk> Date: Wed, 22 Aug 2001 10:52:10 +0200 X-Virus-Scanned: by amavisd-milter (http://www.amavis.org/) at laposte.enst-bretagne.fr Sender: owner-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: A few comments mainly from an implementation point of view: In draft-13, the MIPv6 protocol data was put into up to *2* Destination Option Headers. These headers had to be placed correctly in between the other ext-headers (before/after AH). Another (not yet defined) dest-opt header could be in the packet. That wasn't very clean. I should like to see new header extension types defined in the same breathing as the requirement on ordering of all the extension headers. That said, if possible, I favour putting *all* MIPv6 data (incl. Home Address Option) into *one* new extension header type. => STOP!!! This issue was solved at the IETF winter meeting: - you can put destination option headers where you'd like - NO new intermediate extention header should be defined - the advanced API should be updated in order to allow orders not in RFC 2460. Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 22 05:04:26 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28109 for ; Wed, 22 Aug 2001 05:04:26 -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 CAA03523; Wed, 22 Aug 2001 02:05: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 CAA14822; Wed, 22 Aug 2001 02:04:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7M93fC19894 for mobile-ip-dist; Wed, 22 Aug 2001 02:03:41 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7M93cm19887 for ; Wed, 22 Aug 2001 02:03:38 -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 CAA25425 for ; Wed, 22 Aug 2001 02:03:40 -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 CAA14429 for ; Wed, 22 Aug 2001 02:03:39 -0700 (PDT) Received: from inrialpes.fr (galibier.inrialpes.fr [194.199.24.97]) by ebene.inrialpes.fr (8.11.3/8.11.3) with ESMTP id f7M90Ji07314 for ; Wed, 22 Aug 2001 11:00:19 +0200 (MEST) Message-ID: <3B83750E.62401349@inrialpes.fr> Date: Wed, 22 Aug 2001 11:02:06 +0200 From: Thierry Ernst Organization: INRIA Rhone-Alpes X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile Routers support without optimization References: <200108211728.KAA14736@heliopolis.eng.sun.com> <15234.43987.779957.663693@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: > The problem is that HA may not a) be trustworthy or > b) authoratative. Assuming this knowledge is readily > available anywhere (which I'm not sure), it needs to > be from a trustworthy and authoratative source. If you claim that HA can not be trusted, then this applies equally well to mobile HOSTS, doesn't it ? As far as standard MIPv6 for mobile HOSTS is concerned, an implication of this statement is that solutions like BAKE and cie wouldn't give much help for the authorization of the MH to send a BU for its home address. Just trying to be consistent. Thierry From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 22 06:30:02 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28792 for ; Wed, 22 Aug 2001 06:30: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 DAA25626; Wed, 22 Aug 2001 03:30: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 DAA21034; Wed, 22 Aug 2001 03:30:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7MAT8G20076 for mobile-ip-dist; Wed, 22 Aug 2001 03:29:08 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7MAT4m20069 for ; Wed, 22 Aug 2001 03:29: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 DAA20384 for ; Wed, 22 Aug 2001 03:29:08 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA00756 for ; Wed, 22 Aug 2001 04:29:03 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.5/8.11.5) with ESMTP id f7MAT5L30856 for ; Wed, 22 Aug 2001 12:29:05 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id MAA27293 for ; Wed, 22 Aug 2001 12:29:05 +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 f7MAT5l58188 for ; Wed, 22 Aug 2001 12:29:05 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200108221029.f7MAT5l58188@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Improvement in Proxy DAD functionality for Mobility Support in IPv6 In-reply-to: Your message of Tue, 21 Aug 2001 09:25:00 PDT. <3B828B5C.33AD2040@iprg.nokia.com> Date: Wed, 22 Aug 2001 12:29:05 +0200 X-Virus-Scanned: by amavisd-milter (http://www.amavis.org/) at laposte.enst-bretagne.fr Sender: owner-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: > PS: the HA should flush the whole context too, including keys. This would be bad for mobile nodes that want to sleep but use the same security association when they wake up a few hours later. => are HA supposed to have infinite (2^64 * sizeof(context)) memory? BTW if keys have their own lifetime there is no issue (i.e. add this as a requirement for key management with all the little details like keys expire before the binding, etc). Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 22 07:01:57 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29450 for ; Wed, 22 Aug 2001 07:01: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 FAA15001; Wed, 22 Aug 2001 05:02: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 EAA22959; Wed, 22 Aug 2001 04:02:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7MB1GR20212 for mobile-ip-dist; Wed, 22 Aug 2001 04:01:16 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7MB1Cm20205 for ; Wed, 22 Aug 2001 04:01:12 -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 EAA02805 for ; Wed, 22 Aug 2001 04:01: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 FAA14042 for ; Wed, 22 Aug 2001 05:01:11 -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 GAA29068; Wed, 22 Aug 2001 06:59:56 -0400 (EDT) Message-Id: <200108221059.GAA29068@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-rfc2002-bis-07.txt Date: Wed, 22 Aug 2001 06:59:56 -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 : IP Mobility Support for IPv4, revised Author(s) : C. Perkins Filename : draft-ietf-mobileip-rfc2002-bis-07.txt Pages : 95 Date : 21-Aug-01 This document specifies protocol enhancements that allow transparent routing of IP datagrams to mobile nodes in the Internet. 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 its current point of attachment to the Internet. The protocol provides for registering the care-of address with a home agent. The home agent sends datagrams destined for the mobile node through a tunnel to the care-of address. After arriving at the end of the tunnel, each datagram is then delivered to the mobile node. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-rfc2002-bis-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-rfc2002-bis-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-rfc2002-bis-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: <20010821092208.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-rfc2002-bis-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-rfc2002-bis-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010821092208.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 22 07:28:47 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00037 for ; Wed, 22 Aug 2001 07:28: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 EAA09973; Wed, 22 Aug 2001 04:29: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 EAA25029; Wed, 22 Aug 2001 04:28:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7MBRmM20340 for mobile-ip-dist; Wed, 22 Aug 2001 04:27:48 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7MBRim20333 for ; Wed, 22 Aug 2001 04:27: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 EAA24935 for ; Wed, 22 Aug 2001 04:27:49 -0700 (PDT) From: fritsche@iabg.de Received: from iabgfw.iabg.de (iabgfw.iabg.de [194.139.245.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA27559 for ; Wed, 22 Aug 2001 05:27:44 -0600 (MDT) Received: by iabgfw.iabg.de; id NAA17995; Wed, 22 Aug 2001 13:27:46 +0200 (MET DST) Received: from unknown(10.255.255.2) by iabgfw.iabg.de via smap (V5.5) id xma017992; Wed, 22 Aug 01 13:27:28 +0200 Received: from iabgvw.iabg.de ([10.255.255.8]) by iabgmh.iabg.de (Post.Office MTA v3.5.1 release 219 ID# 127-59214U1600L300S0V35) with ESMTP id de for ; Wed, 22 Aug 2001 13:27:25 +0200 Received: from iabgdns.iabg.de (localhost [127.0.0.1]) by iabgvw.iabg.de (8.8.8+Sun/8.8.8) with ESMTP id NAA18376 for ; Wed, 22 Aug 2001 13:27:19 +0200 (MET DST) Received: from ziegenlippe (ziegenlippe.iabg.de [10.15.0.185]) by iabgdns.iabg.de (8.8.8+Sun/8.8.8) with SMTP id NAA27551 for ; Wed, 22 Aug 2001 13:27:27 +0200 (MET DST) Message-Id: <200108221127.NAA27551@iabgdns.iabg.de> Comments: Authenticated sender is To: mobile-ip@sunroof.eng.sun.com Date: Wed, 22 Aug 2001 13:27:26 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: RE: [mobile-ip] IPsec, IKE, MIPv6 and concensus In-reply-to: <009CA59D1752DD448E07F8EB2F911757197FDA@esebe004.NOE.Nokia.com> X-mailer: Pegasus Mail for Win32 (v2.54DE) Sender: owner-mobile-ip@sunroof.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 Jarno wrote: > Wolfgang wrote: > > > Jarno wrote: > > > The scenario is: > > > > > > - Need to send a BU to a CN > > > - If there is an outgoing packet to the CN in a queue, and > > > - the packet is not associated with any SA > > > - then can piggyback the BU with the packet in the queue > > > - else send BU as a separate packet > > > > But what will happen if at a later time it becomes necessary to have > > a SA also for the payload? IPSec will detect, that there is already > > one (with no idea, that it has been established for Mobile IP BUs), > > which probably will not match the security policy for the payload. So > > should the Mobile IP SA be overridden? How do you inform Mobile IP > > about that? > > > > The decision whether to piggyback or to send a separate packet must be done > separately for each signaling message sent by mobile IP, so I do not > understand what you mean with "at a later time". It's clear that a piggyback decision is done on a per-packet basis, but that's not what I addressed. My concern has been that sending BU piggybacked means that the SA to be established for this packet will address the security issues for the BU and the payload in the packet. As this SA will not be created just for one packet's lifetime, but last for a longer period, my comment has been that you may get into trouble if at a later time (when this SA is still valid) payload data has to be exchanged between MN and CN, which require the establishment of a different (from the security properties) SA. Will you then override the existing one, and if so will you also use the new one for future BUs, ... . As Erik already mentioned in an other email, this could easily become a source for interoperability problems. > What the actual implementation solution for resolving the possible race > condition between two SPD entries (one for Mobile IP, other for the payload) > is not important (for this discussion), and does not need to be > standardized. It suffices to state that (for example): > > "Mobile IP header (TBD) may be followed by transport headers only if the > transport protocol message can be sent with the Security Association used > for protecting Mobile IP itself." Concerning the use of a new extension header for MIP BUs I would be in favor with this approach if it provides the necessary granularity to differ between BUs and payload exchanged between MN and CN from a security perspective (using existing IPSec selectors). Reading the IPSec selectors chapter of the IPSec architecture (RFC 2401) I'm not quite sure about that, as it contains: " - Transport Layer Protocol: Obtained from the IPv4 "Protocol" or the IPv6 "Next Header" fields. This may be an individual protocol number. These packet fields may not contain the Transport Protocol due to the presence of IP extension headers, e.g., a Routing Header, AH, ESP, Fragmentation Header, Destination Options, Hop-by-hop options, etc. Note that the Transport Protocol may not be available in the case of receipt of a packet with an ESP header, thus a value of "OPAQUE" SHOULD be supported. [REQUIRED for all implementations] NOTE: To locate the transport protocol, a system has to chain through the packet headers checking the "Protocol" or "Next Header" field until it encounters either one it recognizes as a transport protocol, or until it reaches one that isn't on its list of extension headers, or until it encounters an ESP header that renders the transport protocol opaque. " You could interpret this in a way, that the granularity of the IPSec selectors concerning the "Next Header" fields is only used for transport layer protocols (e.g. TCP, UDP, ...) and not for other "Next Header" fields (Routing, Fragment, ..., or a possible new MIP BU). If this interpretation is correct, what benefits from the security perspective will bring an new "Next Header" field for the BU? Maybe some IPSec gurus could correct me. > If you do not want to find a solution how to do this, never piggyback. It is > a tradeoff with possible complexity of checking the SPD in the right places, > and getting the efficiency of piggybacking. But this tradeoff should have no > interoperability consequences, so there is no need for standardizing > anything new for this. > > > You won't have such problems without piggybacking. > > > > Again, this issue can be left to the implementers of to decide. No-one is > forced to piggyback. Reception of piggybacked transport PDU should happen > with current standards. > > Or am I still missing something? What adverse effects you see with > piggybacking, with the assumption that the originating host knows when it > can/not piggyback? > > Jarno > Wolfgang From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 22 08:52:27 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04327 for ; Wed, 22 Aug 2001 08:52: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 FAA09128; Wed, 22 Aug 2001 05:52: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 FAA12013; Wed, 22 Aug 2001 05:52:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7MCp7620458 for mobile-ip-dist; Wed, 22 Aug 2001 05:51:07 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7MCp3m20451 for ; Wed, 22 Aug 2001 05:51: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 FAA27735 for ; Wed, 22 Aug 2001 05:51:08 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA29187 for ; Wed, 22 Aug 2001 05:51:07 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.5/8.11.5) with ESMTP id f7MCp5L06373 for ; Wed, 22 Aug 2001 14:51:05 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id OAA28559 for ; Wed, 22 Aug 2001 14:51:05 +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 f7MCp4l58630 for ; Wed, 22 Aug 2001 14:51:04 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200108221251.f7MCp4l58630@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile IPv6 draft revision In-reply-to: Your message of Mon, 20 Aug 2001 13:38:56 PDT. <3B817560.FF84055B@iprg.nokia.com> Date: Wed, 22 Aug 2001 14:51:04 +0200 X-Virus-Scanned: by amavisd-milter (http://www.amavis.org/) at laposte.enst-bretagne.fr Sender: owner-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've discussed about this with Charlie but we need mailing list approval. My concern is about section 10.20 (returning Home). Context is: When sending this Binding Update to its home agent, the mobile node must be careful in how it uses Neighbor Solicitation [17] (if needed) to learn the home agent's link-layer address, since the home agent will be currently configured to defend the mobile node's home address for Duplicate Address Detection. In particular, a Neighbor Solicitation from the mobile node using its home address as the Source Address would be detected by the home agent as a duplicate address. In many cases, Neighbor Solicitation by the mobile node for the home agent's address will not be necessary, since the mobile node may have already learned the home agent's link-layer address, for example from a Source Link-Layer Address option in the Router Advertisement from which it learned that its home address was on-link and that the mobile node had thus returned home. The real issue is not "the Source Address would be detected by the home agent as a duplicate address", it is simpler: the home deregistration is not yet done so packets to the home address are tunneled via the previous care-of address. But the result is the same: NSs from the home address don't work. Another detail to fix: the RA "from which it learned ..." is from a router, not in all cases from the HA itself (Murphy's law applies: if there is more than one router (the HA), the first RA will never be from the HA, near 100% hit in my experiments :-). The current proposal is: If the mobile node does Neighbor Solicitation to learn the home agent's link-layer address, in this special case of the mobile node returning home, the mobile node MUST unicast the packet, and in addition set the Source Address of this Neighbor Solicitation to the unspecified address (0:0:0:0:0:0:0:0). Since the solicitation is unicast, the home agent will be able to distinguish from a similar packet that would only be used for DAD. The home agent will send a multicast Neighbor Advertisement back to the mobile node with the Solicited flag ('S') set to zero. The mobile node SHOULD accept this advertisement, and set the state of the Neighbor Cache entry for the home agent to REACHABLE. The text is not very clear but the NS is for the HA own address. The problem is that this simply cannot work because in order to unicast the NS to the HA, the HA link-layer address must be already known... The current proposal is a (wrong) fix of the old proposal (ID 12): If the mobile node does Neighbor Solicitation to learn the home agent's link-layer address, in this special case of the mobile node returning home, the mobile node MUST set the Source Address of this Neighbor Solicitation to the unspecified address. This works but is a DAD probe for the HA own address so a better solution was sought... My proposal to fix the problem is: - first to roll back to the previous version - second to weaken the MUST to a MAY (not a SHOULD in order to keep a place for the last item) - third to list all the cases where there is an immediate solution (immediate: without changing a word in other IPv6 standards) - four to seek for another better solution Third: cases where ID 12 solution is not needed (in order): - RA from the HA with a source link-layer option - if the link-local address MN is not registered, just use it as source to multicast a NS for the HA address - if a MN address is not registered, idem Four: hints for a better solution: - make a source address available to MNs - RAs from the HA may not include a source link-layer option, make the inclusion of source link-layer option mandatory for HAs - HAs may not send RAs on reception of RS, make answer mandatory for HAs - HAs must delay answer (RFC 2461 6.2.6), remove this delay when the RS comes from a MN (of course the issue is to recognize this case). So my last idea about a solution is: - when the MN detect a possible link change to the home link (from the link-layer or by the reception of a RA with a home prefix) the MN MUST multicast some RS without its source link-layer option (change to the SHOULD in RFC 2461 4.2) from its home address to all routers - an ordinary router just applies RFC 2461 6.2.6 - a HA which doesn't serve the MN (i.e. hasn't a home registration for the MN home address) applies RFC 2461 6.2.6 with a little improvement: it SHOULD multicast (to all nodes) the RA (note: RFC 2461 gives the choice between unicast or multicast solicited RAs) - a HA which serves the MN (i.e. has a home registration for the MN home address) MUST multicast to all nodes the RA without delay with a source link-layer option if the link has addresses. This makes the default mechanism (good RAs from the HA) to work in all cases with an exception: the MN must be a host because a router must not send RSs... So I am in favor to keep the old solution with a MAY. Regards Francis.Dupont@enst-bretagne.fr PS: if multicasts to all routers/all nodes are too expensive, solicited-node addresses do the job (the MN home address and the HA own address are known) and doesn't need a deep change into current router implementations (no check of the multicast destination of RS/RA, BTW RFC 2461 6.1.1 & 6.1.2 has not such a check in RS/RA validation rules). From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 22 09:50:39 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07963 for ; Wed, 22 Aug 2001 09:50: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 HAA25288; Wed, 22 Aug 2001 07:49: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 GAA08791; Wed, 22 Aug 2001 06:49:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7MDme520601 for mobile-ip-dist; Wed, 22 Aug 2001 06:48:40 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7MDmam20594 for ; Wed, 22 Aug 2001 06:48:36 -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 GAA04171 for ; Wed, 22 Aug 2001 06:48: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 HAA18702 for ; Wed, 22 Aug 2001 07:48:44 -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 f7MDmPK23489 for ; Wed, 22 Aug 2001 15:48:25 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed Aug 22 15:48:24 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Wed, 22 Aug 2001 15:48:24 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008C0C@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] draft-soliman-mobileip-flow-move-00.txt as a WG i tem ? Date: Wed, 22 Aug 2001 15:48: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 prefer to wait on making this a working group item. While > intertechnology handover is an important topic, it is not clear at > this point what the requirements are and whether a change in MIPv6 > is really necessary. It might rather be an item for Seamoby, for > example. > => Perhaps my mail was not very clear. This is an extension for MIPv6 to allow redirecting single flows rather than all (in the current spec). Semoby has nothing to do with this. This a MIPv6 extension. Also inter-access cases are only one application. Currently a multihomed IPv6 host can control its outgoing packets route using IPv6 specs and MIPv6. Nothing is defined to control the inbound route. This is what the draft does. > I have not had time to review this draft in detail, and > would prefer a more comprehensive discussion on intertechnology > handover prior to committing to working group items, as opposed > to picking and choosing particular mechanisms piecemeal. The > latter approach has poorly served the working group in the past. > => This is a generalisation of the problem that we do not need to get into. I'll look forward to your comments after you read the draft. Hesham From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 22 10:39:32 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10932 for ; Wed, 22 Aug 2001 10:39: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 IAA03847; Wed, 22 Aug 2001 08:40:10 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA11139; Wed, 22 Aug 2001 07:39:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7MEd2620725 for mobile-ip-dist; Wed, 22 Aug 2001 07:39:02 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7MEcwm20718 for ; Wed, 22 Aug 2001 07:38: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 HAA15447 for ; Wed, 22 Aug 2001 07:39:02 -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 HAA00977 for ; Wed, 22 Aug 2001 07:39:02 -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 f7MEdIT29964 for ; Wed, 22 Aug 2001 07:39: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 AAD06351; Wed, 22 Aug 2001 07:38:59 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA19857; Wed, 22 Aug 2001 07:38:59 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15235.50179.697073.295602@thomasm-u1.cisco.com> Date: Wed, 22 Aug 2001 07:38:59 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile Routers support without optimization In-Reply-To: <3B83750E.62401349@inrialpes.fr> References: <200108211728.KAA14736@heliopolis.eng.sun.com> <15234.43987.779957.663693@thomasm-u1.cisco.com> <3B83750E.62401349@inrialpes.fr> 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 Thierry Ernst writes: > Michael Thomas wrote: > > The problem is that HA may not a) be trustworthy or > > b) authoratative. Assuming this knowledge is readily > > available anywhere (which I'm not sure), it needs to > > be from a trustworthy and authoratative source. > > If you claim that HA can not be trusted, then this applies equally well > to mobile HOSTS, doesn't it ? As far as standard MIPv6 for mobile HOSTS > is concerned, an implication of this statement is that solutions like > BAKE and cie wouldn't give much help for the authorization of the MH to > send a BU for its home address. Assuming you are talking about stationary hosts behind a mobile router (?) (or even MN's), then sure it can't be trusted. It should be noted that "cannot be trusted" really has an implicit suffix of "in all cases". Indeed, if we can find something which is trustworthy and accurate in the proper context to give us a truthful answer to "is this BU legitimate" then we've made some progress. Mike From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 22 11:07:21 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12406 for ; Wed, 22 Aug 2001 11:07:20 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA26857; Wed, 22 Aug 2001 09: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 IAA16220; Wed, 22 Aug 2001 08:07:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7MF6eX20922 for mobile-ip-dist; Wed, 22 Aug 2001 08:06:40 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7MF6am20915 for ; Wed, 22 Aug 2001 08:06: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 IAA19760 for ; Wed, 22 Aug 2001 08:06:40 -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 JAA25614 for ; Wed, 22 Aug 2001 09:06:34 -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 f7MF6av06588 for ; Wed, 22 Aug 2001 17:06:37 +0200 (MEST) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id RAA10808; Wed, 22 Aug 2001 17:06:36 +0200 Message-ID: <3B83CA0B.52752C8F@era.ericsson.se> Date: Wed, 22 Aug 2001 17:04:43 +0200 From: Mattias Pettersson Organization: Ericsson Research X-Mailer: Mozilla 4.77 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile Routers support without optimization References: <200108211728.KAA14736@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 Alexandru Petrescu wrote: > > James Kempf writes: > > The issue is independent of whether the CN knows the subnet > > relationship between MN, HA, and MR. > > I think that knowing the true MR's prefix by probing MR-HA-MNN does > say a lot about what that MR can claim. Of course, "probing" will > probably contain keying material. A solution such as BAKE tries to prove authorization by "probing" the return routability. The CN can check that the same MN is reachable both by its CoA and home address. It relies on the routing system to deliver packets to the MN's home address. It is weak, since it is not using out-of-band signalling and is exposed to some MitM attacks. However, this method works for single addresses. But you don't do the same for an entire prefix. You can't probe all (2^64) possible MNNs in a single /64 claimed by a MR. /Mattias From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 22 11:21:43 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13192 for ; Wed, 22 Aug 2001 11: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 IAA14039; Wed, 22 Aug 2001 08:22: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 IAA22610; Wed, 22 Aug 2001 08:21:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7MFKUV21074 for mobile-ip-dist; Wed, 22 Aug 2001 08:20:30 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7MFKRm21067 for ; Wed, 22 Aug 2001 08:20: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 IAA22313 for ; Wed, 22 Aug 2001 08:20:31 -0700 (PDT) Received: from iol.unh.edu (mars.iol.unh.edu [132.177.121.222]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA07824 for ; Wed, 22 Aug 2001 09:20:26 -0600 (MDT) Received: from BRINSTAR (norfair.iol.unh.edu [132.177.118.42]) by iol.unh.edu (8.9.3/8.9.3) with SMTP id LAA18403 for ; Wed, 22 Aug 2001 11:20:29 -0400 (EDT) From: "John Leser" To: Subject: RE: [mobile-ip] Mobile Router Route Optimization Date: Wed, 22 Aug 2001 11:20:01 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <3B827E2A.90A7A19D@inrialpes.fr> 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 :-----Original Message----- :From: owner-mobile-ip@sunroof.eng.sun.com :[mailto:owner-mobile-ip@sunroof.eng.sun.com]On Behalf Of Thierry Ernst :Sent: Tuesday, August 21, 2001 11:29 AM :To: mobile-ip@sunroof.eng.sun.com :Subject: Re: [mobile-ip] Mobile Router Route Optimization : : :John Leser wrote: :> :> Hi folks, :> :> Just to throw some more fuel on the fire, I question the value :of allowing :> an MR to bind anything other than /128 with a CN. :> :> As an alternative, let's say the MR, when it detects that an MNN is :> communicating with some CN, sends a BU just for that MNN's address to the :> CN. In effect, it sends a normal BU on behalf of the MNN, but using the :> MR's COA. The obvious downside is that when multiple MNNs are :communicating :> with the same CN, more BUs will be sent. (One BU per MNN, per CN, rather :> than just one per CN). : :We thought about that in the first place. I think that such solution :would lead to flooding the network with BUs. All your family is in the :same car and each member has a session with grand-ma. Why would all :members send a BU to grand-ma when you could aggregate it ? :Prefix-scope BUs leaves room for more optimizations. : I agree that this is the biggest drawback of handing the BU's this way. However, there are several drawbacks to the prefix scope BUs. - They require a longest prefix match lookup, rather then an exact match lookup in the binding cache on the part of the CN. Exact match can be linear on the number of entries in the binding cache, while prefix match cannot (please correct me if I'm wrong) If we could predict the future, it would be easy to see which way this CPU vs. memory tradeoff should go. Right now, I have no idea. But, grandma will likely have at least as much or more TCP or application state as BU state per session. - They require more trust on the part of the CN to accept the BU. Of course, since many of the security issues are somewhat unresolved in the general senses, I am making an something of an assumption here. So, if every one tries to opens session with grandma at the same time, is it better to a.) flood a bunch of single address BUs, or b.) to send a single prefix BU's, that gets rejected because grandma (or rather, whoever wrote grandma's IPv6 stack) was afraid of unforeseen security exploits with prefix BU's, and all packets take a triangular route. So, in a sense, my argument against the prefix BU is that while it is superior in the example you gave, it has a more damaging worst case scenario. Another possibility is to allow both, but only allow the prefix BU when strong authentication/authorization is available. One situation where all MNNs may have sessions with a single CN is DNS. Since your DNS is likely to share in whatever PKI your ISP or organization sets up, it's much easier to securely set up a prefix-BU. :> The two upsides are that CN binding cache lookup :> remains simple (exact address match), and that BU authentication :isn't any :> harder than it is in the non-router case (MR must have whatever :credentials :> needed to bind each MNN's address, just as it would for its own address). : :I disagree. Authentication is not an upside. A node should not be :allowed to send a BU 'on behalf' of another node. Here, it's not a :matter of authorization, but a matter of authentication. Are you :willing the MR to authenticate on behalf of yourself ? I am not sure :the MR has whatever credentials for this, particularly if the MNN is a :VMN, nor that it would be such a good idea.You are in a flight, would :you allow the aircraft company to authenticate on-behalf of you ? I can :imagine transient issues. : :In the prefix-scope BU proposal, the BU is sent by the MR and the MR is :authenticated as being the one it claims to be. Wether or not MR has :the right to advertise the BU is an authorization issue, not :authentication issue. I would prefer this scenario. : :BTW, couldn't we rely on certificates to authorize a MR to send a BU for :a prefix /p ? I am not a securiry guy, then this might not make sense, :but no one gave my a no-reply to this when I first mentioned it. : You are correct - I should have said authorization is easier. But I must disagree with your reasoning that the MR should not be able to send BU's on behalf of another node. Any node behind a router places this kind of trust in its router - after all, any intermediate router between two nodes can easily hijack a session. My reasoning for why authorization is easier is a bit harder to show. It really depends on what method (beside strong PKI based methods) is used to authorize bindings. I was under the impression, based discussion on this list, that part of the problem with authorizing prefix BU's was the fact that the HA can't know for sure whether a certain prefix length is OK for the MR to bind with an arbitrary CN. Not using prefix-BUs gets around this. : :> The MR would still bind prefixes with its home agent, which is :much easier, :> assuming we expect the HA to have been preconfigured with the prefixes to :> expect from each MR. This is the expectation, as I've gathered from :> discussion on this list. :> :> -John : :-- :* 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 Aug 22 11:58:02 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14645 for ; Wed, 22 Aug 2001 11:58:02 -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 IAA03285; Wed, 22 Aug 2001 08:58: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 IAA28991; Wed, 22 Aug 2001 08:57:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7MFubV21179 for mobile-ip-dist; Wed, 22 Aug 2001 08:56:37 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7MFuXm21172 for ; Wed, 22 Aug 2001 08:56: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 IAA28028 for ; Wed, 22 Aug 2001 08:56:38 -0700 (PDT) Message-Id: <200108221556.IAA28028@heliopolis.eng.sun.com> Date: Wed, 22 Aug 2001 08:56:38 -0700 (PDT) From: James Kempf Subject: Re: [mobile-ip] Mobile Routers support without optimization To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Co4RzY7RWd94rBoWjsG5BA== 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, >> The problem is that HA may not a) be trustworthy or >> b) authoratative. Assuming this knowledge is readily >> available anywhere (which I'm not sure), it needs to >> be from a trustworthy and authoratative source. > >If you claim that HA can not be trusted, then this applies equally well >to mobile HOSTS, doesn't it ? As far as standard MIPv6 for mobile HOSTS >is concerned, an implication of this statement is that solutions like >BAKE and cie wouldn't give much help for the authorization of the MH to >send a BU for its home address. > >Just trying to be consistent. Maybe I'm missing something, but doesn't the MN have a security association with it's HA? So the MN can trust it's HA. The issue here is whether the CN can trust the HA, and without a similar security association, I think Michael's point is correct. jak From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 22 12:40:13 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16102 for ; Wed, 22 Aug 2001 12:40: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 KAA16845; Wed, 22 Aug 2001 10:40: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 JAA07496; Wed, 22 Aug 2001 09:40:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7MGdUG21342 for mobile-ip-dist; Wed, 22 Aug 2001 09:39:30 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7MGdQm21335 for ; Wed, 22 Aug 2001 09:39: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 JAA07899 for ; Wed, 22 Aug 2001 09:39:31 -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 KAA07838 for ; Wed, 22 Aug 2001 10:39:49 -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 f7MGdlT21366 for ; Wed, 22 Aug 2001 09:39: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 AAE01078; Wed, 22 Aug 2001 09:39:27 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA19865; Wed, 22 Aug 2001 09:39:27 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15235.57407.450172.275875@thomasm-u1.cisco.com> Date: Wed, 22 Aug 2001 09:39:27 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile Routers support without optimization In-Reply-To: <200108221556.IAA28028@heliopolis.eng.sun.com> References: <200108221556.IAA28028@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: > Thierry, > > >> The problem is that HA may not a) be trustworthy or > >> b) authoratative. Assuming this knowledge is readily > >> available anywhere (which I'm not sure), it needs to > >> be from a trustworthy and authoratative source. > > > >If you claim that HA can not be trusted, then this applies equally well > >to mobile HOSTS, doesn't it ? As far as standard MIPv6 for mobile HOSTS > >is concerned, an implication of this statement is that solutions like > >BAKE and cie wouldn't give much help for the authorization of the MH to > >send a BU for its home address. > > > >Just trying to be consistent. > > Maybe I'm missing something, but doesn't the MN have a security > association with it's HA? So the MN can trust it's HA. The issue > here is whether the CN can trust the HA, and without a similar > security association, I think Michael's point is correct. Ah. Yes, just because I trust my home agent doesn't mean that everybody should trust my home agent. The home agent *may* be trustable, but if the CN doesn't have any way to differentiate trustworthy ones from untrustworthy ones, it doesn't do it much good, and must therefore assume it is not trustworthy either. What may work here is a UN Security Council like approach here where the routers in the path between CN and HA inclusive all have absolute veto power over any proposal. Only by running this gauntlet can any request be accepted. Mike From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 22 14:55:39 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20490 for ; Wed, 22 Aug 2001 14:55: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 LAA08781; Wed, 22 Aug 2001 11:55: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 LAA03644; Wed, 22 Aug 2001 11:54:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7MIrAJ21623 for mobile-ip-dist; Wed, 22 Aug 2001 11:53:10 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7MIr6m21616 for ; Wed, 22 Aug 2001 11:53:06 -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 LAA11601 for ; Wed, 22 Aug 2001 11:53:05 -0700 (PDT) Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA16334 for ; Wed, 22 Aug 2001 11:53:05 -0700 (PDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id OAA115876 for ; Wed, 22 Aug 2001 14:50:55 -0400 Received: from d03nm066.boulder.ibm.com (d03nm066.boulder.ibm.com [9.99.140.50]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7MIqvP70110 for ; Wed, 22 Aug 2001 12:52:58 -0600 Subject: [mobile-ip] Request for information on Conceptual Data Structure To: mobile-ip@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Krishna Kumar" Date: Wed, 22 Aug 2001 11:50:50 -0700 X-MIMETrack: Serialize by Router on D03NM066/03/M/IBM(Release 5.0.8 |June 18, 2001) at 08/22/2001 12:57:11 PM 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, The text on "Sending Advertisements to the Mobile Node" says that the Unique Identifier field of a Binding Update is compared to that sent with the Binding Request. Section 9.8.3 : ---------------- A Binding Update matches a Binding Request if it specifies a binding for the mobile node to which the Binding Request was sent and contains a Unique Identifier Sub-Option matching the unique identifier sent in the Unique Identifier Sub-Option in the Binding Request. Does this requirement make it mandatory for the Conceptual DS of the Binding Cache to contain a field for the UID sent with the BR, to be able to perform the comparison ? Thanks for any information on this! Regards, - KK From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 22 15:08:18 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21014 for ; Wed, 22 Aug 2001 15:08:18 -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 NAA00689; Wed, 22 Aug 2001 13:08: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 MAA07076; Wed, 22 Aug 2001 12:08:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7MJ6RO21725 for mobile-ip-dist; Wed, 22 Aug 2001 12:06:27 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7MJ6Om21718 for ; Wed, 22 Aug 2001 12:06: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 MAA06574 for ; Wed, 22 Aug 2001 12:06:28 -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 MAA24527 for ; Wed, 22 Aug 2001 12:06:28 -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 MAA18841 for ; Wed, 22 Aug 2001 12:06:27 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f7MJ6RR02515 for ; Wed, 22 Aug 2001 12:06:27 -0700 X-mProtect: Wed, 22 Aug 2001 12:06:27 -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 smtpdLPdJqd; Wed, 22 Aug 2001 12:06:25 PDT Message-ID: <3B8402B2.A4935BF7@iprg.nokia.com> Date: Wed, 22 Aug 2001 12:06:26 -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] Mobile IPv6 draft revision References: <200108221251.f7MCp4l58630@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit hi Francis, some comments.... the MN detects that it has returned home by getting a router advertisement from the home agent or from a router on the home link. lets assume the router advertisement does not have a source link layer address option. now the MN needs the home agent's MAC address to send a deregistration BU. the MN sends a neighbor solicitation first neighbor solicitation src = unspecified address dst = all nodes multicast address target = Home Agent the home agent receives the NS and respnds with a NA. since the source address for the NS was unspecified, the NA is sent to the all nodes multicast address. neighbor advertisment src = link local dst = all nodes multicast address target = Home Agent since the dst address on the NA is all nodes multicast address this packet skips any binding cache entry that exists for the MN. the MN receives this NA and creates a REACHABLE neighbor cache for the Home Agent. after that the MN sends a BU for deregistration. wont this work? vijay Francis Dupont wrote: > > I've discussed about this with Charlie but we need mailing list approval. > > My concern is about section 10.20 (returning Home). > Context is: > > When sending this Binding Update to its home agent, the mobile > node must be careful in how it uses Neighbor Solicitation [17] (if > needed) to learn the home agent's link-layer address, since the home > agent will be currently configured to defend the mobile node's home > address for Duplicate Address Detection. In particular, a Neighbor > Solicitation from the mobile node using its home address as the > Source Address would be detected by the home agent as a duplicate > address. In many cases, Neighbor Solicitation by the mobile node > for the home agent's address will not be necessary, since the mobile > node may have already learned the home agent's link-layer address, > for example from a Source Link-Layer Address option in the Router > Advertisement from which it learned that its home address was on-link > and that the mobile node had thus returned home. > > The real issue is not "the Source Address would be detected by the > home agent as a duplicate address", it is simpler: the home > deregistration is not yet done so packets to the home address are > tunneled via the previous care-of address. But the result is the > same: NSs from the home address don't work. > Another detail to fix: the RA "from which it learned ..." is from > a router, not in all cases from the HA itself (Murphy's law applies: > if there is more than one router (the HA), the first RA will never > be from the HA, near 100% hit in my experiments :-). > > The current proposal is: > > If the mobile node > does Neighbor Solicitation to learn the home agent's link-layer > address, in this special case of the mobile node returning home, the > mobile node MUST unicast the packet, and in addition set the Source > Address of this Neighbor Solicitation to the unspecified address > (0:0:0:0:0:0:0:0). Since the solicitation is unicast, the home > agent will be able to distinguish from a similar packet that would > only be used for DAD. The home agent will send a multicast Neighbor > Advertisement back to the mobile node with the Solicited flag ('S') > set to zero. The mobile node SHOULD accept this advertisement, and > set the state of the Neighbor Cache entry for the home agent to > REACHABLE. > > The text is not very clear but the NS is for the HA own address. > The problem is that this simply cannot work because in order to unicast > the NS to the HA, the HA link-layer address must be already known... > > The current proposal is a (wrong) fix of the old proposal (ID 12): > > If the mobile node > does Neighbor Solicitation to learn the home agent's link-layer > address, in this special case of the mobile node returning home, the > mobile node MUST set the Source Address of this Neighbor Solicitation > to the unspecified address. > > This works but is a DAD probe for the HA own address so a better > solution was sought... > > My proposal to fix the problem is: > - first to roll back to the previous version > - second to weaken the MUST to a MAY (not a SHOULD in order to keep > a place for the last item) > - third to list all the cases where there is an immediate solution > (immediate: without changing a word in other IPv6 standards) > - four to seek for another better solution > > Third: cases where ID 12 solution is not needed (in order): > - RA from the HA with a source link-layer option > - if the link-local address MN is not registered, just use it > as source to multicast a NS for the HA address > - if a MN address is not registered, idem > > Four: hints for a better solution: > - make a source address available to MNs > - RAs from the HA may not include a source link-layer option, > make the inclusion of source link-layer option mandatory for HAs > - HAs may not send RAs on reception of RS, make answer mandatory for HAs > - HAs must delay answer (RFC 2461 6.2.6), remove this delay when > the RS comes from a MN (of course the issue is to recognize this case). > > So my last idea about a solution is: > - when the MN detect a possible link change to the home link > (from the link-layer or by the reception of a RA with a home prefix) > the MN MUST multicast some RS without its source link-layer option > (change to the SHOULD in RFC 2461 4.2) from its home address to > all routers > - an ordinary router just applies RFC 2461 6.2.6 > - a HA which doesn't serve the MN (i.e. hasn't a home registration > for the MN home address) applies RFC 2461 6.2.6 with a little > improvement: it SHOULD multicast (to all nodes) the RA > (note: RFC 2461 gives the choice between unicast or multicast > solicited RAs) > - a HA which serves the MN (i.e. has a home registration for the > MN home address) MUST multicast to all nodes the RA without delay > with a source link-layer option if the link has addresses. > > This makes the default mechanism (good RAs from the HA) to work in > all cases with an exception: the MN must be a host because a router > must not send RSs... So I am in favor to keep the old solution with > a MAY. > > Regards > > Francis.Dupont@enst-bretagne.fr > > PS: if multicasts to all routers/all nodes are too expensive, > solicited-node addresses do the job (the MN home address and > the HA own address are known) and doesn't need a deep change > into current router implementations (no check of the multicast > destination of RS/RA, BTW RFC 2461 6.1.1 & 6.1.2 has not such > a check in RS/RA validation rules). From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 22 16:51:33 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23758 for ; Wed, 22 Aug 2001 16:51: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 NAA02802; Wed, 22 Aug 2001 13:52:12 -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 NAA27722; Wed, 22 Aug 2001 13:51:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7MKo5W22055 for mobile-ip-dist; Wed, 22 Aug 2001 13:50:05 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7MKo2m22048 for ; Wed, 22 Aug 2001 13: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 NAA27295 for ; Wed, 22 Aug 2001 13:50:07 -0700 (PDT) Received: from zrc2s03g.us.nortel.com (zrc2s03g.nortelnetworks.com [47.103.122.66]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA27368 for ; Wed, 22 Aug 2001 13:50:06 -0700 (PDT) Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id PAA08685 for ; Wed, 22 Aug 2001 15:49:51 -0500 (CDT) Received: from zrchb200.us.nortel.com by smtprch2.nortel.com; Wed, 22 Aug 2001 15:43:29 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 Aug 2001 15:49:39 -0500 Message-ID: <85AA7486A2C1D411BCA20000F8073E43032E34BA@crchy271.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Mobile Routers support without optimization Date: Wed, 22 Aug 2001 15:49:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C12B4B.F5023A30" 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_01C12B4B.F5023A30 Content-Type: text/plain; charset="iso-8859-1" Would not the trust relationship between the HA and the CN is analogous to a router which delivers a packet on the last hop to another non mobile node? Doesn't the inherent trust relationship (of the IP routers) that the packet sent to an IP address, the home address, will be delivered to the correct network, guard sufficiently against this percieved HA, MN collusion threat? If not, then I guess we can't trust these last hop routers either for even non-mobile cases and we would have to use AH on every packet send from any source to any destination? It seems to me that to question whether the HA can be trusted is to question if any router can be trusted. -----Original Message----- From: Michael Thomas [mailto:mat@cisco.com] Sent: Wednesday, August 22, 2001 11:39 AM To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile Routers support without optimization James Kempf writes: > Thierry, > > >> The problem is that HA may not a) be trustworthy or > >> b) authoratative. Assuming this knowledge is readily > >> available anywhere (which I'm not sure), it needs to > >> be from a trustworthy and authoratative source. > > > >If you claim that HA can not be trusted, then this applies equally well > >to mobile HOSTS, doesn't it ? As far as standard MIPv6 for mobile HOSTS > >is concerned, an implication of this statement is that solutions like > >BAKE and cie wouldn't give much help for the authorization of the MH to > >send a BU for its home address. > > > >Just trying to be consistent. > > Maybe I'm missing something, but doesn't the MN have a security > association with it's HA? So the MN can trust it's HA. The issue > here is whether the CN can trust the HA, and without a similar > security association, I think Michael's point is correct. Ah. Yes, just because I trust my home agent doesn't mean that everybody should trust my home agent. The home agent *may* be trustable, but if the CN doesn't have any way to differentiate trustworthy ones from untrustworthy ones, it doesn't do it much good, and must therefore assume it is not trustworthy either. What may work here is a UN Security Council like approach here where the routers in the path between CN and HA inclusive all have absolute veto power over any proposal. Only by running this gauntlet can any request be accepted. Mike ------_=_NextPart_001_01C12B4B.F5023A30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Mobile Routers support without = optimization

Would not the trust relationship between the HA and = the CN is analogous to a router which delivers a packet on the last hop = to another non mobile node? Doesn't the inherent trust relationship (of = the IP routers) that the packet sent to an IP address, the home = address, will be delivered to the correct network, guard sufficiently = against this percieved HA, MN collusion threat?

If not, then I guess we can't trust these last hop = routers either for even non-mobile cases and we would have to use AH on = every packet send from any source to any destination? It seems to me = that to question whether the HA can be trusted is to question if any = router can be trusted.

-----Original Message-----
From: Michael Thomas [mailto:mat@cisco.com]
Sent: Wednesday, August 22, 2001 11:39 AM
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Mobile Routers support = without optimization


James Kempf writes:
 > Thierry,
 >
 > >>    The problem is = that HA may not a) be trustworthy or
 > >>    b) = authoratative. Assuming this knowledge is readily
 > >>    available = anywhere (which I'm not sure), it needs to
 > >>    be from a = trustworthy and authoratative source.
 > >
 > >If you claim that HA can not be = trusted, then this applies equally well
 > >to mobile HOSTS, doesn't it ?  = As far as standard MIPv6 for mobile HOSTS
 > >is concerned, an implication of this = statement is that solutions like
 > >BAKE and cie wouldn't give much help = for the authorization of the MH to
 > >send a BU for its home address.  =
 > >
 > >Just trying to be consistent.
 >
 > Maybe I'm missing something, but doesn't = the MN have a security
 > association with it's HA? So the MN can = trust it's HA. The issue
 > here is whether the CN can trust the HA, = and without a similar
 > security association, I think Michael's = point is correct.

   Ah. Yes, just because I trust my home = agent doesn't
   mean that everybody should trust my = home agent. The
   home agent *may* be trustable, but if = the CN doesn't
   have any way to differentiate = trustworthy ones from
   untrustworthy ones, it doesn't do it = much good, and
   must therefore assume it is not = trustworthy either.

   What may work here is a UN Security = Council like
   approach here where the routers in the = path between
   CN and HA inclusive all have absolute = veto power
   over any proposal. Only by running this = gauntlet
   can any request be accepted.

           Mike

------_=_NextPart_001_01C12B4B.F5023A30-- From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 22 17:29:07 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24425 for ; Wed, 22 Aug 2001 17:29: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 PAA26475; Wed, 22 Aug 2001 15:29: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 OAA05576; Wed, 22 Aug 2001 14:29:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7MLS9b22298 for mobile-ip-dist; Wed, 22 Aug 2001 14:28:09 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7MLS5m22291 for ; Wed, 22 Aug 2001 14:28: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 OAA14058 for ; Wed, 22 Aug 2001 14:28:11 -0700 (PDT) Message-Id: <200108222128.OAA14058@heliopolis.eng.sun.com> Date: Wed, 22 Aug 2001 14:28:11 -0700 (PDT) From: James Kempf Subject: RE: [mobile-ip] Mobile Routers support without optimization To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: hI901CMEmunbwthLZlIpfg== 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: Glenn, The issue is that the HA is not required to participate in any standard routing update protocol, so the CN cannot have confidence that it is authorized to distribute routing information. Telling the CN that an MN had the right to route a prefix is essentially distributing routing information. jak >From: "Glenn Morrow" >To: mobile-ip@sunroof.eng.sun.com >Subject: RE: [mobile-ip] Mobile Routers support without optimization >Date: Wed, 22 Aug 2001 15:49:37 -0500 > >Would not the trust relationship between the HA and the CN is analogous to a >router which delivers a packet on the last hop to another non mobile node? >Doesn't the inherent trust relationship (of the IP routers) that the packet >sent to an IP address, the home address, will be delivered to the correct >network, guard sufficiently against this percieved HA, MN collusion threat? > >If not, then I guess we can't trust these last hop routers either for even >non-mobile cases and we would have to use AH on every packet send from any >source to any destination? It seems to me that to question whether the HA >can be trusted is to question if any router can be trusted. > >-----Original Message----- >From: Michael Thomas [mailto:mat@cisco.com] >Sent: Wednesday, August 22, 2001 11:39 AM >To: mobile-ip@sunroof.eng.sun.com >Subject: Re: [mobile-ip] Mobile Routers support without optimization > > >James Kempf writes: > > Thierry, > > > > >> The problem is that HA may not a) be trustworthy or > > >> b) authoratative. Assuming this knowledge is readily > > >> available anywhere (which I'm not sure), it needs to > > >> be from a trustworthy and authoratative source. > > > > > >If you claim that HA can not be trusted, then this applies equally well > > >to mobile HOSTS, doesn't it ? As far as standard MIPv6 for mobile HOSTS > > >is concerned, an implication of this statement is that solutions like > > >BAKE and cie wouldn't give much help for the authorization of the MH to > > >send a BU for its home address. > > > > > >Just trying to be consistent. > > > > Maybe I'm missing something, but doesn't the MN have a security > > association with it's HA? So the MN can trust it's HA. The issue > > here is whether the CN can trust the HA, and without a similar > > security association, I think Michael's point is correct. > > Ah. Yes, just because I trust my home agent doesn't > mean that everybody should trust my home agent. The > home agent *may* be trustable, but if the CN doesn't > have any way to differentiate trustworthy ones from > untrustworthy ones, it doesn't do it much good, and > must therefore assume it is not trustworthy either. > > What may work here is a UN Security Council like > approach here where the routers in the path between > CN and HA inclusive all have absolute veto power > over any proposal. Only by running this gauntlet > can any request be accepted. > > Mike From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 22 17:29:43 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24437 for ; Wed, 22 Aug 2001 17:29: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 OAA24724; Wed, 22 Aug 2001 14:29: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 OAA01478; Wed, 22 Aug 2001 14:11:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7MLAck22173 for mobile-ip-dist; Wed, 22 Aug 2001 14:10:38 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7MLAYm22166 for ; Wed, 22 Aug 2001 14:10:34 -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 OAA09382 for ; Wed, 22 Aug 2001 14:10:40 -0700 (PDT) From: jarno.rajahalme@nokia.com Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA07684 for ; Wed, 22 Aug 2001 15:10:35 -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 f7MLEQG22935 for ; Thu, 23 Aug 2001 00:14:26 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 23 Aug 2001 00:10:37 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MSVZTPS>; Thu, 23 Aug 2001 00:10:36 +0300 Message-ID: <009CA59D1752DD448E07F8EB2F911757197FE0@esebe004.NOE.Nokia.com> To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] IPsec, IKE, MIPv6 and concensus Date: Thu, 23 Aug 2001 00:10:35 +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: Hesham wrote: > > > > Sure this is a performance optimization only, and the > degree of the benefit > > depends heavily on the type of L2's in both ends, feature > interaction with > > HC, etc., but if done right there is nothing that would > make the standard > > "only work sometimes". It is quite customary that standards > have options > > that are not always used. > > > => The question is whether this complexity you mention above > (L2 interaction, HC implications, Path MTU ....etc) are worth > the hassles. There is no foreseen benefit really if you're > using ROHC for example. Do you think the perceived gain > actually outweighs the processing headache ? > If it does then what you're suggesting would make a lot of sense. > All that complexity of figuring out when it is worthwhile and possible to piggyback lies on the engineer implementing piggybacking. If you rather not bother, then do not piggyback. There is no added complexity for the recipient. Also, if you'd *know* piggybacking has absolutely no benefit, why'd you tell your competitors that :-? Seriously, you should piggyback only if you think it's worth the effort. Jarno From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 22 17:37:51 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24557 for ; Wed, 22 Aug 2001 17:37: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 OAA28942; Wed, 22 Aug 2001 14:38:15 -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 OAA02579; Wed, 22 Aug 2001 14:17:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7MLG8C22207 for mobile-ip-dist; Wed, 22 Aug 2001 14:16:08 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7MLG5m22200 for ; Wed, 22 Aug 2001 14:16: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 OAA10461 for ; Wed, 22 Aug 2001 14:16:10 -0700 (PDT) From: jarno.rajahalme@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 OAA10645 for ; Wed, 22 Aug 2001 14:16:09 -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 f7MLJuG23899 for ; Thu, 23 Aug 2001 00:19:56 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 23 Aug 2001 00:16:07 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MSVZTP8>; Thu, 23 Aug 2001 00:16:06 +0300 Message-ID: <009CA59D1752DD448E07F8EB2F91175715D49B@esebe004.NOE.Nokia.com> To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] IPsec, IKE, MIPv6 and concensus Date: Thu, 23 Aug 2001 00:16:03 +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: Wolfgang wrote: > It's clear that a piggyback decision is done on a per-packet basis, > but that's not what I addressed. My concern has been that sending BU > piggybacked means that the SA to be established for this packet will > address the security issues for the BU and the payload in the packet. > As this SA will not be created just for one packet's lifetime, but > last for a longer period, my comment has been that you may get into > trouble if at a later time (when this SA is still valid) payload data > has to be exchanged between MN and CN, which require the > establishment of a different (from the security properties) SA. Will > you then override the existing one, and if so will you also use the > new one for future BUs, ... The assumption for this discussion has been that the SPD entries for the BU and for the payload can be separately identified (with the new next header value). From this perspective the problem you describe does not arise. Jarno From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 22 18:16:22 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25182 for ; Wed, 22 Aug 2001 18:16: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 PAA16118; Wed, 22 Aug 2001 15:16: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 PAA25810; Wed, 22 Aug 2001 15:14:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7MMDCr22711 for mobile-ip-dist; Wed, 22 Aug 2001 15:13:12 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7MMD9m22704 for ; Wed, 22 Aug 2001 15:13:09 -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 PAA18152 for ; Wed, 22 Aug 2001 15:13: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 QAA27845 for ; Wed, 22 Aug 2001 16:13:09 -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 f7MMDCK01033 for ; Thu, 23 Aug 2001 00:13:12 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Thu Aug 23 00:13:12 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Thu, 23 Aug 2001 00:13:06 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008C15@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] IPsec, IKE, MIPv6 and concensus Date: Thu, 23 Aug 2001 00:13: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: > > > Sure this is a performance optimization only, and the > > degree of the benefit > > > depends heavily on the type of L2's in both ends, feature > > interaction with > > > HC, etc., but if done right there is nothing that would > > make the standard > > > "only work sometimes". It is quite customary that standards > > have options > > > that are not always used. > > > > > => The question is whether this complexity you mention above > > (L2 interaction, HC implications, Path MTU ....etc) are worth > > the hassles. There is no foreseen benefit really if you're > > using ROHC for example. Do you think the perceived gain > > actually outweighs the processing headache ? > > If it does then what you're suggesting would make a lot of sense. > > > > All that complexity of figuring out when it is worthwhile and possible to > piggyback lies on the engineer implementing piggybacking. If you rather not > bother, then do not piggyback. There is no added complexity for the > recipient. > => The only question unanswered (at least to me) is the one Erik posted on the topic (TCP connections expecting all packets to be protected). Other than that what you're saying makes sense. > Also, if you'd *know* piggybacking has absolutely no benefit, why'd you tell > your competitors that :-? > => Don't worry I won't say everyting :) I just want to see good spec become an RFC. Hesham From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 22 19:53:51 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26627 for ; Wed, 22 Aug 2001 19:53: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 RAA01058; Wed, 22 Aug 2001 17: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 QAA14115; Wed, 22 Aug 2001 16:54:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7MNqrs23129 for mobile-ip-dist; Wed, 22 Aug 2001 16:52:53 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7MNqnm23122 for ; Wed, 22 Aug 2001 16:52: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 QAA06270 for ; Wed, 22 Aug 2001 16:52:54 -0700 (PDT) From: jarno.rajahalme@nokia.com Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA29610 for ; Wed, 22 Aug 2001 16:52:53 -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 f7MNueG15393 for ; Thu, 23 Aug 2001 02:56:40 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 23 Aug 2001 02:52:52 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MSVZTYG>; Thu, 23 Aug 2001 02:52:52 +0300 Message-ID: <009CA59D1752DD448E07F8EB2F911757197FE1@esebe004.NOE.Nokia.com> To: Erik.Nordmark@eng.sun.com, jarno.rajahalme@nokia.com Cc: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] IPsec, IKE, MIPv6 and concensus Date: Thu, 23 Aug 2001 02:52:49 +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: Erik wrote: > > > The scenario is: > > > > - Need to send a BU to a CN > > - If there is an outgoing packet to the CN in a queue, and > > - the packet is not associated with any SA > > - then can piggyback the BU with the packet in the queue > > - else send BU as a separate packet > > > > If the spec allowed for this, would it be broken in some way? > > Someone (I forgot who) pointed out that even this was a problem for > careful implementations of IPsec. > The claim (which I understand and agree with) is that > a TCP connection would like to use the same security policy > for the lifetime > of the connection. If you don't then how can you use IPsec to prevent > a unsecure RST packet from blowing away your connection? > > Thus if the packet is piggyback on a TCP SYN packet the peer > is likely to assume that all of that TCP connection will be secured, > but that will not be the case since the SYN was only secured > as a site effect > of securing the piggy-backed BU. > You mean that the recipient's IPsec implementation is creating new SPD entries dynamically and implicitly as the side effect of a IPsec envelope used with the TCP SYN packet? If a selector for Mobile IP Next Header is defined, and the SA used for reception of the packet specifies this selector (in which case it would NOT contain a selector for TCP), there is no reason for the IPsec implementation to create any SPD entries for the piggybacked TCP session. But there seems to be a related issue: the recipient should be able to check that the piggybacked TCP packet can indeed get in without IPsec protection. Normally, inbound IPsec processing matches also the packets that came with no IPsec headers against the SPD to determine whether they *should* have come with IPsec headers. If Mobile IP Next Header selector is implemented as Transport Layer Protocol selector, there is no way that IPsec inbound processing could know to look for another embedded transport protocol selector (e.g. TCP) to make sure that the SPD entry for that states "passby". However, if a new selector parameter is defined for "in-between" Next Headers, then both the sender and recipient of any piggybacked transport protocol could check that the SPD entry matching the transport selector does not require IPsec processing. The new selector parameter would be needed to be implemented by all CNs supporting route optimization (as well as the mobile nodes themselves), and the associated check for the SPD entry for the piggybacked transport message should be implemented at the same time as the new selector parameter. By the RFC2401 only the first matching SPD entry is used for packet's IPsec processing ("the first matching entry is consistently selected"). This would need to change in case of "in-between" Next Header selectors and piggybacked transport protocol messages, where multiple SPD entries need to be selected and checked by both ends. Is this acceptable? Jarno From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 22 19:57:54 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26691 for ; Wed, 22 Aug 2001 19:57: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 RAA03325; Wed, 22 Aug 2001 17:58: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 QAA15572; Wed, 22 Aug 2001 16:58:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7MNvnq23179 for mobile-ip-dist; Wed, 22 Aug 2001 16:57:49 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7MNvjm23172 for ; Wed, 22 Aug 2001 16:57:45 -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 QAA16818 for ; Wed, 22 Aug 2001 16:57:50 -0700 (PDT) From: jarno.rajahalme@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA02201 for ; Wed, 22 Aug 2001 17:58:09 -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 f7MNwD311429 for ; Thu, 23 Aug 2001 02:58: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 ; Thu, 23 Aug 2001 02:57:47 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MSVZTYN>; Thu, 23 Aug 2001 02:57:47 +0300 Message-ID: <009CA59D1752DD448E07F8EB2F91175715D49D@esebe004.NOE.Nokia.com> To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] IPsec, IKE, MIPv6 and concensus Date: Thu, 23 Aug 2001 02:57: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: Hesham, As you see from my reply to Erik's message, there may be something in there relating to the IPsec selectors for Next Headers other than transport protocols. I don't know if that is a show-stopper for piggybacking or not. What do you think? Jarno > -----Original Message----- > From: Hesham Soliman (ERA) [mailto:Hesham.Soliman@era.ericsson.se] > Sent: 23. elokuuta 2001 1:13 > To: 'mobile-ip@sunroof.eng.sun.com' > Subject: RE: [mobile-ip] IPsec, IKE, MIPv6 and concensus > > > > > > Sure this is a performance optimization only, and the > > > degree of the benefit > > > > depends heavily on the type of L2's in both ends, feature > > > interaction with > > > > HC, etc., but if done right there is nothing that would > > > make the standard > > > > "only work sometimes". It is quite customary that standards > > > have options > > > > that are not always used. > > > > > > > => The question is whether this complexity you mention above > > > (L2 interaction, HC implications, Path MTU ....etc) are worth > > > the hassles. There is no foreseen benefit really if you're > > > using ROHC for example. Do you think the perceived gain > > > actually outweighs the processing headache ? > > > If it does then what you're suggesting would make a lot > of sense. > > > > > > > All that complexity of figuring out when it is worthwhile > and possible to > > piggyback lies on the engineer implementing piggybacking. > If you rather not > > bother, then do not piggyback. There is no added complexity for the > > recipient. > > > => The only question unanswered (at least to me) is the one > Erik posted on the topic (TCP connections expecting all > packets to be protected). Other than that what you're saying > makes sense. > > > Also, if you'd *know* piggybacking has absolutely no > benefit, why'd you tell > > your competitors that :-? > > > => Don't worry I won't say everyting :) > I just want to see good spec become an RFC. > > Hesham > From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 23 03:46:00 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19974 for ; Thu, 23 Aug 2001 03:46:00 -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 AAA00615; Thu, 23 Aug 2001 00:46: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 AAA03610; Thu, 23 Aug 2001 00:46:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7N7iTh23636 for mobile-ip-dist; Thu, 23 Aug 2001 00:44:29 -0700 (PDT) Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7N7iJm23613 for ; Thu, 23 Aug 2001 00:44:20 -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 f7N7iJN12152; Thu, 23 Aug 2001 09:44:19 +0200 (MET DST) Date: Thu, 23 Aug 2001 09:28:07 +0200 (CEST) From: Erik Nordmark Subject: Re: [mobile-ip] Mobile Routers support without optimization To: Michael Thomas Cc: mobile-ip@sunroof.eng.sun.com, petrescu@crm.mot.com, Erik.Nordmark@eng.sun.com, James.Kempf@Sun.COM In-Reply-To: "Your message with ID" <15234.40790.768468.610613@thomasm-u1.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > There seems to be two separable attacks. First is > the attack where a spoofer is not reachable > on the prefix it is attempting to control at all. > A simple return routability test as is being proposed > for MIPv6 ought to provide adequate protection to > counter that attack (we hope). Agreed. > The second is when > a node which is reachable on the proposed prefix, > but is trying to hijack a larger prefix than it is > authorized for. I believe that the only nodes which > can make a determination as to whether the mobile > router is authorized to advertize that prefix to > the CN are the routers in the path between MN and > CN by way of HA. Yes, this is the second problem I've been trying to shine light on. > In fact, it seems that some router between HA > and CN ought to know whether it summarizes a prefix > which is smaller than the proposed prefix and thus > be able to reject the request. That is, suppose we > have a MN trying to advertize a /8 to a CN. If the > CN sends the proposed BU toward MN (say with router > alert on for grins), and a router in the path discovers > that it summarizes a /16 toward the MN, then > it would know that the request is not legitimate > since it must summarize prefixes which are strictly > larger than in the downstream direction. Whether this > solves all potential attacks, I have no idea, but it > does seem to have the potential for solving this > particular attack. I agree that in theory such a method to extract the hop-by-hop authorization choices can work. So you are providing a good indication of the issues in accomplishing authorization for prefix BUs. I currently have no idea if such a scheme can be made to work in practice. Erik From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 23 03:46:07 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19986 for ; Thu, 23 Aug 2001 03:46: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 AAA00681; Thu, 23 Aug 2001 00:46: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 AAA03654; Thu, 23 Aug 2001 00:46:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7N7iSU23634 for mobile-ip-dist; Thu, 23 Aug 2001 00:44:28 -0700 (PDT) Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7N7iJm23612 for ; Thu, 23 Aug 2001 00:44:20 -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 f7N7iJN12156; Thu, 23 Aug 2001 09:44:19 +0200 (MET DST) Date: Thu, 23 Aug 2001 09:33:32 +0200 (CEST) From: Erik Nordmark Subject: Re: [mobile-ip] Mobile Routers support without optimization To: Michael Thomas Cc: mobile-ip@sunroof.eng.sun.com, Alexandru Petrescu , Erik.Nordmark@eng.sun.com, James Kempf In-Reply-To: "Your message with ID" <15234.44617.546341.967898@thomasm-u1.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > Erik Nordmark writes: > > A provider might assign > > 10.1.0.0/16 to user A > > 10.2.0.0/16 to user B > > 10.3.0.0/16 to user A > > > > This creates "holes" thus in your proposal this can be used by A to claim > > the space assigned to B. > > What this says is that the router(s) which summarizes this > route (say 10.0.0.0/14) is the one that knows that A claiming > 10.0.0.0/15 (or less) is bogus. > > Yes? Yes. Of course, it needs to be able to understand the identities "A" and "B" in order to answer that question. This might be easy of A and B are IP address *from the same prefix*. I don't know what trouble multiple global IPv6 prefixes per subnet will add :-) Erik From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 23 03:46:25 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20003 for ; Thu, 23 Aug 2001 03:46: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 BAA02833; Thu, 23 Aug 2001 01:47:03 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA03651; Thu, 23 Aug 2001 00:46:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7N7iTB23635 for mobile-ip-dist; Thu, 23 Aug 2001 00:44:29 -0700 (PDT) Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7N7iLm23617 for ; Thu, 23 Aug 2001 00:44:22 -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 f7N7iJN12148; Thu, 23 Aug 2001 09:44:19 +0200 (MET DST) Date: Thu, 23 Aug 2001 09:18:04 +0200 (CEST) From: Erik Nordmark Subject: Re: [mobile-ip] Mobile Routers support without optimization To: James Kempf Cc: petrescu@crm.mot.com, Erik.Nordmark@eng.sun.com, mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <200108211609.JAA10505@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: > The issue then becomes whether the HA can be trusted. Now, suppose > the protocol requires that the HA be authenticable via a chain > of trust through the routing update authentication mechanism > used to authenticate OSPF and BGP routes? The mechanism used to authorize (authenticate isn't really the problem here :-) routing updates are hop-by-hop i.e. a BGP speaker might have a configured list of prefixes that peer is allowed to advertise. Due to the aggregation in the routing tables these authorization choices can't possibly be extract beyond where aggregation happens. So I don't see how you can extend this to cover multiple routing adjacency hops - and that is essentially what you are proposing as far as I can tell. Erik From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 23 03:53:14 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20074 for ; Thu, 23 Aug 2001 03:53:14 -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 AAA02706; Thu, 23 Aug 2001 00:54: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 AAA24170; Thu, 23 Aug 2001 00:53:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7N7pqj23791 for mobile-ip-dist; Thu, 23 Aug 2001 00:51:52 -0700 (PDT) Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7N7plm23784 for ; Thu, 23 Aug 2001 00:51:47 -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 f7N7pmN13527; Thu, 23 Aug 2001 09:51:48 +0200 (MET DST) Date: Thu, 23 Aug 2001 09:48:35 +0200 (CEST) From: Erik Nordmark Subject: Re: [mobile-ip] Mobile Routers support without optimization To: Michael Thomas Cc: mobile-ip@sunroof.eng.sun.com, James.Kempf@sun.com, Erik.Nordmark@eng.sun.com In-Reply-To: "Your message with ID" <15234.56620.266061.947619@thomasm-u1.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > Not quite. The authentication just keeps outsiders > out. If you're part of the BGP club though, anything > is possible; if I want to advertise something ridiculous, > nothing prevents me from doing that (that I know of). > Same thing with RIP/OSPF/IS-IS... > > [disclaimer: BGP may have more safeguards than this, > but the real point is that if you're part of the > BGP club, you can do significant damage to the routing > system which is ultimately only enforceable by > other BGP's refusing to peer with you. If > somebody knows otherwise, I'm all ears about > how this is done.] This is gettting a bit off topic but ... It is possible to manually define lists of prefixes that are acceptable from routing peers, indepedent of the routing protocol as far as I know. Thus X could configure its BGP speakers that talk to Y to only accept prefixes P1, P2, etc. I don't know if this is in operational use at all. I've heard of an effort to explore automating this based on the IPv4 address assignments done by the RIRs somehow, but a lot of the IPv4 address space was assigned by the IANA before the RIRs arrived. Erik From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 23 04:46:58 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20601 for ; Thu, 23 Aug 2001 04:46:57 -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 BAA17658; Thu, 23 Aug 2001 01:47:54 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA03102; Thu, 23 Aug 2001 01:47:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7N8kYk23969 for mobile-ip-dist; Thu, 23 Aug 2001 01:46:34 -0700 (PDT) Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7N8kUm23962 for ; Thu, 23 Aug 2001 01:46:30 -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 f7N8kTN22441; Thu, 23 Aug 2001 10:46:29 +0200 (MET DST) Date: Thu, 23 Aug 2001 10:43:16 +0200 (CEST) From: Erik Nordmark Subject: RE: [mobile-ip] IPsec, IKE, MIPv6 and concensus To: jarno.rajahalme@nokia.com Cc: Erik.Nordmark@eng.sun.com, mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <009CA59D1752DD448E07F8EB2F911757197FE1@esebe004.NOE.Nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > You mean that the recipient's IPsec implementation is creating new SPD > entries dynamically and implicitly as the side effect of a IPsec envelope > used with the TCP SYN packet? I think that is what I'm saying (I've though more in terms of what the implementation does than how this fits with the SPD concept). I think an example is that the SPD initially has a matching entry (e.g. just for TCP + the destination port) allowing IPsec or no IPsec. But when a new connection is created an SPD entry is created which matches just that connection and the entry constrains the policy to be what was used on the SYN. I don't know if such a scheme is discussed in RFC2401 but it seems useful since it allows one to build servers where the client can choose whether or not it wants to use ipsec i.e. there is less coordination needed. > If a selector for Mobile IP Next Header is defined, and the SA used for > reception of the packet specifies this selector (in which case it would NOT > contain a selector for TCP), there is no reason for the IPsec implementation > to create any SPD entries for the piggybacked TCP session. So how would you solve the above issue in that case? > But there seems to be a related issue: the recipient should be able to check > that the piggybacked TCP packet can indeed get in without IPsec protection. > > Normally, inbound IPsec processing matches also the packets that came with > no IPsec headers against the SPD to determine whether they *should* have > come with IPsec headers. > > If Mobile IP Next Header selector is implemented as Transport Layer Protocol > selector, there is no way that IPsec inbound processing could know to look > for another embedded transport protocol selector (e.g. TCP) to make sure > that the SPD entry for that states "passby". > > However, if a new selector parameter is defined for "in-between" Next > Headers, then both the sender and recipient of any piggybacked transport > protocol could check that the SPD entry matching the transport selector does > not require IPsec processing. > > The new selector parameter would be needed to be implemented by all CNs > supporting route optimization (as well as the mobile nodes themselves), and > the associated check for the SPD entry for the piggybacked transport message > should be implemented at the same time as the new selector parameter. > > By the RFC2401 only the first matching SPD entry is used for packet's IPsec > processing ("the first matching entry is consistently selected"). This would > need to change in case of "in-between" Next Header selectors and piggybacked > transport protocol messages, where multiple SPD entries need to be selected > and checked by both ends. Is this acceptable? Seems like things are simpler without piggybacking. Erik From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 23 05: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 ESMTP id FAA20759 for ; Thu, 23 Aug 2001 05: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 CAA23483; Thu, 23 Aug 2001 02:08: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 CAA04905; Thu, 23 Aug 2001 02:08:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7N97Rl24055 for mobile-ip-dist; Thu, 23 Aug 2001 02:07:27 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7N97Nm24048 for ; Thu, 23 Aug 2001 02:07:23 -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 CAA25006 for ; Thu, 23 Aug 2001 02:07:29 -0700 (PDT) From: fritsche@iabg.de Received: from iabgfw.iabg.de (iabgfw.iabg.de [194.139.245.2]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA12865 for ; Thu, 23 Aug 2001 02:07:27 -0700 (PDT) Received: by iabgfw.iabg.de; id LAA03941; Thu, 23 Aug 2001 11:07:26 +0200 (MET DST) Received: from unknown(10.255.255.2) by iabgfw.iabg.de via smap (V5.5) id xma003936; Thu, 23 Aug 01 11:07:14 +0200 Received: from iabgvw.iabg.de ([10.255.255.8]) by iabgmh.iabg.de (Post.Office MTA v3.5.1 release 219 ID# 127-59214U1600L300S0V35) with ESMTP id de for ; Thu, 23 Aug 2001 11:07:10 +0200 Received: from iabgdns.iabg.de (localhost [127.0.0.1]) by iabgvw.iabg.de (8.8.8+Sun/8.8.8) with ESMTP id LAA28060 for ; Thu, 23 Aug 2001 11:07:06 +0200 (MET DST) Received: from ziegenlippe (ziegenlippe.iabg.de [10.15.0.185]) by iabgdns.iabg.de (8.8.8+Sun/8.8.8) with SMTP id LAA04597 for ; Thu, 23 Aug 2001 11:07:12 +0200 (MET DST) Message-Id: <200108230907.LAA04597@iabgdns.iabg.de> Comments: Authenticated sender is To: mobile-ip@sunroof.eng.sun.com Date: Thu, 23 Aug 2001 11:07:12 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: RE: [mobile-ip] IPsec, IKE, MIPv6 and concensus In-reply-to: <009CA59D1752DD448E07F8EB2F911757197FE1@esebe004.NOE.Nokia.com> X-mailer: Pegasus Mail for Win32 (v2.54DE) Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7BIT > Erik wrote: > > > > > The scenario is: > > > > > > - Need to send a BU to a CN > > > - If there is an outgoing packet to the CN in a queue, and > > > - the packet is not associated with any SA > > > - then can piggyback the BU with the packet in the queue > > > - else send BU as a separate packet > > > > > > If the spec allowed for this, would it be broken in some way? > > > > Someone (I forgot who) pointed out that even this was a problem for > > careful implementations of IPsec. > > The claim (which I understand and agree with) is that > > a TCP connection would like to use the same security policy > > for the lifetime > > of the connection. If you don't then how can you use IPsec to prevent > > a unsecure RST packet from blowing away your connection? > > > > Thus if the packet is piggyback on a TCP SYN packet the peer > > is likely to assume that all of that TCP connection will be secured, > > but that will not be the case since the SYN was only secured > > as a site effect > > of securing the piggy-backed BU. > > > > You mean that the recipient's IPsec implementation is creating new SPD > entries dynamically and implicitly as the side effect of a IPsec envelope > used with the TCP SYN packet? > > If a selector for Mobile IP Next Header is defined, and the SA used for > reception of the packet specifies this selector (in which case it would NOT > contain a selector for TCP), there is no reason for the IPsec implementation > to create any SPD entries for the piggybacked TCP session. > > But there seems to be a related issue: the recipient should be able to check > that the piggybacked TCP packet can indeed get in without IPsec protection. > > Normally, inbound IPsec processing matches also the packets that came with > no IPsec headers against the SPD to determine whether they *should* have > come with IPsec headers. > > If Mobile IP Next Header selector is implemented as Transport Layer Protocol > selector, there is no way that IPsec inbound processing could know to look > for another embedded transport protocol selector (e.g. TCP) to make sure > that the SPD entry for that states "passby". > > However, if a new selector parameter is defined for "in-between" Next > Headers, then both the sender and recipient of any piggybacked transport > protocol could check that the SPD entry matching the transport selector does > not require IPsec processing. This is exactly what my second comment in my previous email was about. Todays IPSec doesn't provide this functionality, so IPSec would need to be enhance by the following: 1. Add a new IPSec selector (what you called "in-between" Next Header) 2. Allow IPSec implementation to apply two IPSec policies (one for the "in-between" Next Header, one for the payload) to the same packet. What shall be done, if both are contradictorily? This could become quite complex for implementations. And as you mention below, this has to be done for all CNs and MNs, that is for nearly all host implementations. I'm not sure if it will be possible to get these IPSec modifications done. And is piggybacking really worth this effort? > The new selector parameter would be needed to be implemented by all CNs > supporting route optimization (as well as the mobile nodes themselves), and > the associated check for the SPD entry for the piggybacked transport message > should be implemented at the same time as the new selector parameter. > > By the RFC2401 only the first matching SPD entry is used for packet's IPsec > processing ("the first matching entry is consistently selected"). This would > need to change in case of "in-between" Next Header selectors and piggybacked > transport protocol messages, where multiple SPD entries need to be selected > and checked by both ends. Is this acceptable? > > Jarno > Wolfgang From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 23 05:12:05 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20810 for ; Thu, 23 Aug 2001 05:12:05 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA27681; Thu, 23 Aug 2001 03:12:55 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA05426; Thu, 23 Aug 2001 02:12:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7N9Bps24105 for mobile-ip-dist; Thu, 23 Aug 2001 02:11:51 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7N9Blm24098 for ; Thu, 23 Aug 2001 02:11:47 -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 CAA11727 for ; Thu, 23 Aug 2001 02:11:53 -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 DAA26834 for ; Thu, 23 Aug 2001 03:11:48 -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 f7N9BpK22254 for ; Thu, 23 Aug 2001 11:11:51 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu Aug 23 11:11:49 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Thu, 23 Aug 2001 11:11:49 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008C16@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" , Erik.Nordmark@eng.sun.com Subject: RE: [mobile-ip] IPsec, IKE, MIPv6 and concensus Date: Thu, 23 Aug 2001 11:11:41 +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: Jarno, A cople of basic questions below for my understanding. > > > > Someone (I forgot who) pointed out that even this was a problem for > > careful implementations of IPsec. > > The claim (which I understand and agree with) is that > > a TCP connection would like to use the same security policy > > for the lifetime > > of the connection. If you don't then how can you use IPsec to prevent > > a unsecure RST packet from blowing away your connection? > > > > Thus if the packet is piggyback on a TCP SYN packet the peer > > is likely to assume that all of that TCP connection will be secured, > > but that will not be the case since the SYN was only secured > > as a site effect > > of securing the piggy-backed BU. > > > > You mean that the recipient's IPsec implementation is creating new SPD > entries dynamically and implicitly as the side effect of a IPsec envelope > used with the TCP SYN packet? > > If a selector for Mobile IP Next Header is defined, and the SA used for > reception of the packet specifies this selector (in which case it would NOT > contain a selector for TCP), there is no reason for the IPsec implementation > to create any SPD entries for the piggybacked TCP session. > > But there seems to be a related issue: the recipient should be able to check > that the piggybacked TCP packet can indeed get in without IPsec protection. > > Normally, inbound IPsec processing matches also the packets that came with > no IPsec headers against the SPD to determine whether they *should* have > come with IPsec headers. > > If Mobile IP Next Header selector is implemented as Transport Layer Protocol > selector, there is no way that IPsec inbound processing could know to look > for another embedded transport protocol selector (e.g. TCP) to make sure > that the SPD entry for that states "passby". > > However, if a new selector parameter is defined for "in-between" Next > Headers, then both the sender and recipient of any piggybacked transport > protocol could check that the SPD entry matching the transport selector does > not require IPsec processing. > => Could you elaborate a bit on what you mean by "in between" headers ? > The new selector parameter would be needed to be implemented by all CNs > supporting route optimization (as well as the mobile nodes themselves), and > the associated check for the SPD entry for the piggybacked transport message > should be implemented at the same time as the new selector parameter. > > By the RFC2401 only the first matching SPD entry is used for packet's IPsec > processing ("the first matching entry is consistently selected"). This would > need to change in case of "in-between" Next Header selectors and piggybacked > transport protocol messages, where multiple SPD entries need to be selected > and checked by both ends. Is this acceptable? > => Well I don't know about acceptable, the question is more like: how easy is it to change anything in an IPsec RFC ? You or someone else more involved in IPsec can perhaps enlighten us. Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 23 05:25:01 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20918 for ; Thu, 23 Aug 2001 05:25: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 DAA06154; Thu, 23 Aug 2001 03:25:51 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA06784; Thu, 23 Aug 2001 02:25:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7N9Oft24245 for mobile-ip-dist; Thu, 23 Aug 2001 02:24:41 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7N9Obm24238 for ; Thu, 23 Aug 2001 02:24: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 CAA06707 for ; Thu, 23 Aug 2001 02:24:43 -0700 (PDT) From: fritsche@iabg.de Received: from iabgfw.iabg.de (iabgfw.iabg.de [194.139.245.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA01663 for ; Thu, 23 Aug 2001 03:25:01 -0600 (MDT) Received: by iabgfw.iabg.de; id LAA04383; Thu, 23 Aug 2001 11:24:41 +0200 (MET DST) Received: from unknown(10.255.255.2) by iabgfw.iabg.de via smap (V5.5) id xma004375; Thu, 23 Aug 01 11:24:18 +0200 Received: from iabgvw.iabg.de ([10.255.255.8]) by iabgmh.iabg.de (Post.Office MTA v3.5.1 release 219 ID# 127-59214U1600L300S0V35) with ESMTP id de for ; Thu, 23 Aug 2001 11:24:14 +0200 Received: from iabgdns.iabg.de (localhost [127.0.0.1]) by iabgvw.iabg.de (8.8.8+Sun/8.8.8) with ESMTP id LAA28341 for ; Thu, 23 Aug 2001 11:24:09 +0200 (MET DST) Received: from ziegenlippe (ziegenlippe.iabg.de [10.15.0.185]) by iabgdns.iabg.de (8.8.8+Sun/8.8.8) with SMTP id LAA04748 for ; Thu, 23 Aug 2001 11:24:15 +0200 (MET DST) Message-Id: <200108230924.LAA04748@iabgdns.iabg.de> Comments: Authenticated sender is To: mobile-ip@sunroof.eng.sun.com Date: Thu, 23 Aug 2001 11:24:15 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: RE: [mobile-ip] IPsec, IKE, MIPv6 and concensus In-reply-to: <034BEFD03799D411A59F00508BDF754603008C16@esealnt448.al.sw.ericsson.se> X-mailer: Pegasus Mail for Win32 (v2.54DE) Sender: owner-mobile-ip@sunroof.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 > From: "Hesham Soliman (ERA)" > To: "'mobile-ip@sunroof.eng.sun.com'" , > Erik.Nordmark@eng.sun.com > Subject: RE: [mobile-ip] IPsec, IKE, MIPv6 and concensus > Date: Thu, 23 Aug 2001 11:11:41 +0200 > Reply-to: mobile-ip@sunroof.eng.sun.com > Jarno, > > A cople of basic questions below for my understanding. > > > > > > > Someone (I forgot who) pointed out that even this was a problem for > > > careful implementations of IPsec. > > > The claim (which I understand and agree with) is that > > > a TCP connection would like to use the same security policy > > > for the lifetime > > > of the connection. If you don't then how can you use IPsec to prevent > > > a unsecure RST packet from blowing away your connection? > > > > > > Thus if the packet is piggyback on a TCP SYN packet the peer > > > is likely to assume that all of that TCP connection will be secured, > > > but that will not be the case since the SYN was only secured > > > as a site effect > > > of securing the piggy-backed BU. > > > > > > > You mean that the recipient's IPsec implementation is creating new SPD > > entries dynamically and implicitly as the side effect of a IPsec envelope > > used with the TCP SYN packet? > > > > If a selector for Mobile IP Next Header is defined, and the SA used for > > reception of the packet specifies this selector (in which case it would NOT > > contain a selector for TCP), there is no reason for the IPsec implementation > > to create any SPD entries for the piggybacked TCP session. > > > > But there seems to be a related issue: the recipient should be able to check > > that the piggybacked TCP packet can indeed get in without IPsec protection. > > > > Normally, inbound IPsec processing matches also the packets that came with > > no IPsec headers against the SPD to determine whether they *should* have > > come with IPsec headers. > > > > If Mobile IP Next Header selector is implemented as Transport Layer Protocol > > selector, there is no way that IPsec inbound processing could know to look > > for another embedded transport protocol selector (e.g. TCP) to make sure > > that the SPD entry for that states "passby". > > > > However, if a new selector parameter is defined for "in-between" Next > > Headers, then both the sender and recipient of any piggybacked transport > > protocol could check that the SPD entry matching the transport selector does > > not require IPsec processing. > > > => Could you elaborate a bit on what you mean by "in between" > headers ? By "in-between" all IPv6 Next Headers are meant, which are no transport layer header, like Routing Header, Fragment Header or a possible new MIP Header. > > The new selector parameter would be needed to be implemented by all CNs > > supporting route optimization (as well as the mobile nodes themselves), and > > the associated check for the SPD entry for the piggybacked transport message > > should be implemented at the same time as the new selector parameter. > > > > By the RFC2401 only the first matching SPD entry is used for packet's IPsec > > processing ("the first matching entry is consistently selected"). This would > > need to change in case of "in-between" Next Header selectors and piggybacked > > transport protocol messages, where multiple SPD entries need to be selected > > and checked by both ends. Is this acceptable? > > > => Well I don't know about acceptable, the question is > more like: how easy is it to change anything in an IPsec RFC ? > You or someone else more involved in IPsec can perhaps > enlighten us. It's not only the new Next Header, also the processing has to be a little bit modified (see my comment in the previous mail). I wouldn't expect these modifications to be done very easy. > Hesham > > Wolfgang ########################################################## ## Wolfgang Fritsche ## Senior Project Manager ## ## IABG ## Department for Communication Networks ## Einsteinstr. 20 ## 85521 Ottobrunn ## Germany ## ## Phone: +49 89 6088 2897 ## Fax: +49 89 6088 2845 ## E-Mail: fritsche@iabg.de ## Web: www.ipv6.iabg.de, www.iabg.de ########################################################## From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 23 05:46:41 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21102 for ; Thu, 23 Aug 2001 05:46:40 -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 CAA04884; Thu, 23 Aug 2001 02:47: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 CAA04276; Thu, 23 Aug 2001 02:47:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7N9jgn24356 for mobile-ip-dist; Thu, 23 Aug 2001 02:45:42 -0700 (PDT) Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7N9jcm24349 for ; Thu, 23 Aug 2001 02:45:38 -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 f7N9jSN28731; Thu, 23 Aug 2001 11:45:28 +0200 (MET DST) Date: Thu, 23 Aug 2001 11:42:13 +0200 (CEST) From: Erik Nordmark Subject: [mobile-ip] RE: Piggybacking [Was: IPsec, IKE, MIPv6 and concensus ] To: jarno.rajahalme@nokia.com Cc: Erik.Nordmark@eng.sun.com, mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <009CA59D1752DD448E07F8EB2F911757197FE1@esebe004.NOE.Nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > If Mobile IP Next Header selector is implemented as Transport Layer Protocol > selector, there is no way that IPsec inbound processing could know to look > for another embedded transport protocol selector (e.g. TCP) to make sure > that the SPD entry for that states "passby". Yes, and in order to simplify things if we decide to remove piggybacking the BU next header (or whatever it will be called) will be defined as a new transport header from the IPsec perspective (i.e. the same way you'd add SCTP support). > However, if a new selector parameter is defined for "in-between" Next > Headers, then both the sender and recipient of any piggybacked transport > protocol could check that the SPD entry matching the transport selector does > not require IPsec processing. > > The new selector parameter would be needed to be implemented by all CNs > supporting route optimization (as well as the mobile nodes themselves), and > the associated check for the SPD entry for the piggybacked transport message > should be implemented at the same time as the new selector parameter. > > By the RFC2401 only the first matching SPD entry is used for packet's IPsec > processing ("the first matching entry is consistently selected"). This would > need to change in case of "in-between" Next Header selectors and piggybacked > transport protocol messages, where multiple SPD entries need to be selected > and checked by both ends. Is this acceptable? I have no idea how complext such changes would be. For instance, what would happen if the SPD matches for one part of the packet and not the other - would the whole packet be rejected or just the part with a non-matching SPD be ignored? Let's step back and look at what problem we think we are solving with piggybacking: - saving packets and or bytes on the first hop link of the BU - saving packets and/or bytes end-end (since other hops might have low bandwidth) If all we care about is the first then one can envision an IPoverFoo specific method of carrying two IP packets in a single link-layer packet. If we care about solving the second one perhaps we can make this more explicit and simple but providing exactly such a mechanism: an e2e mechanism to send two packets (with the same IPv6 source, dest, tclass, and flowid) as a single packet. This could be done by definition a new extension header called multipacket which would include some number of nexthdr and lengths values. The receive side processing of such an extension header would occur before IPsec (i.e. IPsec header would not be placed before this header) and would result in two separate packets being produced and processed completely independently by the receiver. Thus the IPsec SPD checks would apply to two separate packets just as without piggybacking. So what problems does the multipacket extension header introduce? Well, if it is general then firewalls and other middleboxes migh need to look deeper into the packet. But this isn't much different than skipping the destination options header containing the BU. What diffserv labels(tclass) would apply to the packet? Should we restrict the multipacket extension to only contain one TCP/UDP packet to make such determination easier? [BTW: I think Robert Elz proposed such a mechanism for IPv6 a long time ago - back when IPv6 header formats were painted using charcoal and greese inside caves in Australia, France, and elsewhere.] Erik From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 23 06:41:15 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21608 for ; Thu, 23 Aug 2001 06:41: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 DAA21958; Thu, 23 Aug 2001 03:42:05 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA12484; Thu, 23 Aug 2001 03:41:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7NAer224523 for mobile-ip-dist; Thu, 23 Aug 2001 03:40:53 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7NAenm24516 for ; Thu, 23 Aug 2001 03:40:49 -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 DAA18877 for ; Thu, 23 Aug 2001 03:40:53 -0700 (PDT) Received: from iproxy1.ericsson.dk (iproxy1.ericsson.dk [130.228.248.98]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA03899 for ; Thu, 23 Aug 2001 04:41:11 -0600 (MDT) Received: from unixmail.ted.dk.eu.ericsson.se (knud.ted.dk.eu.ericsson.se [192.66.4.246]) by iproxy1.ericsson.dk (8.10.1/8.10.1) with ESMTP id f7NAeoc26933 for ; Thu, 23 Aug 2001 12:40:50 +0200 (MET DST) Received: from ted.ericsson.dk (petg.ted.dk.eu.ericsson.se [192.66.4.85]) by unixmail.ted.dk.eu.ericsson.se (8.10.1/8.10.1/TEDmain-1.0) with ESMTP id f7NAejL29094; Thu, 23 Aug 2001 12:40:45 +0200 (MEST) Message-ID: <3B84DDAD.918FE9B3@ted.ericsson.dk> Date: Thu, 23 Aug 2001 12:40:45 +0200 From: "Peter Grimstrup (TED)" Organization: Ericsson Telebit A/S X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile IPv6 draft revision 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 From draft-14: 8.5. Sending Binding Acknowledgements and the packet 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 (even if the binding was rejected), as described in Section 8.9. 8.9. Sending Packets to a Mobile Node Before sending any packet, the sending node SHOULD examine its Binding Cache for an entry for the destination address to which the packet is being sent. If the sending node has a Binding Cache entry for this address, the sending node SHOULD use a Routing header I find the 2 sections in conflict. Further sec. 5.2 also says "The packet is sent using a routing header" Comments to De-registration (not touching the questions raised by Francis Dupont recently). The deregistration may be sent from a) the Home Address (any Lifetime) b) the latest Care Of Address (Lifetime = 0) c) another address (Lifetime = 0) First the Binding Cache Entry (BCE) is deleted (see sec. 8.4 and 9.2) then the Binding Acknowledgement (BA) is sent. As mentioned above, the BA must be sent with a routing header, but we have no BCE anymore. In case a) the BA should be sent to the Home Address (in this case a routing header is not really needed, doesn't harm much either). In case b) and c) the BA could reasonably be sent back to the source address of the deregistration, which in case b) is the BCE just deleted. This procedure is very much the same as described in sec. 5.2 when *rejecting* a BU - in this case, however, the BU is not rejected and the acceptance procedure is used. Have I missed something or should this be added/clarified in the draft? Peter From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 23 09:59:23 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23617 for ; Thu, 23 Aug 2001 09:59: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 GAA23217; Thu, 23 Aug 2001 06:59: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 GAA26807; Thu, 23 Aug 2001 06:58:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7NDsHn24915 for mobile-ip-dist; Thu, 23 Aug 2001 06:54:17 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7NDsDm24908 for ; Thu, 23 Aug 2001 06:54:13 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA26262 for ; Thu, 23 Aug 2001 06:54:18 -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 HAA13293 for ; Thu, 23 Aug 2001 07:54:13 -0600 (MDT) Received: by megisto-sql1.megisto.com with Internet Mail Service (5.5.2650.21) id ; Thu, 23 Aug 2001 09:53:23 -0400 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Route Optimization Draft Date: Thu, 23 Aug 2001 09:53:14 -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 Tony, draft-ietf-mobileip-optim-10.txt completed WG Last Call late last year. We've been waiting to forward it for IESG consideration because of the need to get MIPv6 done and the problems with route optimization in that spec. So far there hasn't been a strong push against that stance. Phil > -----Original Message----- > From: Tony lance [mailto:tony_lance_tough@rediffmail.com] > Sent: Thursday, August 16, 2001 6:06 AM > To: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] MN-FA/MN-HA Key Material clarification needed > > > > Hi , > The draft on Route Optimization in Mobile IP > i.e. draft-ietf-mobileip-optim-10.txt was supposed to > expire by 15 May 2001.Can I know,is there any rfc based on > this draft?.Can we consider this draft as a valid one? > > Thank u > > (Tony) > > > > > > > From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 23 10:12:51 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23860 for ; Thu, 23 Aug 2001 10:12: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 HAA29264; Thu, 23 Aug 2001 07:13: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 HAA28396; Thu, 23 Aug 2001 07:11:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7NEAFA24999 for mobile-ip-dist; Thu, 23 Aug 2001 07:10:15 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7NEACm24988 for ; Thu, 23 Aug 2001 07:10:12 -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 HAA04073 for ; Thu, 23 Aug 2001 07:10:15 -0700 (PDT) From: jarno.rajahalme@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 IAA28680 for ; Thu, 23 Aug 2001 08:10:09 -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 f7NEAc302091 for ; Thu, 23 Aug 2001 17:10:38 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 23 Aug 2001 17:10:12 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MSV5SPR>; Thu, 23 Aug 2001 17:10:12 +0300 Message-ID: <009CA59D1752DD448E07F8EB2F911757197FE2@esebe004.NOE.Nokia.com> To: Erik.Nordmark@eng.sun.com Cc: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] IPsec, IKE, MIPv6 and concensus Date: Thu, 23 Aug 2001 17:10:04 +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: Erik wrote: > > > You mean that the recipient's IPsec implementation is > creating new SPD > > entries dynamically and implicitly as the side effect of a > IPsec envelope > > used with the TCP SYN packet? > > I think that is what I'm saying (I've though more in terms of what > the implementation does than how this fits with the SPD concept). > I think an example is that the SPD initially has a matching entry > (e.g. just for TCP + the destination port) allowing IPsec or no IPsec. > But when a new connection is created an SPD entry is created > which matches > just that connection and the entry constrains the policy to be what > was used on the SYN. > > I don't know if such a scheme is discussed in RFC2401 but it > seems useful > since it allows one to build servers where the client can > choose whether > or not it wants to use ipsec i.e. there is less coordination needed. > From my reading it does not seem to be in the 2401, I don't know if it is somewhere else. By 2401 a SPD entry either requires IPsec or not (or tells to drop the matching packet). > > If a selector for Mobile IP Next Header is defined, and the > SA used for > > reception of the packet specifies this selector (in which > case it would NOT > > contain a selector for TCP), there is no reason for the > IPsec implementation > > to create any SPD entries for the piggybacked TCP session. > > So how would you solve the above issue in that case? > If the selector in the SA specifies the Mobile IP Next Header value, the implementation would have to assume that the TCP message arrived without IPsec protection. If the source intended to use IPsec for TCP protection, it would have not piggybacked the two messages in same packet, but separate packets with separate SAs. > > But there seems to be a related issue: the recipient should > be able to check > > that the piggybacked TCP packet can indeed get in without > IPsec protection. > > [...] > > Seems like things are simpler without piggybacking. > Note that all this discussion has been conditional on the assumption of using IPsec for BU protection with a new Next Header value definition for IPsec (either as a transport selector or something new). Now it seems to me that with this assumption, piggybacking can not be used, unless IPsec goes and defines the behavior I described for "in-between" next headers. There still is the case where the BU has it's own, embedded authentication mechanism (non-IPsec). Packets with those could also carry regular transport messages and associated IPsec headers for their protection. In this case I can't see any additional complexity from piggybacking for the recipient. Can we agree on these conclusions? Jarno From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 23 10:29:11 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24260 for ; Thu, 23 Aug 2001 10:29:10 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA17640; Thu, 23 Aug 2001 08:29: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 HAA00803; Thu, 23 Aug 2001 07:29:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7NERjV25076 for mobile-ip-dist; Thu, 23 Aug 2001 07:27:45 -0700 (PDT) Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7NERem25069 for ; Thu, 23 Aug 2001 07:27:41 -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 f7NERcN27009; Thu, 23 Aug 2001 16:27:38 +0200 (MET DST) Date: Thu, 23 Aug 2001 16:24:24 +0200 (CEST) From: Erik Nordmark Subject: RE: [mobile-ip] IPsec, IKE, MIPv6 and concensus To: jarno.rajahalme@nokia.com Cc: Erik.Nordmark@eng.sun.com, mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <009CA59D1752DD448E07F8EB2F911757197FE2@esebe004.NOE.Nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > Note that all this discussion has been conditional on the assumption of > using IPsec for BU protection with a new Next Header value definition for > IPsec (either as a transport selector or something new). Now it seems to me > that with this assumption, piggybacking can not be used, unless IPsec goes > and defines the behavior I described for "in-between" next headers. My issue appears whether the BU remains as a destination option or is in its own extension header. But making it a separate header makes it easier to see these aspects of the interaction with the SPD. > There still is the case where the BU has it's own, embedded authentication > mechanism (non-IPsec). Packets with those could also carry regular transport > messages and associated IPsec headers for their protection. In this case I > can't see any additional complexity from piggybacking for the recipient. Agreed from the perspective of IPsec. (There are still PMTU, ROHC? issues etc with piggybacking.) Erik > Can we agree on these conclusions? > > Jarno From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 23 11:15:36 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25407 for ; Thu, 23 Aug 2001 11:15: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 JAA04069; Thu, 23 Aug 2001 09:16: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 IAA02080; Thu, 23 Aug 2001 08:14:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7NFDqY25253 for mobile-ip-dist; Thu, 23 Aug 2001 08:13:52 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7NFDmm25246 for ; Thu, 23 Aug 2001 08:13: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 IAA13944 for ; Thu, 23 Aug 2001 08:13:52 -0700 (PDT) From: jarno.rajahalme@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA22814 for ; Thu, 23 Aug 2001 08:13:51 -0700 (PDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7NFEC326898 for ; Thu, 23 Aug 2001 18:14:12 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 23 Aug 2001 18:13:46 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MSV54B9>; Thu, 23 Aug 2001 18:13:46 +0300 Message-ID: <009CA59D1752DD448E07F8EB2F911757197FE3@esebe004.NOE.Nokia.com> To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] IPsec, IKE, MIPv6 and concensus Date: Thu, 23 Aug 2001 18:13: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: Erik wrote: > > There still is the case where the BU has it's own, embedded authentication > > mechanism (non-IPsec). Packets with those could also carry regular transport > > messages and associated IPsec headers for their protection. In this case I > > can't see any additional complexity from piggybacking for the recipient. > > Agreed from the perspective of IPsec. > (There are still PMTU, ROHC? issues etc with piggybacking.) > These issues burden the sender choosing to piggyback, not the innocent receiver. Jarno From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 23 11:33:31 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25903 for ; Thu, 23 Aug 2001 11:33:31 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA08618; Thu, 23 Aug 2001 08:34: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 IAA05559; Thu, 23 Aug 2001 08:32:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7NFVgF25343 for mobile-ip-dist; Thu, 23 Aug 2001 08:31:42 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7NFVcm25336 for ; Thu, 23 Aug 2001 08:31: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 IAA00851; Thu, 23 Aug 2001 08:31:42 -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 IAA20316; Thu, 23 Aug 2001 08:31: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 IAA18279; Thu, 23 Aug 2001 08:31:42 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f7NFVfe11859; Thu, 23 Aug 2001 08:31:41 -0700 X-mProtect: Thu, 23 Aug 2001 08:31:41 -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 smtpdgKvjSS; Thu, 23 Aug 2001 08:31:40 PDT Message-ID: <3B8521DC.6E4B198E@iprg.nokia.com> Date: Thu, 23 Aug 2001 08:31:41 -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: Erik.Nordmark@eng.sun.com CC: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Was: IPsec, IKE, MIPv6 and concensus 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 Erik, You wrote: > Let's step back and look at what problem we think we are solving with > piggybacking: > - saving packets and or bytes on the first hop link of the BU > - saving packets and/or bytes end-end (since other hops might have > low bandwidth) > > If all we care about is the first then one can envision an IPoverFoo specific > method of carrying two IP packets in a single link-layer packet. > > If we care about solving the second one perhaps we can make this more > explicit and simple but providing exactly such a mechanism: an e2e mechanism > to send two packets (with the same IPv6 source, dest, tclass, and flowid) > as a single packet. Since both source and destination could often be wireless (or, more abstractly, low-bandwidth) connections, end-to-end is important. If you believe in ad hoc networks, then some intermediate links might also be low-bandwidth. The main purpose is saving packets by not sending Binding Updates unless they are needed, and often they aren't needed until the mobile wants to send data. In cases where the Binding Update was needed and the mobile node knows this but doesn't have any data, then of course the update can be sent. In cases where the mobile node guesses wrong and doesn't send the update even when some correspondent node would find it useful, either the home agent or a smooth handover mechanism can help. For this, I think it is very natural to model the outgoing data stream from the mobile node as requiring occasional redirection for the correspondent node, whenever the mobile node determines that its previous care-of address isn't topologically correct any more. This model leads naturally to including the Binding Update with the data itself, because the route table can be marked with a flag that says when packets need to include a Binding Update. Of course there are other ways to model the necessary signalling, somme of which will resolve some of the current difficulties with IPsec AH. I am in favor of continuing the existing way of including Binding Update with data packets because it is bandwidth-efficient, and there is a natural implementation for it. If IPsec AH did the right thing for our needs, this discussion would never have come up. Furthermore, there are plenty of people who claim that AH was a mistake anyway, independent of Mobile IP. If IPsec AH can be made to do the right thing in the future, we should allow it. But to use IPsec AH problems as the basis for reducing the potential performance of Mobile IPv6 seems wrong to me. I'm reminded of the frequent accusations that IETF doesn't care about wireless. A lot of people do. Other people think it's not worth the effort. I hate to see a valuable tool in our arsenal against performance-loss to be discarded just because current IPsec AH technology (itself frequently denigrated) does not yet provide the exact semantics we need. It would be different if we absolutely had no other solution, but the authentication data suboption for the ...-14 Binding Update does solve the problem, and maybe in a way that is better than using AH. > This could be done by definition a new extension header called > multipacket > which would include some number of nexthdr and lengths values. Agreed that one could define new extension headers, but then I don't see why that is better than what we've already done. The devil is in the details, and who's to say that a year from now we wouldn't still be bogged down in the new details of the devil we didn't know yet? Furthermore, the current Binding Update is a simple upgrade to existing implementations. This should be given due consideration. It seems to me that going forward with what we have, with the appropriate changes as have been noted over the last few weeks, is a minimum energy and yet very effective solution. I think that is a lot better than assigning a heavy weighting factor towards satisfying IPsec AH constraints which seem to be themselves evolving and undergoing clarifications. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 23 12:08:06 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26541 for ; Thu, 23 Aug 2001 12:08:05 -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 JAA25940; Thu, 23 Aug 2001 09: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 JAA11571; Thu, 23 Aug 2001 09:07:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7NG6SW25496 for mobile-ip-dist; Thu, 23 Aug 2001 09:06:28 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7NG6Om25489 for ; Thu, 23 Aug 2001 09:06:24 -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 JAA11405; Thu, 23 Aug 2001 09:06:28 -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 KAA24898; Thu, 23 Aug 2001 10:06:24 -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 f7NG6jT10302; Thu, 23 Aug 2001 09:06:45 -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 AAE26921; Thu, 23 Aug 2001 09:06:25 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA20169; Thu, 23 Aug 2001 09:06:25 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15237.10753.575932.213862@thomasm-u1.cisco.com> Date: Thu, 23 Aug 2001 09:06:25 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Cc: jarno.rajahalme@nokia.com, Erik.Nordmark@eng.sun.com Subject: [mobile-ip] RE: Piggybacking [Was: IPsec, IKE, MIPv6 and concensus ] In-Reply-To: References: <009CA59D1752DD448E07F8EB2F911757197FE1@esebe004.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 Erik Nordmark writes: > I have no idea how complext such changes would be. > For instance, what would happen if the SPD matches for one part of the > packet and not the other - would the whole packet be rejected or > just the part with a non-matching SPD be ignored? > > Let's step back and look at what problem we think we are solving with > piggybacking: > - saving packets and or bytes on the first hop link of the BU > - saving packets and/or bytes end-end (since other hops might have > low bandwidth) > > If all we care about is the first then one can envision an IPoverFoo specific > method of carrying two IP packets in a single link-layer packet. > > If we care about solving the second one perhaps we can make this more > explicit and simple but providing exactly such a mechanism: an e2e mechanism > to send two packets (with the same IPv6 source, dest, tclass, and flowid) > as a single packet. Note that links with low bandwidth are fairly likely to want to use CRTP/ROHC themselves, so the actual cost of the IP6 header should be close to nil since it is almost completely compressible. This has the nice property that hops that care, can choose. Hops that don't don't. Also, you're proposal for layer two blocking applies equally well for intermediate/far end as well. Indeed, the way that DOCSIS modems work with concatenation (ie L2 blocking), having serveral packets in the queue at the same time is all that is required to cause the modem to ask for a larger transmission slot. This is a *much* larger win than any particular L4+ packet piggybacking on another L3 packet, and is *far* less complex. > What diffserv labels(tclass) would apply to the packet? > Should we restrict the multipacket extension to only contain one TCP/UDP > packet to make such determination easier? Right, and the same goes for intserv flows. Worse is that when you have an L2 CBR QoS class on a shared media, all of the schemes I know of rely on some sort of TDM like multiplexing where you get a fixed slot sized allocation to send your data ever so many milliseconds. Variations on this theme abound but they all rely on the property that you minimize your slots to the minimum so as to not waste lots of bandwidth. In this case (and I think it's very pertinent to wireless -- a shared media), piggybacking is either a non-starter, or detrimental if you decide to carve out slots big enough to carry the occassional BU. Mike From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 23 12:57:37 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27261 for ; Thu, 23 Aug 2001 12:57: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 KAA13645; Thu, 23 Aug 2001 10:58:15 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA17613; Thu, 23 Aug 2001 09:57:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7NGuPh25617 for mobile-ip-dist; Thu, 23 Aug 2001 09:56:25 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7NGuMm25610 for ; Thu, 23 Aug 2001 09:56: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 JAA01781 for ; Thu, 23 Aug 2001 09:56:00 -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 JAA26735 for ; Thu, 23 Aug 2001 09:55:59 -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 f7NGuAn23574 for ; Thu, 23 Aug 2001 09:56:10 -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 AAF00265; Thu, 23 Aug 2001 09:55:52 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA20183; Thu, 23 Aug 2001 09:55:51 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15237.13719.597107.863809@thomasm-u1.cisco.com> Date: Thu, 23 Aug 2001 09:55:51 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] IPsec, IKE, MIPv6 and concensus In-Reply-To: <009CA59D1752DD448E07F8EB2F911757197FE0@esebe004.NOE.Nokia.com> References: <009CA59D1752DD448E07F8EB2F911757197FE0@esebe004.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 jarno.rajahalme@nokia.com writes: > Hesham wrote: > > > > > > Sure this is a performance optimization only, and the > > degree of the benefit > > > depends heavily on the type of L2's in both ends, feature > > interaction with > > > HC, etc., but if done right there is nothing that would > > make the standard > > > "only work sometimes". It is quite customary that standards > > have options > > > that are not always used. > > > > > => The question is whether this complexity you mention above > > (L2 interaction, HC implications, Path MTU ....etc) are worth > > the hassles. There is no foreseen benefit really if you're > > using ROHC for example. Do you think the perceived gain > > actually outweighs the processing headache ? > > If it does then what you're suggesting would make a lot of sense. > > > > All that complexity of figuring out when it is worthwhile and possible to > piggyback lies on the engineer implementing piggybacking. If you rather not > bother, then do not piggyback. There is no added complexity for the > recipient. That's not completely true: if there is a requirement that *all* receivers accept piggybacking, then they share the burden. > Seriously, you should piggyback only if you think it's worth the effort. I think we have an inversion of priorities going on here (and throughout the rest of the IETF, for that matter). The question should not be framed as if it's not a big deal, throw it in, it should be framed as why do we absolutely, positively _have_ to have this feature. The net is getting far too complicated, and the law of unintended consequences brought to the fore far too often. It's already been shown that there's a great deal of possibility for unintended consequences with piggybacking -- consequences I'll add which are quite possible regardless of whether IPsec is used or not. Unless somebody can show some concrete wins which cannot be achieved in any other way than L3 piggybacking, we should be prudent and defer that discussion for another day when we know more. Mike From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 23 12:57:51 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27280 for ; Thu, 23 Aug 2001 12:57:50 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA13620; Thu, 23 Aug 2001 10:58: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 JAA17610; Thu, 23 Aug 2001 09:57:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7NGuTf25626 for mobile-ip-dist; Thu, 23 Aug 2001 09:56:29 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7NGuQm25619 for ; Thu, 23 Aug 2001 09:56:26 -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 JAA01878 for ; Thu, 23 Aug 2001 09:56:31 -0700 (PDT) From: jarno.rajahalme@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA27144 for ; Thu, 23 Aug 2001 09:56:29 -0700 (PDT) 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 f7NGuq322498 for ; Thu, 23 Aug 2001 19:56:52 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 23 Aug 2001 19:56:26 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MSV5VLQ>; Thu, 23 Aug 2001 19:56:25 +0300 Message-ID: <009CA59D1752DD448E07F8EB2F911757197FE4@esebe004.NOE.Nokia.com> To: mat@cisco.com, mobile-ip@sunroof.eng.sun.com Cc: Erik.Nordmark@eng.sun.com Subject: RE: [mobile-ip] RE: Piggybacking [Was: IPsec, IKE, MIPv6 and conc ensus ] Date: Thu, 23 Aug 2001 19:56:19 +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: Michael Thomas wrote: > Note that links with low bandwidth are fairly > likely to want to use CRTP/ROHC themselves, so the > actual cost of the IP6 header should be close to > nil since it is almost completely compressible. Only if the IPv6 header is part of a flow. For occasional signaling messages there is likely to be no header compression at all. Anyway, I'd like we have a conclusive end to the piggybacking discussion. So far we know that with IPsec protection of BUs piggybacking is likely not possible because of SPD lookup issues at recipients. If the BU specific security solution is adopted, there seems to be no harm from the piggybacking at the recipient. This issue is likely not a determining factor for choosing the BU security solution. Anyway, when we have a solution for the BU protection, the implications for piggybacking should be documented. Jarno From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 23 13:02:47 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27351 for ; Thu, 23 Aug 2001 13:02:46 -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 LAA18676; Thu, 23 Aug 2001 11:03: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 KAA18923; Thu, 23 Aug 2001 10:02:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7NH22b25707 for mobile-ip-dist; Thu, 23 Aug 2001 10:02:02 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7NH1xm25700 for ; Thu, 23 Aug 2001 10:01: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 KAA18724 for ; Thu, 23 Aug 2001 10:02:04 -0700 (PDT) From: jarno.rajahalme@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA12936 for ; Thu, 23 Aug 2001 10:01:58 -0700 (PDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7NH2N323677 for ; Thu, 23 Aug 2001 20:02:23 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 23 Aug 2001 20:01:55 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MSV5VM7>; Thu, 23 Aug 2001 20:01:55 +0300 Message-ID: <009CA59D1752DD448E07F8EB2F911757197FE5@esebe004.NOE.Nokia.com> To: Erik.Nordmark@eng.sun.com Cc: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] RE: Piggybacking [Was: IPsec, IKE, MIPv6 and concensus ] Date: Thu, 23 Aug 2001 20:01:53 +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: Erik, I have wanted to find out if piggybacking transport messages with Mobile BUs is possible with no cost to the recipient. If any standardization activity (other than some very easy stuff with Mobile IPv6 itself) would be needed to allow piggybacking, let's just forget about it. Jarno > -----Original Message----- > From: ext Erik Nordmark [mailto:Erik.Nordmark@eng.sun.com] > Sent: 23. elokuuta 2001 12:42 > To: Rajahalme Jarno (NRC/Helsinki) > Cc: Erik.Nordmark@eng.sun.com; mobile-ip@sunroof.eng.sun.com > Subject: RE: Piggybacking [Was: IPsec, IKE, MIPv6 and concensus ] > > > > > If Mobile IP Next Header selector is implemented as > Transport Layer Protocol > > selector, there is no way that IPsec inbound processing > could know to look > > for another embedded transport protocol selector (e.g. TCP) > to make sure > > that the SPD entry for that states "passby". > > Yes, and in order to simplify things if we decide to remove > piggybacking > the BU next header (or whatever it will be called) will be defined > as a new transport header from the IPsec perspective (i.e. > the same way you'd add SCTP support). > > > However, if a new selector parameter is defined for > "in-between" Next > > Headers, then both the sender and recipient of any > piggybacked transport > > protocol could check that the SPD entry matching the > transport selector does > > not require IPsec processing. > > > > The new selector parameter would be needed to be > implemented by all CNs > > supporting route optimization (as well as the mobile nodes > themselves), and > > the associated check for the SPD entry for the piggybacked > transport message > > should be implemented at the same time as the new selector > parameter. > > > > By the RFC2401 only the first matching SPD entry is used > for packet's IPsec > > processing ("the first matching entry is consistently > selected"). This would > > need to change in case of "in-between" Next Header > selectors and piggybacked > > transport protocol messages, where multiple SPD entries > need to be selected > > and checked by both ends. Is this acceptable? > > I have no idea how complext such changes would be. > For instance, what would happen if the SPD matches for one part of the > packet and not the other - would the whole packet be rejected or > just the part with a non-matching SPD be ignored? > > Let's step back and look at what problem we think we are solving with > piggybacking: > - saving packets and or bytes on the first hop link of the BU > - saving packets and/or bytes end-end (since other hops might have > low bandwidth) > > If all we care about is the first then one can envision an > IPoverFoo specific > method of carrying two IP packets in a single link-layer packet. > > If we care about solving the second one perhaps we can make this more > explicit and simple but providing exactly such a mechanism: > an e2e mechanism > to send two packets (with the same IPv6 source, dest, tclass, > and flowid) > as a single packet. > > This could be done by definition a new extension header called > multipacket > which would include some number of nexthdr and lengths values. > > The receive side processing of such an extension header would > occur before > IPsec (i.e. IPsec header would not be placed before this header) and > would result in two separate packets being produced and > processed completely > independently by the receiver. > > Thus the IPsec SPD checks would apply to two separate packets > just as without > piggybacking. > > So what problems does the multipacket extension header introduce? > Well, if it is general then firewalls and other middleboxes > migh need to > look deeper into the packet. But this isn't much different > than skipping the > destination options header containing the BU. > > What diffserv labels(tclass) would apply to the packet? > Should we restrict the multipacket extension to only contain > one TCP/UDP > packet to make such determination easier? > > [BTW: I think Robert Elz proposed such a mechanism for IPv6 a > long time ago - > back when IPv6 header formats were painted using charcoal and > greese inside > caves in Australia, France, and elsewhere.] > > Erik > From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 23 13:25:11 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27635 for ; Thu, 23 Aug 2001 13:25:10 -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 LAA08137; Thu, 23 Aug 2001 11:24:53 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA24247; Thu, 23 Aug 2001 10:24:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7NHN5W25833 for mobile-ip-dist; Thu, 23 Aug 2001 10:23:05 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7NHN1m25826 for ; Thu, 23 Aug 2001 10:23: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 KAA08594 for ; Thu, 23 Aug 2001 10:23:03 -0700 (PDT) From: jarno.rajahalme@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 LAA06238 for ; Thu, 23 Aug 2001 11:22:57 -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 f7NHNP328247 for ; Thu, 23 Aug 2001 20:23:26 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 23 Aug 2001 20:23:00 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MSV5VSL>; Thu, 23 Aug 2001 20:22:11 +0300 Message-ID: <009CA59D1752DD448E07F8EB2F911757197FE6@esebe004.NOE.Nokia.com> To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] IPsec, IKE, MIPv6 and concensus Date: Thu, 23 Aug 2001 20:22:05 +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: Michael, As long as Mobile IPv6 is implemented in the L3 (IP option) headers, there is nothing extra receivers need to do to *accept* piggybacking, it just falls out naturally. Actually, you need more text in the spec to disallow piggybacking. And if this is done, why to keep Mobile IPv6 at L3? (Kernel/user space considerations should be out of scope for IETF) It seems that IF IPsec is used to protect the BU, BU would really need to be implemented as a transport protocol, or on top of some existing transport protocol. In this case piggybacking would indeed require some additional support (ref. Erik's recent mail), which I do not support. On the other hand, if the mechanism in draft -14 is used for BU protection, piggybacking falls out naturally again. Actually the discussion should be about BU piggybacking in the e.g. TCP packet, not the other way around. This way it is easy to see that DSCP, flow label, etc. should NOT be changed by inclusion of the BU. If the BU needs some specific diffserv treatment, then it should be sent out by itself. Jarno > -----Original Message----- > From: ext Michael Thomas [mailto:mat@cisco.com] > Sent: 23. elokuuta 2001 19:56 > To: mobile-ip@sunroof.eng.sun.com > Subject: RE: [mobile-ip] IPsec, IKE, MIPv6 and concensus > > > jarno.rajahalme@nokia.com writes: > > Hesham wrote: > > > > > > > > Sure this is a performance optimization only, and the > > > degree of the benefit > > > > depends heavily on the type of L2's in both ends, feature > > > interaction with > > > > HC, etc., but if done right there is nothing that would > > > make the standard > > > > "only work sometimes". It is quite customary that standards > > > have options > > > > that are not always used. > > > > > > > => The question is whether this complexity you mention above > > > (L2 interaction, HC implications, Path MTU ....etc) are worth > > > the hassles. There is no foreseen benefit really if you're > > > using ROHC for example. Do you think the perceived gain > > > actually outweighs the processing headache ? > > > If it does then what you're suggesting would make a lot > of sense. > > > > > > > All that complexity of figuring out when it is worthwhile > and possible to > > piggyback lies on the engineer implementing piggybacking. > If you rather not > > bother, then do not piggyback. There is no added complexity for the > > recipient. > > That's not completely true: if there is a requirement > that *all* receivers accept piggybacking, then they > share the burden. > > > Seriously, you should piggyback only if you think it's > worth the effort. > > I think we have an inversion of priorities going on > here (and throughout the rest of the IETF, for that > matter). The question should not be framed as > if it's not a big deal, throw it in, it should > be framed as why do we absolutely, positively > _have_ to have this feature. The net is getting > far too complicated, and the law of unintended > consequences brought to the fore far too often. > > It's already been shown that there's a great > deal of possibility for unintended consequences > with piggybacking -- consequences I'll add > which are quite possible regardless of whether > IPsec is used or not. Unless somebody can show > some concrete wins which cannot be achieved in > any other way than L3 piggybacking, we should > be prudent and defer that discussion for > another day when we know more. > > Mike > From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 23 13:25:58 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27672 for ; Thu, 23 Aug 2001 13:25: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 LAA09906; Thu, 23 Aug 2001 11:26: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 KAA24799; Thu, 23 Aug 2001 10:26:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7NHOl725851 for mobile-ip-dist; Thu, 23 Aug 2001 10:24:47 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7NHOim25844 for ; Thu, 23 Aug 2001 10:24:44 -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 KAA10955 for ; Thu, 23 Aug 2001 10:24: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 KAA26694 for ; Thu, 23 Aug 2001 10:24: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 KAA26606 for ; Thu, 23 Aug 2001 10:24:48 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f7NHOmZ05993 for ; Thu, 23 Aug 2001 10:24:48 -0700 X-mProtect: Thu, 23 Aug 2001 10:24: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 smtpdexvflU; Thu, 23 Aug 2001 10:24:46 PDT Message-ID: <3B853C5E.191C4C6A@iprg.nokia.com> Date: Thu, 23 Aug 2001 10:24: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: [mobile-ip] PMTU, ROHC and piggybacking (was IPsec, IKE, MIPv6 and concensus) 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, Erik Nordmark wrote: > Agreed from the perspective of IPsec. > (There are still PMTU, ROHC? issues etc with piggybacking.) whats are the PMTU issues? you check the data packet. if you can add the BU option to the packet without exceeding the PMTU, you piggyback. otherwise you dont. you send the BU as a separate packet. only the sender has to do this check. its not an issue for ROHC either, we have an implementation here. when ROHC comes across a packet bigger than what it is supposed to be, it skips compressing this particular packet. and this packet is received in the clear. we do exactly this. we have run tests with a simple RTP application. the typical packet in the data stream (that is being compressed in our experiment) is (IPv6 header + home address option + UDP header + RTP header + payload). if a packet received by the compression engine is bigger than this, we skip compression on this packet. i dont know whats the big deal. it works. somebody please correct me if i am wrong. Vijay > > Erik > > > Can we agree on these conclusions? > > > > Jarno From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 23 16:36:13 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01139 for ; Thu, 23 Aug 2001 16:36: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 OAA04266; Thu, 23 Aug 2001 14:36: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 NAA14995; Thu, 23 Aug 2001 13:36:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7NKZJ826222 for mobile-ip-dist; Thu, 23 Aug 2001 13:35:19 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7NKZFm26215 for ; Thu, 23 Aug 2001 13:35:16 -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 NAA22916 for ; Thu, 23 Aug 2001 13:35: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 OAA27762 for ; Thu, 23 Aug 2001 14:35:37 -0600 (MDT) Received: by megisto-sql1.megisto.com with Internet Mail Service (5.5.2650.21) id ; Thu, 23 Aug 2001 16:34:17 -0400 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] FW: draft-ietf-mobileip-mier-07.txt Date: Thu, 23 Aug 2001 16:34: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: Hi folks, we've received this feedback from the IESG on the MIER draft. Please provide comments, especially on the first set of options. Phil -------------------- General comment. This ID seems to be of rather limited usefulness as a standalone RFC. Is it really needed? This document seems to update RFC 2002, but is informational. This can be remedied by: - making this standards track (seems overkill, since it doesn't actually define an option, and hence, doesn't define anything anyone needs to implement, from what I can tell) - merge it in with 2002bis (which is being revised right now anyway) - merge this document with GNAI, since the GNAI document is a specific case where use of MIER might make sense. - take out the MUST/SHOULDs and make it clear that this document is only proposing an approach to encoding options, and that future options writers should consider the issues raised when designing their options. NOte: if this approach is used, other documents (e.g., draft-ietf-mobileip-gnaie-04.txt) shouldn't have normative references to this document. At present, gnai appears to do just that. For example: > MIER describes a new extension > structure to Mobile IP to make the extensions far more > extensible. Could be rewritten as: MIER describes a way of encoding extensions that make it possible to conserve MIP options in some cases. Authors of future options should consider the issues raised in this document when designing new options. There are several other places in the document where the langauge could be toned down and made more neutral. > 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 There is an alternate approach, one that seems to be working in practice, and has other benefits. Don't allow IANA to assign options until there is significant support for an option, i.e, via something like "IETF consensus" [RFC 2434]. This approach also has the advantage that it discourages the use of many options anyway, a generaly desirable feature. Usage of many options tends to negatively impact interoperability. Finally, looking at the IANA pages, it does not appear that options are being used at a significant rate and that exhaustion of the space is serious issue at present. > 1.0 Introduction > > The type field in the Mobile IP extension structure can support > upto 255 (skippable and not skippable) uniquely identifiable > extensions. With new developments/additions to Mobile IP > there is a strong possibility that the available space will > run out. What evidence is there that this is true at present? > Mobile IP Extensions Rationalization (MIER) describes a > new extension structure to solve this problem. MIER strategy > is to initially aggregate certain types of extensions (e.g, > NAI) and sub types to identify the precise extension (example > MN/User NAI, HA NAI etc). This will greatly reduce the usage > of the type field. Last sentence seems a bit too strong. Better to say "This may reduce the usage of the type field in some cases". > 2.2 New Mobile IP Extension format > > This draft proposes the following two structures for Mobile IP > extensions to be carried in the Mobile IP control messages. > Since the new extension structures will cause an efficient > usage of the extension type space, it is strongly recommended > that all the new proposals for the Mobile IP WG that have new > extensions SHOULD follow this format. SHOULD wording seems a bit strong. Encoding options in this way makes sense in *some* cases, but it is not clear (to me) that it does so in even the majority of cases. It would be sufficient to say option writers should consider whether the structure defined here makes sense when a new option is defined. Saying they SHOULD follow it is too strong. > 2.2.1 Long Extension Format In the absence of a specific proposed need for a long option, I don't see the value in defining it. Moreover, will MIP *ever* define any more non-skippable options? Seems like doing so would be bad for interoperating with the installed base (which won't understand any newly defined options) . If that is the case, why define now? One can always define a long format later should it be deemed necessary. > 2.2.2 Short Extension Format This format makes sense for some types of options (GNAI would seem to be one). It does not make sense for others. For example, of the existing MIP options, how many would it actually make sense to encode in this fashion? > Sub-Type is a unique number given to each member in the > aggregated type. Sub-Type values between of 200 through > 255 are reserved for future use and standardization. The semantics of this field are dependent on the actual option; it make no sense to say anything about reserving values in the general case. It *might* make sense to say something like that in the case of a specific option, but that would be the job of that specific option. If this document is to be published as a standalone document: Needs security considerations section. Would be good to have an IANA considerations section; I would expect it to say "There are no IANA Actions in this document", but that sort of depends on resolution of the first point. From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 23 20:32:26 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04390 for ; Thu, 23 Aug 2001 20:32: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 RAA29462; Thu, 23 Aug 2001 17:33: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 RAA13921; Thu, 23 Aug 2001 17:32:45 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19) with ESMTP id f7O0Ve1O026732 for ; Thu, 23 Aug 2001 17:31:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19/Submit) id f7O0Vebn026731 for mobile-ip-dist; Thu, 23 Aug 2001 17:31: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 jurassic.eng.sun.com (jurassic [129.146.85.31] (may be forged)) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19) with ESMTP id f7O0Vb1O026724 for ; Thu, 23 Aug 2001 17:31:37 -0700 (PDT) Received: from istanbul.Eng.Sun.COM (istanbul.Eng.Sun.COM [129.146.86.247]) by jurassic.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19) with SMTP id f7O0VZS8652749; Thu, 23 Aug 2001 17:31:35 -0700 (PDT) Message-Id: <200108240031.f7O0VZS8652749@jurassic.eng.sun.com> Date: Thu, 23 Aug 2001 17:31:42 -0700 (PDT) From: Alper Yegin Subject: Re: [mobile-ip] Mobile IPv6 draft revision To: charliep@iprg.nokia.com, mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: MULTIPART/mixed; BOUNDARY=Flink_of_Cows_791_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: --Flink_of_Cows_791_000 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 1vYK10hEwFf0jt3HBO0V/w== Charlie, I assume the "Connectathon 2001 feedback on the Mobile IPv6 draft" will also be incorporated into this upcoming version. Right? I attached the original e-mail that details the issues which were both presented at IETF 50 and sent on the mailing list before. Regards, alper > Hello folks, > > Following the recent discussion, I believe a new revision to the > existing Mobile IPv6 draft ...-14 is needed. The new draft would > have the following features: > > - Removal of all text related to Mobile Routers, including the > 'R' bit of the Binding Update > > - Reorganizing the Binding Update format so that: > = authentication data is able to be included as a suboption > = Specify that the Binding Update needs a new header number > = Specify that the Binding Update must follow AH whenever > AH is present. > This will allow use of AH in the future, but allow the use > of other authentication algorithms which can be specified > directly to depend on specialized key exchange protocols > as has been discussed recently. > > - other minor fixes that have been reported. > > I believe these fixes conform to recent consensus, do not > represent a significant upheaval to existing implementations, > and may help to make future discussion more productive. > > Comments? > > Regards, > Charlie P. alper --Flink_of_Cows_791_000 Content-Type: MESSAGE/rfc822; name=Mailbox Content-Description: Mailbox Date: Thu, 23 Aug 2001 17:29:58 -0700 (PDT) From: Postmaster Subject: Message from mail server Content-Length: 96 Mime-Version: 1.0 Status: RO X-IMAP: 998612997 1 Delete. This is a system message. --END+PSEUDO-- From Alper.Yegin@eng.sun.com Mon Jul 16 18:05:22 2001 X-Unix-From: Alper.Yegin@eng.sun.com Mon Jul 16 18:05:22 2001 Received: from engmail3.Eng.Sun.COM (engmail3.Eng.Sun.COM [129.144.170.5]) by jurassic.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6H15Mb895428; Mon, 16 Jul 2001 18:05:22 -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 SAA03333; Mon, 16 Jul 2001 18:05:12 -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: Status: RO X-Status: $$$$ X-UID: 0000000001 --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-- --Flink_of_Cows_791_000-- From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 23 20:55:11 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04622 for ; Thu, 23 Aug 2001 20:55: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 RAA06310; Thu, 23 Aug 2001 17:55: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 RAA17355; Thu, 23 Aug 2001 17:55:47 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19) with ESMTP id f7O0si1O026843 for ; Thu, 23 Aug 2001 17:54:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19/Submit) id f7O0si5u026842 for mobile-ip-dist; Thu, 23 Aug 2001 17:54: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.Beta19+Sun/8.12.0.Beta19) with ESMTP id f7O0sf1O026835 for ; Thu, 23 Aug 2001 17:54: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 RAA00643 for ; Thu, 23 Aug 2001 17:54:42 -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 SAA23456 for ; Thu, 23 Aug 2001 18:55: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 RAA27299 for ; Thu, 23 Aug 2001 17:54:41 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f7O0seD12944 for ; Thu, 23 Aug 2001 17:54:40 -0700 X-mProtect: Thu, 23 Aug 2001 17:54:40 -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 smtpdxWgCBw; Thu, 23 Aug 2001 17:54:37 PDT Message-ID: <3B85A584.1AC9AE96@iprg.nokia.com> Date: Thu, 23 Aug 2001 17:53:24 -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] Mobile IPv6 draft revision References: <200108240031.f7O0VZS8652749@jurassic.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Alper, Yes, and thank you very much for the reminder! Regards, Charlie P. Alper Yegin wrote: > Charlie, > > I assume the "Connectathon 2001 feedback on the Mobile IPv6 draft" will also be > incorporated into this upcoming version. Right? I attached the original e-mail > that details the issues which were both presented at IETF 50 and sent on the > mailing list before. > > Regards, > > alper > > > Hello folks, > > > > Following the recent discussion, I believe a new revision to the > > existing Mobile IPv6 draft ...-14 is needed. The new draft would > > have the following features: > > > > - Removal of all text related to Mobile Routers, including the > > 'R' bit of the Binding Update > > > > - Reorganizing the Binding Update format so that: > > = authentication data is able to be included as a suboption > > = Specify that the Binding Update needs a new header number > > = Specify that the Binding Update must follow AH whenever > > AH is present. > > This will allow use of AH in the future, but allow the use > > of other authentication algorithms which can be specified > > directly to depend on specialized key exchange protocols > > as has been discussed recently. > > > > - other minor fixes that have been reported. > > > > I believe these fixes conform to recent consensus, do not > > represent a significant upheaval to existing implementations, > > and may help to make future discussion more productive. > > > > Comments? > > > > Regards, > > Charlie P. > > alper > > ------------------------------------------------------------------------ > > Subject: Message from mail server > Date: Thu, 23 Aug 2001 17:29:58 -0700 (PDT) > From: Postmaster > > Delete. > This is a system message. > > --END+PSEUDO-- > > >From Alper.Yegin@eng.sun.com Mon Jul 16 18:05:22 2001 > X-Unix-From: Alper.Yegin@eng.sun.com Mon Jul 16 18:05:22 2001 > Received: from engmail3.Eng.Sun.COM (engmail3.Eng.Sun.COM [129.144.170.5]) > by jurassic.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6H15Mb895428; > Mon, 16 Jul 2001 18:05:22 -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 SAA03333; > Mon, 16 Jul 2001 18:05:12 -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: > Status: RO > X-Status: $$$$ > X-UID: 0000000001 > > --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 Fri Aug 24 06:02:15 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27869 for ; Fri, 24 Aug 2001 06:02: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 DAA22300; Fri, 24 Aug 2001 03:03:00 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA06588; Fri, 24 Aug 2001 03:02:45 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19) with ESMTP id f7OA1k1O027480 for ; Fri, 24 Aug 2001 03:01:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19/Submit) id f7OA1jtk027479 for mobile-ip-dist; Fri, 24 Aug 2001 03:01: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.Beta19+Sun/8.12.0.Beta19) with ESMTP id f7OA1f1O027472 for ; Fri, 24 Aug 2001 03:01: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 DAA00427 for ; Fri, 24 Aug 2001 03:01:45 -0700 (PDT) Received: from tml-gw.tml.hut.fi (tml.hut.fi [130.233.44.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA13587 for ; Fri, 24 Aug 2001 04:02:04 -0600 (MDT) Received: (from smap@localhost) by tml-gw.tml.hut.fi (8.8.7/8.8.7) id NAA32387 for ; Fri, 24 Aug 2001 13:01:31 +0300 Received: from mail.tml.hut.fi(130.233.45.70) by tml-gw.tml.hut.fi via smap (V2.0) id xma032385; Fri, 24 Aug 01 13:01:23 +0300 Received: from caffeine.tml.hut.fi (caffeine.tml.hut.fi [130.233.45.27]) by mail.tml.hut.fi (8.11.0/8.11.0) with ESMTP id f7OA05902038 for ; Fri, 24 Aug 2001 13:00:05 +0300 (EEST) Received: from localhost (lpetande@localhost) by caffeine.tml.hut.fi (8.9.3+Sun/8.9.3) with ESMTP id NAA07253 for ; Fri, 24 Aug 2001 13:01:34 +0300 (EEST) X-Authentication-Warning: caffeine.tml.hut.fi: lpetande owned process doing -bs Date: Fri, 24 Aug 2001 13:01:34 +0300 (EEST) From: Henrik Petander To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] processing of the home address option 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 sent email about the same subject to the list some weeks ago, but I guess it got lost in the mail storm which took place right before the IETF meeting. Section 8.1 in MIPv6 draft 14 specifies that the home address option should be processed only after all the other options in the same destination option header are processed. In practice, this requirement makes the receiver keep state between different options. I wonder, whether the requirement is really worth the extra complexity it creates in all IPv6 nodes. If the ordering is required, it would IMHO be better to make the ordering the responsibility of MN, which adds the options, i.e. "The home address option MUST be added as the last destination option to the destination option header ...". This would simplify the CN and would increase the complexity of MN only marginally. Regards, Henrik Petander ---------------------------------- Henrik Petander Helsinki University of Technology, GO/Core Project Henrik.Petander@hut.fi Office: +358 (0)9 451 5846 GSM: +358 (0)40 741 5248 ---------------------------------- From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 24 09:40:34 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04882 for ; Fri, 24 Aug 2001 09:40: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 GAA28723; Fri, 24 Aug 2001 06:41: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 GAA20053; Fri, 24 Aug 2001 06:41:11 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19) with ESMTP id f7ODde1O027821 for ; Fri, 24 Aug 2001 06:39:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19/Submit) id f7ODdeQ0027820 for mobile-ip-dist; Fri, 24 Aug 2001 06:39:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19) with ESMTP id f7ODda1O027813 for ; Fri, 24 Aug 2001 06:39:36 -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 GAA18266 for ; Fri, 24 Aug 2001 06:39:42 -0700 (PDT) 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 GAA09038 for ; Fri, 24 Aug 2001 06:39: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 f7ODdji08197 for ; Fri, 24 Aug 2001 08:39:45 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 24 Aug 2001 08:39:39 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 24 Aug 2001 08:39:39 -0500 content-class: urn:content-classes:message Subject: [mobile-ip] RE: NAT Traversal Scenarios for Mobile IP Date: Fri, 24 Aug 2001 08:39:39 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF441E84BB@daebe007.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Thread-Topic: NAT Traversal Scenarios for Mobile IP Thread-Index: AcEsnp32MyEmjpiQEdWxLgAIx6TWeAAAzs0Q From: "Patil Basavaraj (NET/Dallas)" To: "'Mobile IP'" X-OriginalArrivalTime: 24 Aug 2001 13:39:39.0825 (UTC) FILETIME=[3926C210:01C12CA2] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f7ODdb1O027814 Sender: owner-mobile-ip@sunroof.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, Following the discussions at the last IETF on the topic of support for NATs and VPNs in Mobile IP4v a new mailing list has been setup (Thanks to Henrik): If you are interested in participating in this discussion please sign up to this list. 'mobileip-nat-vpn@ipunplugged.com'. To subscribe, you send a mail with 'subscribe' in the subject line or in the message body, to 'mobileip-nat-vpn-request@ipunplugged.com': mailto:mobileip-nat-vpn-request@ipunplugged.com?subject=subscribe From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 24 10:43:07 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06096 for ; Fri, 24 Aug 2001 10:43:06 -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 HAA27830; Fri, 24 Aug 2001 07:43: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 HAA11751; Fri, 24 Aug 2001 07:43:28 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19) with ESMTP id f7OEgI1O027976 for ; Fri, 24 Aug 2001 07:42:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19/Submit) id f7OEgIBa027975 for mobile-ip-dist; Fri, 24 Aug 2001 07:42: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 eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19) with ESMTP id f7OEgF1O027968 for ; Fri, 24 Aug 2001 07:42:16 -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 KAA27644 for ; Fri, 24 Aug 2001 10:42:19 -0400 (EDT) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id KAA03605 for mobile-ip@sunroof.eng.sun.com; Fri, 24 Aug 2001 10:42:47 -0400 (EDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19) with ESMTP id f7O2CI1O027022 for ; Thu, 23 Aug 2001 19:12:18 -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 TAA24652 for ; Thu, 23 Aug 2001 19:12:24 -0700 (PDT) Received: from lochinvar.ece.neu.edu (mail2.ece.neu.edu [129.10.60.82]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA19899 for ; Thu, 23 Aug 2001 20:12:19 -0600 (MDT) Received: from runner.ece.neu.edu (runner.ece.neu.edu [129.10.60.136]) by lochinvar.ece.neu.edu (8.9.3/8.9.3) with ESMTP id WAA24641 for ; Thu, 23 Aug 2001 22:14:17 -0400 (EDT) Received: from localhost by runner.ece.neu.edu (8.9.3/8.9.3) with ESMTP id WAA06022 for ; Thu, 23 Aug 2001 22:12:22 -0400 (EDT) X-Authentication-Warning: runner.ece.neu.edu: mcdonald owned process doing -bs Date: Thu, 23 Aug 2001 22:12:22 -0400 (EDT) From: "A. Bruce McDonald" X-Sender: mcdonald@runner To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Re: CFP: CNDS 2002, San Antonio, Texas In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: ANNOUNCEMENT AND CALL FOR PAPERS (2nd Announcement) CNDS'2002 Submission Deadline: Sept 21, 2001 ----------------------------------------------------------------------- Please Accept Our Sincere Apologies Should you Receive Multiple Copies of this CFP ----------------------------------------------------------------------- The Society for Modeling and Simulation International (SCS) presents: COMMUNICATION NETWORKS AND DISTRIBUTED SYSTEMS MODELING AND SIMULATION CONFERENCE 2002 January 27-31, 2002 Four Points Sheraton Hotel, Riverwalk North San Antonio, Texas Please Visit the Conference Web Site for Additional Information http://www.ece.neu.edu/conf/CNDS/2002/ ----------------------------------------------------------------------- * * * * * * * * * * CNDS focuses on applications of simulation over a range of interesting topics in addition to simulation and modeling methodologies. We are seeking high quality technical papers that present original results related to the topics listed below. * * * * * ----------------------------------------------------------------------- Part of the 2002 SCS Western Multiconference on Computer Simulation The objective of this conference is to serve as a forum for the exchange of ideas among a talented group of international researchers on advances in the design and performance analysis of communication networks and distributed systems. The conference emphasizes modeling, technical advances and unique applications in the areas of high speed networking, wireless communications, multimedia applications, computer architecture and distributed, parallel and mobile computing systems. The structure of the conference is designed to facilitate collegiality and continuity of discussion among the conference speakers and attendees on the topics covered during the week. Paper sessions are designed to promote discussion of concepts and methodologies based on the presentation of results and innovative modeling, simulation or analysis techniques. The conference grew out of the need to improve the efficiency and quality of models of increasingly complex networks and distributed systems. In addition to the technical sessions, the conference includes an invited keynote speaker, and there will be vendor presentations and exhibits arranged in conjunction with the 2002 SCS Western Simulation Multiconference (WMC). Original, high-quality technical papers, addressing significant aspects of the design, modeling, or performance analysis of communication networks and distributed systems are solicited for review, possible presentation and subsequent publication in the conference proceedings. Papers that include well-conceived or innovative simulation modeling techniques with strong results and analysis are especially sought. Papers are solicited from not limited to the following topics: * Performance Modeling and Analysis * Mobile and Nomadic Computing * Distributed and Wireless Multimedia Systems * QoS Support for Wireless Ad Hoc Network Applications * Routing and Mobility Management in Wireless Networks * Power Control in Wireless Computer Systems * Distributed and Intelligent Sensor Networks * Wearable Computer Systems * Resource Allocation in High Speed Networks * Switch and Processor Architectures for High Speed Routers * Advances in Computer Architecture and Memory Systems * Network and Parallel Computing * Storage Area Networks * Content Based Image Retrieval Systems * Real-Time and Mobile Web-Based Computing * Reliable Multicast Routing and Group Communications * Network and Application Security and Availability * Web Caching and Switching * Scalable and Reliable Distributed Servers * Load Balancing in Distributed Systems IMPORTANT DATES: * The CDNS'02 deadline has been extended from September 15, 2001 to September 21, 2001 in order to match a misprint in a recently distributed WCN'02 brochure. Please make a note of the new date(s). September 21, 2001 Paper Submission Deadline. October 21, 2001 Acceptance Notification. November 21, 2001 Camera Ready Paper Deadline. * Note: Some printed announcements were distributed with incorrect information regarding submission instructions. Please make note of instructions as given here and on the CNDS WWW site. Authors are requested to submit manuscripts electronically to the Program Chair by 11:00 pm (Eastern Time) of the due date via Anonymous ftp directly: ftp.ece.neu.edu:/pub/conf/CNDS/2002/Submissions. Papers can also be uploaded using the Web Site: www.ece.neu.edu/conf/CNDS/2002/. *Please check the web site again prior to making your submission as we are hoping to install conference management software that will alter the procedures and ease the task for everyone.) Papers must be in English and submitted files must be in Postscript or PDF format with all figures and tables included. Files names must be unique and reflect the name of the primary author, his or her primary affiliation, the version number of the file and an extension indicating the file type. Multiple versions may be uploaded; however, only the most recent will be reviewed. Filenames are not readable once the file transfer has been completed. Confirmations will be sent to the contact author when the file has been retrieved and successfully viewed or printed. Only original unpublished material will be considered for publication. This year's International TPC is outstanding. Its members represent a broad spectrum of interrelated interests and technical expertise relevent to CNDS including performance analysis, simulation, communications networks, both wired and wireless, mobile computing, computer architecture, distributed systems and more. The TPC consists of newcomers and veterans of CNDS from Universities and Research Labs around the world. Each member is committed to ensure that all submissions are fully refereed for accuracy, technical content, and relevance, and to make this year's conference an exciting International forum for the presentation of high quality work and the exchange of ideas. Papers should be limited to 20 double-spaced pages (camera-ready versions are limited to 6 single-spaced pages). Authors must include a single page which includes all the authors' names, titles and affiliations, a paper abstract, list of top three relevant topics and contact person information (complete address, email, phone, and fax). Accepted papers will appear in the Conference's Proceedings to be published by the Society for Computer Simulation. Instructions for submitting camera ready papers will be sent to authors following paper acceptance. An award will be presented to the best paper presented at WMC'02. Authors of top papers will also be encouraged to submit a follow-on paper to the International Journal in Computer Simulation. Authors must obtain employer, client, or government releases prior to submittal of the final manuscript. Please do not hesitate to contact the Program Chair, Prof. McDonald via email (mcdonald@ece.neu.edu), or telephone ((617) 373-3028) with any questions concerning the paper submission and review process, or questions regarding the relevance of a paper to the conference. General Chair Program Chair Dr. Taieb F. Znati Prof. A. Bruce McDonald Senior Program Director Dept. of Electrical and Computer Eng. National Science Foundation 417 Dana Research Center ANIR and Northeastern University Computer Science Department 360 Huntington Avenue University of Pittsburgh Boston, MA 15221 Pittsburgh, PA 15260 U.S.A. U.S.A. Phone: +1(412)624-8417 Phone: +1(617)328-3028 FAX: +1(412)624-8854 FAX: +1(617)328-8970 E_Mail: znati@cs.pitt.edu E_Mail: mcdonald@ece.neu.edu Please visit the conference Web Site for up-to-date information and to see a list of the distinguished members of the International Technical Program Commmittee: http://www.ece.neu.edu/conf/CNDS/2002/ -------------------------------------------------------- A. Bruce McDonald f:617.373.8970 Assistant Prof. v:617.373.3028 ECE Dept., 417 Dana mcdonald@ece.neu.edu 360 Huntington Ave. www.ece.neu.edu/faculty/mcdonald Northeastern University Boston, MA 02115 www.ece.neu.edu/conf/CNDS/2002/ -------------------------------------------------------- From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 24 11:40:15 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07409 for ; Fri, 24 Aug 2001 11:40: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 IAA25489; Fri, 24 Aug 2001 08:41:05 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA12257; Fri, 24 Aug 2001 08:40:59 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19) with ESMTP id f7OFdh1O028069 for ; Fri, 24 Aug 2001 08:39:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19/Submit) id f7OFdhiO028068 for mobile-ip-dist; Fri, 24 Aug 2001 08:39:43 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19) with ESMTP id f7OFde1O028061 for ; Fri, 24 Aug 2001 08:39:40 -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 IAA19756 for ; Fri, 24 Aug 2001 08:39:44 -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 IAA06585 for ; Fri, 24 Aug 2001 08:39:44 -0700 (PDT) Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19) id ; Fri, 24 Aug 2001 11:38:49 -0400 Message-ID: From: "Shahrier, Sharif M." To: "'mobile-ip@sunroof.eng.sun.com'" Cc: "Shahrier, Sharif M." Subject: RE: [mobile-ip] GGSN to Internet Date: Fri, 24 Aug 2001 11:38: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: Hi, I was wondering if anyone can provide information on how GGSN currently attaches to the Internet. How this is currently done. Is there just a gateway between GGSN and the IP-backbone? If that is the case, how are functions such as inter-GGSN mobility management functions performed? Thanks for any information. Sharif. From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 24 12:01:39 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08025 for ; Fri, 24 Aug 2001 12:01:38 -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 JAA05459; Fri, 24 Aug 2001 09:01: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 IAA15558; Fri, 24 Aug 2001 08:59:50 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19) with ESMTP id f7OFwf1O028150 for ; Fri, 24 Aug 2001 08:58:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19/Submit) id f7OFwfci028149 for mobile-ip-dist; Fri, 24 Aug 2001 08:58:41 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19) with ESMTP id f7OFwb1O028142 for ; Fri, 24 Aug 2001 08:58: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 IAA22922 for ; Fri, 24 Aug 2001 08:58:42 -0700 (PDT) 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 IAA05875 for ; Fri, 24 Aug 2001 08:58: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 f7OFwki25715 for ; Fri, 24 Aug 2001 10:58:46 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 24 Aug 2001 10:58:41 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 24 Aug 2001 10:58:40 -0500 content-class: urn:content-classes:message Subject: RE: [mobile-ip] GGSN to Internet Date: Fri, 24 Aug 2001 10:58:40 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF441E84D0@daebe007.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [mobile-ip] GGSN to Internet X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Thread-Index: AcEsszGOanFjCZilEdWrxAAIx6S5QwAAjSdA From: "Patil Basavaraj (NET/Dallas)" To: Cc: X-OriginalArrivalTime: 24 Aug 2001 15:58:41.0036 (UTC) FILETIME=[A4E68CC0:01C12CB5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f7OFwc1O028143 Sender: owner-mobile-ip@sunroof.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 Sharif, The Mobile IP WG list is not the right place w.r.t questions pertaining to GPRS. -Basavaraj > > Hi, > > I was wondering if anyone can provide information on how GGSN > currently attaches to the Internet. How this is currently > done. Is there > just a gateway between GGSN and the IP-backbone? If that is > the case, how > are functions such as inter-GGSN mobility management > functions performed? > Thanks for any information. > > Sharif. > > From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 24 12: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 ESMTP id MAA08142 for ; Fri, 24 Aug 2001 12:03: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 KAA24877; Fri, 24 Aug 2001 10:04:10 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA16714; Fri, 24 Aug 2001 09:03:51 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19) with ESMTP id f7OG351O028188 for ; Fri, 24 Aug 2001 09:03:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19/Submit) id f7OG35pZ028187 for mobile-ip-dist; Fri, 24 Aug 2001 09:03: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.Beta19+Sun/8.12.0.Beta19) with ESMTP id f7OG311O028180 for ; Fri, 24 Aug 2001 09:03:01 -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 JAA18652 for ; Fri, 24 Aug 2001 09:03:06 -0700 (PDT) Received: from mailer3.bham.ac.uk (mailer3.bham.ac.uk [147.188.128.54]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA08361 for ; Fri, 24 Aug 2001 09:03:03 -0700 (PDT) Received: from bham.ac.uk ([147.188.128.127]) by mailer3.bham.ac.uk with esmtp (Exim 3.16 #2) id 15aJQD-0004Pn-00 for mobile-ip@sunroof.eng.sun.com; Fri, 24 Aug 2001 17:03:01 +0100 Received: from eee-fs7.bham.ac.uk ([147.188.145.131] helo=bham-eee-fs7.bham.ac.uk) by bham.ac.uk with esmtp (Exim 3.16 #3) id 15aJQO-0002bL-00 for mobile-ip@sunroof.eng.sun.com; Fri, 24 Aug 2001 17:03:12 +0100 Received: by eee-fs7.bham.ac.uk with Internet Mail Service (5.5.2653.19) id ; Fri, 24 Aug 2001 17:02:09 +0100 Message-ID: From: "Vanijprahba H." To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] GGSN to Internet Date: Fri, 24 Aug 2001 17:02:08 +0100 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, correct me if i am wrong, i think GGSN is not directly connected to the IP-backbone. it is connected via an operator network to the Edge router (gateway). once the mobile terminal is roamed to another network, SGSN will check the MT's id. the MT can either use the home GGSN or visited GGSN to route the packets to their destinations... Public Land Mobile Network (PLMN), which consists of SGSN and GGSN, are interconnected by Inter-PLMN backbone network. it utilizes the GPRS Tunneling Protocol (GTP) to handle the global mobility. but again, the MT can use both Home or Visit PLMN (HPLMN or VPLMN). Hope this will help.... Hugh -----Original Message----- From: Shahrier, Sharif M. [mailto:Sharif.Shahrier@InterDigital.com] Sent: 24 August 2001 16:39 To: 'mobile-ip@sunroof.eng.sun.com' Cc: Shahrier, Sharif M. Subject: RE: [mobile-ip] GGSN to Internet Hi, I was wondering if anyone can provide information on how GGSN currently attaches to the Internet. How this is currently done. Is there just a gateway between GGSN and the IP-backbone? If that is the case, how are functions such as inter-GGSN mobility management functions performed? Thanks for any information. Sharif. From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 24 12:07:19 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08247 for ; Fri, 24 Aug 2001 12:07:19 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA09118; Fri, 24 Aug 2001 09:08: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 JAA17644; Fri, 24 Aug 2001 09:08:02 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19) with ESMTP id f7OG771O028235 for ; Fri, 24 Aug 2001 09:07:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19/Submit) id f7OG773M028234 for mobile-ip-dist; Fri, 24 Aug 2001 09:07:07 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19) with ESMTP id f7OG731O028227 for ; Fri, 24 Aug 2001 09:07:03 -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 JAA19729 for ; Fri, 24 Aug 2001 09:07:08 -0700 (PDT) Received: from pltn13.pbi.net (mta7.pltn13.pbi.net [64.164.98.8]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA21218 for ; Fri, 24 Aug 2001 09:07:08 -0700 (PDT) Received: from earthlink.net ([63.195.116.64]) by mta7.pltn13.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GIK00HQUY3VAC@mta7.pltn13.pbi.net> for mobile-ip@sunroof.eng.sun.com; Fri, 24 Aug 2001 09:07:07 -0700 (PDT) Date: Fri, 24 Aug 2001 08:55:31 -0700 From: Debi Jones Subject: Re: [mobile-ip] GGSN to Internet To: mobile-ip@sunroof.eng.sun.com Message-id: <3B8678F2.26EAB74A@earthlink.net> MIME-version: 1.0 X-Mailer: Mozilla 4.73 [en] (Win95; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: <697DAA22C5004B4596E033803A7CEF441E84D0@daebe007.NOE.Nokia.com> Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Do you have a place to recommend taking this question? Does anyone else? That would be helpful to this person and others who have an interest in the deployment of GPRS. "Patil Basavaraj (NET/Dallas)" wrote: > Sharif, > > The Mobile IP WG list is not the right place w.r.t questions > pertaining to GPRS. > > -Basavaraj > > > > > Hi, > > > > I was wondering if anyone can provide information on how GGSN > > currently attaches to the Internet. How this is currently > > done. Is there > > just a gateway between GGSN and the IP-backbone? If that is > > the case, how > > are functions such as inter-GGSN mobility management > > functions performed? > > Thanks for any information. > > > > Sharif. > > > > From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 24 12:21:47 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08619 for ; Fri, 24 Aug 2001 12:21: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 KAA09001; Fri, 24 Aug 2001 10:22: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 JAA23058; Fri, 24 Aug 2001 09:22:13 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19) with ESMTP id f7OGKB1O028322 for ; Fri, 24 Aug 2001 09:20:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19/Submit) id f7OGKBar028321 for mobile-ip-dist; Fri, 24 Aug 2001 09:20:11 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19) with ESMTP id f7OGK71O028314 for ; Fri, 24 Aug 2001 09:20:08 -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 JAA20137 for ; Fri, 24 Aug 2001 09:20:09 -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 KAA07336 for ; Fri, 24 Aug 2001 10:20:05 -0600 (MDT) Received: by megisto-sql1.megisto.com with Internet Mail Service (5.5.2650.21) id ; Fri, 24 Aug 2001 12:19:12 -0400 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] GGSN to Internet Date: Fri, 24 Aug 2001 12:19: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: Hi Debi, the 3gpp community also has mailing lists (http://www.3gpp.org) although one doesn't often see these kinds of questions on the list. But I'd investigate there and see whether someone on those lists can help you out. Phil > -----Original Message----- > From: Debi Jones [mailto:netbean@earthlink.net] > Sent: Friday, August 24, 2001 11:56 AM > To: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] GGSN to Internet > > > Do you have a place to recommend taking this question? Does anyone > else? That would be helpful to this person and others who have an > interest in the deployment of GPRS. > > "Patil Basavaraj (NET/Dallas)" wrote: > > > Sharif, > > > > The Mobile IP WG list is not the right place w.r.t questions > > pertaining to GPRS. > > > > -Basavaraj > > > > > > > > Hi, > > > > > > I was wondering if anyone can provide information > on how GGSN > > > currently attaches to the Internet. How this is currently > > > done. Is there > > > just a gateway between GGSN and the IP-backbone? If that is > > > the case, how > > > are functions such as inter-GGSN mobility management > > > functions performed? > > > Thanks for any information. > > > > > > Sharif. > > > > > > > From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 24 12:27:28 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08742 for ; Fri, 24 Aug 2001 12:27:27 -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 KAA13371; Fri, 24 Aug 2001 10:28: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 JAA24511; Fri, 24 Aug 2001 09:28:03 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19) with ESMTP id f7OGR81O028365 for ; Fri, 24 Aug 2001 09:27:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19/Submit) id f7OGR8Ji028364 for mobile-ip-dist; Fri, 24 Aug 2001 09:27: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19) with ESMTP id f7OGR41O028357 for ; Fri, 24 Aug 2001 09:27: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 JAA24233 for ; Fri, 24 Aug 2001 09:27:09 -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 JAA21394 for ; Fri, 24 Aug 2001 09:27:08 -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 f7OGQd622017; Fri, 24 Aug 2001 09:26:40 -0700 (PDT) Received: (mchandra@localhost) by mchandra-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA20291; Fri, 24 Aug 2001 12:25:56 -0400 (EDT) Date: Fri, 24 Aug 2001 12:25:56 -0400 From: "Madhavi W. Chandra" To: mobile-ip@sunroof.eng.sun.com Cc: pcalhoun@diameter.org, charliep@iprg.nokia.com, Basavaraj.Patil@nokia.com, PRoberts@megisto.com, Read Bell , "Kent K. Leung" , Alpesh Patel , Madhavi Chandra Subject: [mobile-ip] Request in Gen Key draft Message-ID: <20010824122556.A20279@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: Hi All, In 'draft-ietf-mobileip-gen-key-00.txt', we are requesting that key exchange be allowed to be unsolicited. Specifically, we are requesting that 'Key Reply' messages and 'Key Request' messages be allowed to be sent in either an RRQ or an RPY, and a statement be added to the draft. The original text in -00 version was vague enough to be interpreted as above. However, new text was added in the Introduction in the latest revision that explicity states a restriction. We would like this restriction removed, and more flexible text added to support unsolicited key exchange. As per procedure, we would like to gauge the views of the WG in this matter, so that the authors may include our request. Thanks, Madhavi From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 24 12: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 ESMTP id MAA09114 for ; Fri, 24 Aug 2001 12:41:03 -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 JAA25874; Fri, 24 Aug 2001 09:41: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 JAA27540; Fri, 24 Aug 2001 09:41:12 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19) with ESMTP id f7OGdA1O028414 for ; Fri, 24 Aug 2001 09:39:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19/Submit) id f7OGdALx028413 for mobile-ip-dist; Fri, 24 Aug 2001 09:39: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19) with ESMTP id f7OGd61O028406 for ; Fri, 24 Aug 2001 09:39: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 JAA16541 for ; Fri, 24 Aug 2001 09:39:11 -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 KAA21877 for ; Fri, 24 Aug 2001 10:39:06 -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 f7OGd9v15629 for ; Fri, 24 Aug 2001 18:39:09 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Fri Aug 24 18:39:08 2001 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 24 Aug 2001 18:32:29 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008C2A@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] GGSN to Internet Date: Fri, 24 Aug 2001 18:39:01 +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: > Do you have a place to recommend taking this question? Does anyone > else? That would be helpful to this person and others who have an > interest in the deployment of GPRS. > => The SA2 mailing list (www.3gpp.org) is the right place for this. FWIW, the GGSN is like a default router for IPv6 hosts and it can connect directly to the Internet. The host never changes GGSNs within the UMTS network so never gets a new address. Hesham > "Patil Basavaraj (NET/Dallas)" wrote: > > > Sharif, > > > > The Mobile IP WG list is not the right place w.r.t questions > > pertaining to GPRS. > > > > -Basavaraj > > > > > > > > Hi, > > > > > > I was wondering if anyone can provide information on how GGSN > > > currently attaches to the Internet. How this is currently > > > done. Is there > > > just a gateway between GGSN and the IP-backbone? If that is > > > the case, how > > > are functions such as inter-GGSN mobility management > > > functions performed? > > > Thanks for any information. > > > > > > Sharif. > > > > > > From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 24 13:14:46 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09972 for ; Fri, 24 Aug 2001 13:14: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 KAA13274; Fri, 24 Aug 2001 10:15: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 KAA04890; Fri, 24 Aug 2001 10:15:19 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19) with ESMTP id f7OHE21O028674 for ; Fri, 24 Aug 2001 10:14:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19/Submit) id f7OHE221028673 for mobile-ip-dist; Fri, 24 Aug 2001 10:14:02 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19) with ESMTP id f7OHDx1O028666 for ; Fri, 24 Aug 2001 10:13:59 -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 KAA00914 for ; Fri, 24 Aug 2001 10:14:04 -0700 (PDT) Received: from mercury.ukc.ac.uk (mercury.ukc.ac.uk [129.12.21.10]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA14404 for ; Fri, 24 Aug 2001 10:14:02 -0700 (PDT) Received: from pelican.ukc.ac.uk ([129.12.200.26]) by mercury.ukc.ac.uk with esmtp (Exim 3.22 #4) id 15aKWp-0000FK-00 for mobile-ip@sunroof.eng.sun.com; Fri, 24 Aug 2001 18:13:55 +0100 Received: from pccomm6.ukc.ac.uk ([129.12.50.121] helo=ukc.ac.uk) by pelican.ukc.ac.uk with esmtp (Exim 3.22 #3) id 15aKWv-0005zS-00 for mobile-ip@sunroof.eng.sun.com; Fri, 24 Aug 2001 18:14:01 +0100 Message-ID: <3B868B57.A583F97E@ukc.ac.uk> Date: Fri, 24 Aug 2001 18:13:59 +0100 From: "K.Sivarajah (INdran)" 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] Application Modelling Statistics 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, Can someone tell me where can I find information on Application Modelling Statistics. Basically, information on audio, video, GSM, UMTS, Web Browsing etc related to interarrival time, packet size, bit rate...etc. Thanks Indran -- /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \ Kumarendra Sivarajah (INdran) / / Department of Electronics \ \ University of Kent at Canterbury / / Telephone(Office): +44 (0)1227 823257 \ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ From owner-mobile-ip@sunroof.eng.sun.com Sat Aug 25 12:38:51 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12931 for ; Sat, 25 Aug 2001 12:38: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 KAA23376; Sat, 25 Aug 2001 10:39: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 JAA03558; Sat, 25 Aug 2001 09:39:25 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7PGcG40000030 for ; Sat, 25 Aug 2001 09:38:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7PGcG3C000029 for mobile-ip-dist; Sat, 25 Aug 2001 09:38:16 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7PGcC40000022 for ; Sat, 25 Aug 2001 09: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 JAA20577 for ; Sat, 25 Aug 2001 09:38:17 -0700 (PDT) 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 JAA08346 for ; Sat, 25 Aug 2001 09:38:17 -0700 (PDT) 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 f7P3ffi07683 for ; Fri, 24 Aug 2001 22:46:41 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 24 Aug 2001 22:41:35 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 24 Aug 2001 22:41:35 -0500 content-class: urn:content-classes:message Subject: [mobile-ip] IETF51 - MIP WG Presentations Date: Fri, 24 Aug 2001 22:41:34 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF441E84EA@daebe007.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Thread-Topic: IETF51 - MIP WG Presentations Thread-Index: AcEtF/LXHAslg5kHEdWwlwAAhj/HZA== From: "Patil Basavaraj (NET/Dallas)" To: "'Mobile IP'" X-OriginalArrivalTime: 25 Aug 2001 03:41:35.0536 (UTC) FILETIME=[D6DC8B00:01C12D17] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f7PGcD40000023 Sender: owner-mobile-ip@sunroof.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, The Mobile IP WG presentations for IETF51 are now available at: http://people.nokia.net/~patil/MobileIP_IETF51 -Basavaraj From owner-mobile-ip@sunroof.eng.sun.com Sat Aug 25 15:17:48 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13931 for ; Sat, 25 Aug 2001 15:17:47 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA05252; Sat, 25 Aug 2001 12:18:44 -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 MAA28335; Sat, 25 Aug 2001 12:18:38 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7PJHc40000196 for ; Sat, 25 Aug 2001 12:17:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7PJHbdD000195 for mobile-ip-dist; Sat, 25 Aug 2001 12:17:37 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7PJHY40000186 for ; Sat, 25 Aug 2001 12:17:34 -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 MAA28220; Sat, 25 Aug 2001 12:17:39 -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 NAA19045; Sat, 25 Aug 2001 13:17:34 -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 f7PJHgX26259; Sat, 25 Aug 2001 12:17: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 AAJ21005; Sat, 25 Aug 2001 12:17:36 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA21011; Sat, 25 Aug 2001 12:17:35 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15239.63951.838016.633781@thomasm-u1.cisco.com> Date: Sat, 25 Aug 2001 12:17:35 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Cc: mat@cisco.com, Erik.Nordmark@eng.sun.com Subject: RE: [mobile-ip] RE: Piggybacking [Was: IPsec, IKE, MIPv6 and conc ensus ] In-Reply-To: <009CA59D1752DD448E07F8EB2F911757197FE4@esebe004.NOE.Nokia.com> References: <009CA59D1752DD448E07F8EB2F911757197FE4@esebe004.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 jarno.rajahalme@nokia.com writes: > Michael Thomas wrote: > > Note that links with low bandwidth are fairly > > likely to want to use CRTP/ROHC themselves, so the > > actual cost of the IP6 header should be close to > > nil since it is almost completely compressible. > > Only if the IPv6 header is part of a flow. For occasional signaling messages > there is likely to be no header compression at all. I would assume that hosts who send BU's would likely have a flow already established. BU's, after all, are optimizations, and the MN should probably be judicious about only sending BU's to active flows if it is bandwidth constrained. Mike From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 27 06:50:23 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10286 for ; Mon, 27 Aug 2001 06:50:23 -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 DAA00839; Mon, 27 Aug 2001 03:51: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 DAA29219; Mon, 27 Aug 2001 03:50:51 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7RAnv40001847 for ; Mon, 27 Aug 2001 03:49:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7RAnv7A001846 for mobile-ip-dist; Mon, 27 Aug 2001 03:49:57 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7RAnq40001839 for ; Mon, 27 Aug 2001 03:49: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 DAA29153 for ; Mon, 27 Aug 2001 03:50:00 -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 DAA04545 for ; Mon, 27 Aug 2001 03:49:59 -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 GAA10045; Mon, 27 Aug 2001 06:48:39 -0400 (EDT) Message-Id: <200108271048.GAA10045@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-qos-requirements-01.txt Date: Mon, 27 Aug 2001 06:48:38 -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 : Requirements of a QoS Solution for Mobile IP Author(s) : H. Chaskar Filename : draft-ietf-mobileip-qos-requirements-01.txt Pages : 7 Date : 24-Aug-01 Mobile IP protocol ensures correct routing of packets to mobile node as the mobile node changes its point of attachment with the Internet. However, it is also required to provide proper QoS forwarding treatment to mobile node's packet stream at the intermediate nodes in the network, so that QoS-sensitive IP services can be supported over Mobile IP. This document describes requirements of an IP QoS mechanism for its satisfactory operation with Mobile IP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-qos-requirements-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-ietf-mobileip-qos-requirements-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mobileip-qos-requirements-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: <20010824105646.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-qos-requirements-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-qos-requirements-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010824105646.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 27 10:04:02 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18994 for ; Mon, 27 Aug 2001 10:04:02 -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 HAA18331; Mon, 27 Aug 2001 07:04:57 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA16258; Mon, 27 Aug 2001 07:04:52 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7RE2u40002178 for ; Mon, 27 Aug 2001 07:02:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7RE2uwO002177 for mobile-ip-dist; Mon, 27 Aug 2001 07:02:56 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7RE2r40002170 for ; Mon, 27 Aug 2001 07:02: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 HAA20504 for ; Mon, 27 Aug 2001 07:03:02 -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 IAA06082 for ; Mon, 27 Aug 2001 08:02:57 -0600 (MDT) Received: by megisto-sql1.megisto.com with Internet Mail Service (5.5.2650.21) id ; Mon, 27 Aug 2001 10:02:00 -0400 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] 3g wireless extentions draft - feedback from IESG Date: Mon, 27 Aug 2001 10:01:58 -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 the complete feedback from the IESG on this document. Ying has already seen some of it and made some editorial updates, but the document is receiving serious scrutiny as you can see from the first three paragraphs. The IESG is trying to determine what exactly to do with this document. What we've decided to do as a working group is to forward this as an Informational RFC from the WG. Should we continue this course? If so, are the suggested changes agreeable? Alternatives would be to publish this as an individual contribution for an Informational RFC if it is agreed that although this reuses Mobile IP messages it has little to do with Mobile IP otherwise and is of very limited application, or to realize that the spec is published elsewhere (in the cdma2000 standards suite) and there is little purpose of having the IETF publish such a doc. Phil -------------------------------- General: does this document really need to be published as an RFC? It seems to be addressing a narrow problem that is of little interest to most MIP implementations. It is also a rather ugly solution, one that I suspect the MIP WG had no input on. Was this presented as a completed document before it was made a WG document? Also, why isn't this a Standards Track document? I suspect the answer is because it is really not a modification of MIP supported by the WG. Rather it is documenting something 3GPP2 did, but that cannot be changed at this point. Is this the case? If so, I could see publishing this as an informationl RFC, but only if it is modified as outlined below. Has this document already been published elsewhere? If so, does it need to be published as an RFC as well? > Mobile IP Based Micro Mobility Management Protocol in > The Third Generation Wireless Network Change title to make clear that this applies only to cdma2000 networks. Indeed, based on comments below, it might be good to also change the title to not suggest that this is some sort of general purpose MIP protocol. It is clearly not. Too many authors listed on page one. Please move list of authors to acknowledgment section and only list the editor on the first page. Add a paragraph or two that provide context for why this is being published, and how it relates to MIP. In particular, this uses different UDP ports than MIP (so would not seem to be MIP at all!). In other words, an applicability statement of sorts, to make it clear that this is of limited interest to most folks. Finally, calling this an extension to MIP is somewhat of a stretch. For starters, it uses a different UDP port number. That alone would make it a different protocol in most people's eyes. This is a rather ugly hack, IMO. It uses a different port number, yet uses many of the same MIP message types, though augmented in some cases. To make matters worse, it appears to use (for example) apparently unused bits in existing MIP messages (i.e, the 'r' and 'x' bits in Registration Requests). 2002-bis says for the 'r' bit: > r Sent as zero; ignored on reception. SHOULD NOT be > allocated for any other uses. So its clearly infringing on MIP as well. One *could* make the argument that because this document uses a different port number, MIP doesn't need to assign the code points that are implied here. There should be no conflict since MIP messages go to the MIP port, and the messages in this document go to a different port. But I would guess that this would cause problems for some existing implementations that have not made a clean distinction between MIP proper, and the extensions defined in this document . :-( > Mobile IP requires link layer connectivity between the Mobile Node > and the Foreign Agent. This draft proposes a protocol for achieving > this when the physical layer terminates at a point distant from the > FA. In particular, this protocol applies to cdma2000 networks where > Might help to point out that this is all done transparently to the client/mobile node, and is something that is done between the RNN and FA. This is a key point, as it means the document is probably not of relevance to most MIP implementations. Also, the wording doesn't really seem right. Does this draft really "propose a protocol for achieving" ... link-layer connectivity between the MN and FA? Can one run ARP when this protocol is employed? Can one send arbitrary L2 packets? Or is it in fact limited to tunneling IP packets? > The interface between the RNN and the PDSN is called the RP > interface. This interface requires mobility management for handling > handoff from one RNN to another without interrupting end to end > communication. It also requires the support of the link layer > protocol encapsulation. Is "interface" the right terminology here? Seems like if the RNN and PDSN are in separate boxes, this is a "protocol". Is this a terminology mismatch between the IETF and 3GPP2? > This document defines extensions to the Mobile IP protocol [1] to > allow mobility management for the interface between a radio network > and a packet data network in the third generation cdma2000 network. Again, I find the terminology "interface" here to be confusing. Also, I think it is misleading to call this "extensions to Mobile IP". It isn't really extending what most people think of MIP (i.e, the MN-HA-CN interactions). It is defining something specific that allows the FA to not have to reside on the directly attached link. It might be good to define some generic terminology that makes this more clear at the start of the document. For an analogy, in PPP, the client dials directily into the NAS and the NAS and PPP server are on the same device. L2TP allows the NAS/PPP server functionality to be split into two distinct parts, connected by a network. That is, the NAS tunnels stuff to the PPP server (transparently from the client's perspective). This seems to be a analagous type of thing (though the details are of course very different). > The messages used for mobility management across the RP interface > include Registration Request, Registration Reply, Registration > Update and Registration Acknowledge. Both Registration Request and > Registration Update messages MUST be sent with UDP using well-known > port number 699. Rather than using terminology such as "used for mobility management", say "used for tunneling MIP messages" ... Personally, I find the term "mobility management" to be almost meaningless. Seems like it could mean anything to anyone. Interestingly, Figure one shows a HA, but no FA. Yet all the previous text talks about the FA, and not a HA. Is this document about FA intereactions , HA interactions, or both? This could be clarified. The reuse of the mobile IP messages causes terminology confusion. Those messages have terms like home address, home agent address, CoA, etc which are meaningful in the MIP context. This prototocol operates between a MIP MN and a MIP FA thus to be clear it would make sense to actually replace the terminology used to describe the message formats as follows: Current Actual Home Address Must be zero Home Agent PDSN address (which is a MIP FA) Care of Address RNN address If those terminology changes are made then it is possible to describe the interaction between the RP protocol and MIP without causing utter confusion. > 4.1 Registration Request > > In a cdma2000 network, the mobile node initiates a connection by > sending a call setup indication to the RNN across the radio network. What kind of setup? to HA, FA, or either? Or is this an L2 connection? There are some formatting problems with the picture in 4.2 (tabs?). > 6.0 IANA Considerations > > The recommended message type value and extension type value have > been used in 3GPP2 standard IOSv4.1. It is desirable to have the > same type value assigned by IANA. This is really unfortunate. It appears that IANA was never consulted about the use of some of these numbers; they were just used. This is wrong. The idea that one can go to the IANA web pages, look for an unused number, and then assume IANA will assign it a year later is really bad. What happens when 3 different sets of people do this and chose the same number? And the IANA (which knows nothing of the three uses) assigns the same value for an RFC that is just being issued? This section is also in the wrong format for an RFC. First, IANA should review this section and report back whether they are able and willing to make the assignments as requested (they may not be able to). If they can, the text should simply state things like "IANA has assigned", as opposed to "IANA SHOULD assign". I.e, think about what the document should read like as an RFC. > The well-known UDP port number 699 used for the Registration Request > and Registration Update Message was chosen from the unassigned port > range. They were requested from and have been assigned by IANA and > are listed at: ftp://ftp.isi.edu/in-notes/iana/assignments/port- > numbers. The IANA page says 699 belongs to: accessnetwork 699/tcp Access Network accessnetwork 699/udp Access Network # Yingchun Xu Somewhat surprisingly, the document doesn't use the term "access network". IANA should update the web page (presumably) to reference this document. Also, would it make sense to mention the name "accessnetwork" in the document, or to change this to something like "cdma2000 access network?" It would be good in the IANA considerations section to point out that "IANA has assigned port 699 for the purposed described in this document" (or something like that). That will ensure that IANA updates its web page when the RFC gets issues to point to the RFC. Also, there is a question/comment in regards to the Registration Reply/Update and Acknowledge secion. The question arose as to what happens when a reply/update/acknowledge is expected but not received? (Is the specified elsewhere? mobileip?) Since this document isn't *really* MIP, but a separate protocol, it would seem like it needs to say when retransmissions are needed, etc. From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 27 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 ESMTP id LAA21744 for ; Mon, 27 Aug 2001 11:26: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 JAA04722; Mon, 27 Aug 2001 09:27: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 IAA02901; Mon, 27 Aug 2001 08:27:17 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7RFPw40002312 for ; Mon, 27 Aug 2001 08:25:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7RFPwQo002311 for mobile-ip-dist; Mon, 27 Aug 2001 08:25:58 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7RFPt40002304 for ; Mon, 27 Aug 2001 08:25:55 -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 LAA11177 for ; Mon, 27 Aug 2001 11:26:02 -0400 (EDT) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id LAA17863 for mobile-ip@sunroof.eng.sun.com; Mon, 27 Aug 2001 11:26:31 -0400 (EDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19) with ESMTP id f7PAiZ1O029746 for ; Sat, 25 Aug 2001 03:44: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 DAA00665 for ; Sat, 25 Aug 2001 03:44:39 -0700 (PDT) Received: from MailBreak.Com ([216.207.225.170]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA25141 for ; Sat, 25 Aug 2001 04:45:01 -0600 (MDT) Received: from solid [24.168.138.53] by mailbreak.com [216.207.225.173] with SMTP (MDaemon.PRO.v4.0.4.R) for ; Sat, 25 Aug 2001 06:44:13 -0400 Message-ID: <024901c12d53$c3e89660$6401a8c0@solid> From: "Eunsoo Shim" To: Cc: , References: Subject: [mobile-ip] Re: [seamoby] Resend:New Draft:Issues in Candidate Access Router Discovery Date: Sat, 25 Aug 2001 06:50:32 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-MDRemoteIP: 24.168.138.53 X-Return-Path: eunsoo@mailbreak.com X-MDaemon-Deliver-To: mobile-ip@sunroof.eng.sun.com Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, It's an interesting draft. Actually we submitted an I-D for fast handoff in MIPv4 last November with the idea of using the neighboring FA information. Unfortunately the I-D does not exist in the archive any more but it is available at http://www.ctr.columbia.edu/~eunsoo/paper/draft-shim-mobileip-neighbor-00.tx t. The neighbor FA in our draft is the PAAR described in your draft. The section 2 (Neighbor FA Information) describes a mechanism that each FA (AR in MIPv6) discovers its neighboring FAs (PAARs). It is a simple mechanism where each MN reports to the new FA (AR) of its old FA(AR) and then the new FA learns about the old FA as one of its neighbor FAs. Also the new FA informs the old FA of itself. Thus two FAs get to know each other. After a certain transition period, a FA gets to know its all neighbor FAs. It is a dynamic and distributed algorithm. We believe our neighbor FA discovery mechanism can be a solution for the problem of identifying the candidate ARs. Thanks. Eunsoo ----- Original Message ----- From: To: Cc: ; Sent: Friday, July 13, 2001 10:48 AM Subject: [seamoby] Resend:New Draft:Issues in Candidate Access Router Discovery 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. QÍQ <> From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 27 12:22:16 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23435 for ; Mon, 27 Aug 2001 12:22: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 JAA20319; Mon, 27 Aug 2001 09: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 JAA29042; Mon, 27 Aug 2001 09:22:53 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7RGLj40002527 for ; Mon, 27 Aug 2001 09:21:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7RGLj5Z002526 for mobile-ip-dist; Mon, 27 Aug 2001 09:21:45 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7RGLf40002519 for ; Mon, 27 Aug 2001 09:21:41 -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 JAA28795 for ; Mon, 27 Aug 2001 09:21:50 -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 JAA20796 for ; Mon, 27 Aug 2001 09:21:49 -0700 (PDT) Received: by megisto-sql1.megisto.com with Internet Mail Service (5.5.2650.21) id ; Mon, 27 Aug 2001 12:20:47 -0400 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Comments on draft-team-mobileip-mipv6-sec-reqts-0 0.txt Date: Mon, 27 Aug 2001 12:20:40 -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: Thanks, Alex, for taking the time to review this. (Some comments inline) We would like to encourage feedback from the WG as a whole. The security ADs have indicated this is a good start. Does this reflect what the working group believes the requirements to be? Thanks, Phil > -----Original Message----- > From: Alexandru Petrescu [mailto:petrescu@crm.mot.com] > Sent: Thursday, August 16, 2001 8:25 AM > To: mobile-ip@sunroof.eng.sun.com > Subject: [mobile-ip] Comments on > draft-team-mobileip-mipv6-sec-reqts-00.txt > > > Hi, > > I have further comments on this draft that I believe have not yet been > mentioned. > > -the table in section 6 has threat B.4 but it is not described > anywhere in the body. Good catch. > -I propose addition of a DoS attack realized by sending fake Binding > Acknowledgments (this is also mentioned in > draft-roe-mobileip-updateauth-00.txt): > Threat B.5: > > By being able to passively monitor the traffic, the attacker could > learn about the CNs that the MN is communicating with and also > determine to which CNs the MN is sending BUs. The attacker could > thus synchronize with the MN such that when MN sends a BU to CN > then attacker replies to MN with a fake Binding Acknowledgment with > a Status field different than 0. > > Effect B.5: > > This will cause the MN to resend a new Binding Update (subject to > rate limiting of sending BU's) to CN's. Depending on timing and > synchronization, this could result on a DoS or low-grade service: > the communication between MN and CN can be shut off or it can > follow an unoptimized triangular route. > > Requirement B.5: > > I don't know. Probably the mentionned draft has a good idea in > this respect. This seems like a worthwhile scenario description to add since the MIPv6 draft already has text for protecting against a malicious binding ack. Could you produce proposed requirement text, please? > > -in section 5 Classification of Attackers, after reading the first > three lines I'm tempted to understand "link" as a "subnet". But > then, a "link" between CN an HA tends to be interpreted more as a > large portion of Internet, including CN's and HA' subnets. Thus I > propose a finer distinction, for example replace: > > "- an attacker on the link between the CN and the HA > > - an attacker on the link between the MN and the CN" > > with: > > "- an attacker on the path between the CN and the HA (except CN's > and HA's links) > > - an attacker on the path link between the MN and the CN (except > CN's and MN's links)" This seems like a useful clarification to me. > > Thank you for reading these comments, > > Alex > From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 27 12:56:23 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24408 for ; Mon, 27 Aug 2001 12:56: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 KAA18460; Mon, 27 Aug 2001 10:57: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 JAA17286; Mon, 27 Aug 2001 09:57:05 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7RGtl40002662 for ; Mon, 27 Aug 2001 09:55:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7RGtl7f002661 for mobile-ip-dist; Mon, 27 Aug 2001 09:55: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.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7RGti40002654 for ; Mon, 27 Aug 2001 09:55:44 -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 JAA05480 for ; Mon, 27 Aug 2001 09:55:52 -0700 (PDT) Received: from p-mail1.cnet.fr (p-mail1.rd.francetelecom.com [193.49.124.31]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id KAA01774 for ; Mon, 27 Aug 2001 10:56:17 -0600 (MDT) Received: by p-biset.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19) id ; Mon, 27 Aug 2001 18:55:38 +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 RRCAF80M; Mon, 27 Aug 2001 18:55:36 +0200 Message-ID: <3B8A7B63.1678ACEE@francetelecom.com> Date: Mon, 27 Aug 2001 18:55:00 +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] IPsec, IKE, MIPv6 and concensus References: <034BEFD03799D411A59F00508BDF754603008BCA@esealnt448.al.sw.ericsson.se> 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 Hi, "Hesham Soliman (ERA)" a écrit : > Hi, > > During the meeting Phil had asked me to write something up to > describe the problem with IPsec usage and some suggestions. > Obviously as we all know (or some of us) Mike Thomas already wrote > a draft for ESP, also Pekka sent a very long mail on the general > topic, so I'm not sure if a draft would add more to what we discussed. > > Therefore I thought perhaps getting some concensus on IPsec > usage would be a good idea. > > First let me summarise briefly the two problems we're having: > > 1. Relying on IKE only as a key exchange mechanism is not > acceptable (This was discussed several times and I think we > all agree on this assumption) > > 2. There are some issues to be resolved if IPsec is to be used. > Mainly this is related to the recent discussions on IPsec selectors > and their granularity. > > Before London, we agreed that (2) can be solved in 2 different ways: > > A. Use a new Ext Header value for MIPv6 BUs. This will not > involve any modifications to the IPsec implementations. > > B. Add some text to the draft to explain that all implementations > for MNs and CNs (receiving BUs only) MUST increase the > granularity of their IPsec implementations to search for the > BU option instead of relying on the nxt Header value only. > > Of course both A and B rely on eliminating piggybacking of the BUs. > > Problem (1) is addressed by several proposals. Needless to say that > 1 and 2 are not dependant on each other (or need not be). > > So the questions that should be answered IMO are: > > 1. Do we want to completely disallow the use of IKE ? JMC : No > > > 2. Do we want to completely disallow the use of IPsec ? JMC : No Regards. JMC. > > Regards, > 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 Mon Aug 27 14:32:19 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26751 for ; Mon, 27 Aug 2001 14:32:18 -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 MAA10491; Mon, 27 Aug 2001 12:32: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 LAA17361; Mon, 27 Aug 2001 11:32:53 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7RIVZ40002777 for ; Mon, 27 Aug 2001 11:31:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7RIVZoR002776 for mobile-ip-dist; Mon, 27 Aug 2001 11:31:35 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7RIVV40002769 for ; Mon, 27 Aug 2001 11:31:32 -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 LAA08277 for ; Mon, 27 Aug 2001 11:31:39 -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 LAA00531 for ; Mon, 27 Aug 2001 11:31:39 -0700 (PDT) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate4.mot.com (motgate4 2.1) with ESMTP id LAA03594 for ; Mon, 27 Aug 2001 11:31:38 -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 LAA23061 for ; Mon, 27 Aug 2001 11:31:38 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r2.mot.com with ESMTP; Mon, 27 Aug 2001 11:31:30 -0700 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 5E6482ECAC; Mon, 27 Aug 2001 20:30:22 +0200 (CEST) To: mobile-ip@sunroof.eng.sun.com Cc: Phil Roberts Subject: Re: [mobile-ip] Comments on draft-team-mobileip-mipv6-sec-reqts-0 0.txt References: From: Alexandru Petrescu Date: 27 Aug 2001 20:31:34 +0200 In-Reply-To: Message-Id: Lines: 58 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: > > Threat B.5: > > > > By being able to passively monitor the traffic, the attacker could > > learn about the CNs that the MN is communicating with and also > > determine to which CNs the MN is sending BUs. The attacker could > > thus synchronize with the MN such that when MN sends a BU to CN > > then attacker replies to MN with a fake Binding Acknowledgment with > > a Status field different than 0. > > > > Effect B.5: > > > > This will cause the MN to resend a new Binding Update (subject to > > rate limiting of sending BU's) to CN's. Depending on timing and > > synchronization, this could result on a DoS or low-grade service: > > the communication between MN and CN can be shut off or it can > > follow an unoptimized triangular route. > > > > Requirement B.5: > > > > I don't know. Probably the mentionned draft has a good idea in > > this respect. > > This seems like a worthwhile scenario description to add since the > MIPv6 draft already has text for protecting against a malicious > binding ack. Could you produce proposed requirement text, please? When re-reading it I realize that it's poorly formulated, I would prefer the following: Threat B.5: By being able to passively monitor the traffic, the attacker could learn about the CNs or HA that the MN is communicating with and also determine to which CNs or HA the MN is sending BUs. The attacker could thus synchronize with the MN such that when MN sends a BU then attacker replies to MN with a fake Binding Acknowledgment different than the true Binding Acknowledgment (Status, Lifetime or Refresh fields). Effect B.5: This can lead to (1) MN sends unnecessary BU's (subject to rate limiting of sending BU's) or (2) MN doesn't send a BU that is necessary. As further effects of (2) unnecessary triangular routing takes place or MN is not reachable at all. Requirement B.5: Upon receiving a packet carrying a Binding Acknowledgement, a mobile node MUST ensure it trusts the sender of that Binding Acknowledgment. Alternatively, the Binding Acknowledgment message could be removed from specification so that attacker can't forge it. [I'm not really proposing it, just to say that many things can be proposed if we don't have a statement "minimal modifs to Mobile IPv6" at the beginning of draft-team]. Alex From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 28 02: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 ESMTP id CAA28559 for ; Tue, 28 Aug 2001 02:58: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 XAA28901; Mon, 27 Aug 2001 23:59: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 XAA29147; Mon, 27 Aug 2001 23:58:53 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7S6uk40003661 for ; Mon, 27 Aug 2001 23:56:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7S6uk5E003660 for mobile-ip-dist; Mon, 27 Aug 2001 23:56:46 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7S6uh40003653 for ; Mon, 27 Aug 2001 23:56:43 -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 XAA27447 for ; Mon, 27 Aug 2001 23:56:50 -0700 (PDT) Received: from mostang.geo.co.il ([212.68.150.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA00959 for ; Tue, 28 Aug 2001 00:56:45 -0600 (MDT) Received: by MOSTANG with Internet Mail Service (5.5.2650.21) id ; Tue, 28 Aug 2001 09:54:35 +0200 Message-ID: From: Dor Snapir To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] R-P interface Flow Control proposals Date: Tue, 28 Aug 2001 09:54:34 +0200 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 All Does anyone knows if there are any other R-P flow control drafts except http://www.alternic.org/drafts/drafts-s-t/draft-singh-mobileip-fcext-00.txt thanks Dor From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 28 10:10:25 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10885 for ; Tue, 28 Aug 2001 10:10: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 IAA24348; Tue, 28 Aug 2001 08:10: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 HAA04904; Tue, 28 Aug 2001 07:10:46 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SE8c40004192 for ; Tue, 28 Aug 2001 07:08:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7SE8ciO004191 for mobile-ip-dist; Tue, 28 Aug 2001 07:08:38 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SE8X40004184 for ; Tue, 28 Aug 2001 07:08: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 HAA04624 for ; Tue, 28 Aug 2001 07:08:41 -0700 (PDT) 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 IAA28384 for ; Tue, 28 Aug 2001 08:09:06 -0600 (MDT) Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7SE9qI00458 for ; Tue, 28 Aug 2001 09:09:52 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 28 Aug 2001 09:08:39 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 28 Aug 2001 09:08:38 -0500 Subject: [mobile-ip] Minutes of WG meeting at IETF51 (Draft version) Date: Tue, 28 Aug 2001 09:08:38 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF441E8528@daebe007.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: Minutes of WG meeting at IETF51 (Draft version) content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Thread-Index: AcEvyw43b/EK1Zu9EdWwmwAAhj/HZA== From: "Patil Basavaraj (NET/Dallas)" To: "'Mobile IP'" X-OriginalArrivalTime: 28 Aug 2001 14:08:38.0828 (UTC) FILETIME=[EF548EC0:01C12FCA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f7SE8Z40004185 Sender: owner-mobile-ip@sunroof.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, Below are IETF51 WG meeting minutes. Please let me know if there are any discrepancies. The minutes will be submitted to the IETF secretary on Monday Sept 3rd (with any corrections if required). Basavaraj Phil Mobile IP WG meeting minutes for IETF51 --------------------------------------- ///////////////// // Session 1 // ///////////////// August 6th, 2001 (1930-2200) Reported by : Jayshree Bharatia Document Status : - 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 expired 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 expired 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 - Charles Perkins ================================================ Charlie Perkins provided current status and reasoning of why RFC2002 should move toward draft standards from its current status as proposed standards. He mentioned that multiple interoperability tests have been performed and there has been significant deployment exist today. The following implemented options were pointed out: - 'R' bit in the agent advertisement => may be superseded by AAA work - Prefix length extension in agent advertisement => never implemented and not interoperated - 'S' bit in registration request message => haven't shown interoperability, refers to simultaneous registration with separate COAs As per 2002Bis-o6 draft, Mobile IP implementations should include HMAC-MD5 as one of the additional authentication algorithms. This algorithm is used for producing and verifying the authentication data in Mobile IP registration messages. If the requirement of using HMAC-MD5 is mandated, it may take six more months before draft moves for the last call. He insisted that the working group should influence this decision. The alternative suggested was to remove this portion from the 2002Bis draft and progress the draft for the proposed standards. It was pointed out by Thomas Narten that it is not required to have implementation of HMAC-MD5 in order to progress toward proposed standards. In the end it was decided that the decision would be taken based on the further WG mailing list discussion. Mobile IP v6 security update - Phil Roberts =========================================== The discussion was based on MIPv6 protocol and the requirements for a security solution discussed in draft draft-team-mobileip-mipv6-sec-reqts-00.txt. It was mentioned by Raj that the draft has an approval from security ADs and pointed out a couple of outstanding items like implementation and usage of IPSec. The current goal is to progress MIPv6 draft to PS by the end of year 2001. The current proposals that specify alternative solutions for the binding update problem are: - draft-thomas-mobileip-ha-cookies-00.txt - draft-perkins-bake-01.txt - draft-montenegro-sucv-01.txt The intent is to have an agreed upon solution that is acceptable to the security area directors and meets the requirements specified in the requirements I-D. Further discussion lead to whether Routing Optimization should be a part of this draft and its impact on 3GPP2 work. Mobile IP v6 other changes - Charles Perkins ============================================ Charlie brought up the issue related to authentication data passed with a binding update destination option. The working group comments received on this topic were that it is currently unclear in the draft on how IPSec can be used and how to handle potential IPSec problems. Also the issue with piggybacking IPSec on binding update data is still open. The further discussions on ESP vs AH may be continue on the mailing list. It seems home agent discovery may need some more work but other than this, the draft may be ready for the WG last call. Low Latency Handover - Karim El-Malki ===================================== Short update of the draft-ietf-mobileip-lowlatency-handoffs-v4-01.txt presented by Karim. It seems draft discusses mainly three handoff techniques, pre-registration, post-registration and combined of the above two. This draft is completed and may be ready for the last WG call. The discussion lead toward using trigger defined from mayfolks-l2-trigger draft rather than defining separate subset specific to this work. Co-chair pointed out that by doing this, there might be a problem of introducing dependency. No decision was made in the meeting on this issue. Fast Handover - Gopal Dometty ============================= Gopal presented updates on draft-ietf-mobileip-fast-mipv6-01.txt. As per this draft, the mobile node can initiate a handover while it still has L2 connectivity to the current access router and about to move to a new access router. It seems there are some minor editorial changes made to this draft. He claimed that L2 and L3 are decoupled. Pat pointed out that access point is nothing but the foreign agent and hence it will have L3 address. Gopal pointed out that L3 information is generally obtained from L2. There is no agent advertisement involved here and hence may reduce delay. Also old CoA is reused. BETH - James Kempf =================== James provided brief overview of BETH. He mentioned that BETH defines 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. It also removes routing loop problem. There were many questions raised by the group like how the new AR detects when the MN has an operational new CoA and tunnel tear down is started; bicasting is specified but the smoothing is not well understood; this draft may be dealing with rare cases only; for certain type of radio links the solution provided by this draft may not work etc. The proposed plan is to incorporate BETH into the FMIPv6 specification as another way for achieving fast handoff. The scheme currently existing in the low-latency (v4) will also be aligned with the BETh proposal. FMIPv6 Implementation experience report - Rajeev Koodli ======================================================= Rajeev provided brief summery of FMIPv6 implementation experience. Handovers are all network initiated using UNIX based router, LINUX MN on 11 Mbps WLAN. The following issues were identified - What destination address to use in the F-BU? It was confirmed by group that global IP address should be used instead of local address as suggested by current specifications - Creating binding cache entry on previous access router (after receiving Hack and after sending F-Back to the old link). It was concluded that this is implementation specific and doesn't really have any protocol impact. - What source address to use when sending F-BU from newer AR? - Issues may be related to sending of F-NA (including only one IP address suffices). The group provided comments that it is essential to know both Hack and F-Back. - When to change default router? There are two options proposed: after receiving proxy PA (may be not) or after actually attaching to the new link (the new AR). Handover Smoothing - Phil Roberts ================================= Phil pointed out that smoothing is currently part of low latency draft (draft-ietf-mobileip-lowlatency-handoffs-v4-01.txt) along with simultaneous binding and currently it is not supported in FMIPv6. The current proposal is to add handover smoothing to the FMIPv6 draft and remove it from the low latency draft. The following comments/proposals were received from the group - FMIPv6 and smoothing may be defined as optional - Bicasting may be treated as implementation specific. - Bicasting is a useful feature needed for handovers - There may be lot more work involved in removing smoothing from the low latency draft - Bicasting is meant for achieving fast handovers and not necessarily for the handover smoothing Discussion on smoothing vs bicasting and buffering. It was determined that smoothing has a larger scope than either bicasting and/or buffering and should be considered as a separate work item. However for the fast handoff work a consensus call was done to determine if bicasting should be included as part of the FMIPv6 specification. The final consensus was to move bicasting to a separate document for both the v4 and v6 fast handoff drafts. ///////////////// // Session 2 // ///////////////// August 7th, 2001 (1700-1800) Reported by : Basavaraj Patil Consensus call for including bicasting in the fast handoff document was not very clear at the previous meeting. Clarified the question requiring consensus. The consensus call essentially was to see if people wanted to see bicasting as another option within the fast handoff specification. Consensus reached: Separate bicasting from fast handoff. LMM Requirements - Carl Williams ================================ [draft-ietf-mobileip-lmm-requirements-00.txt] Carl presented the major issues that have been raised on the Mobile IP mailing list since the last IETF[50] w.r.t LMM. The draft with Carl as the editor captures the requirements for an LMM solution. Discussion focused around obtaining consensus on the requirements and also to clarify the issues that have been previously discussed. One major issue that continues to persist is the one dealing with the levels of hierarchy. A long discussion on the pros and cons of single vs multiple levels of hierarchy ensued. Since there was no conclusion on levels of hierarchy, it was decided that Carl would work with some of the interested people on this topic to arrive at some consensus. This should be documented in the next revision of the requirements document. Mobile Network Suppport - Thierry Ernst ======================================= [draft-ernst-mobileip-monetv6-00.txt] Thierry Ernst presented the draft on support for mobile networks and routers for IPv6 using Mobile IPv6. Obviously this topic needs to be investigated more as it raised more questions than answers at this time. Basavaraj mentioned that the work does fit into the Mobile IP WG as the charter does not limit the scope to just mobile hosts. There were some concerns about stepping into MANET boundaries. Erik Nordmark mentioned that the issue of authorization for mobile networks is a hard problem to solve and hence suggested that more work needs to be done in this area. Opinions on the need for this work being done in the MIP WG were expressed by many people. Conclusion was that more work needs to be done in this area. This draft is a good starting point and could be used to investigate the issues raised by Thierry in his presentation. Nat Support in Mobile IPv4 - Henrik Levkowetz ============================================= A small group of WG members who are interested in having MIPv4 work in networks using NATs met the previous day. Conclusion reached at this meeting was that Mobile iPv4 does not currently work very well in a NAT world and scenarios where support for MIPv4 with NATs is required were discussed. Henrik presented the conclusions of the discussion and the need for a solution for Mobile IPv4 over NATs. Most WG members agreed that this work is important for MIPv4 deployment. A discussion list will be setup to discuss the scenarios and requirements for NAT support in MIPv4. The WG will make a decision regarding the inclusion of supporting NATs as a WG item at a later time [i.e after the scenarios and requirements draft are done]. Mobile IP Component Redundancy - Gopal Dometty ============================================== [draft-subbarao-mobileip-redundancy-00.txt] This could not be presented due to a lack of time. Other MIP issues - Basavaraj Patil ================================== Discussion item was skipped due to a lack of time. The presentations used for the items above are available at: http://people.nokia.net/~patil/MobileIP_IETF51 From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 28 11:25:58 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12945 for ; Tue, 28 Aug 2001 11:25: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 IAA15215; Tue, 28 Aug 2001 08:26:46 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA20267; Tue, 28 Aug 2001 08:26:33 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SFOk40004474 for ; Tue, 28 Aug 2001 08:24:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7SFOk8t004473 for mobile-ip-dist; Tue, 28 Aug 2001 08:24:46 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SFOg40004466 for ; Tue, 28 Aug 2001 08:24:42 -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 IAA06048 for ; Tue, 28 Aug 2001 08:24:50 -0700 (PDT) Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA12062 for ; Tue, 28 Aug 2001 08:24:50 -0700 (PDT) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate3.mot.com (motgate3 2.1) with ESMTP id IAA02081 for ; Tue, 28 Aug 2001 08:16:57 -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 IAA26382 for ; Tue, 28 Aug 2001 08:24:49 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r2.mot.com with ESMTP; Tue, 28 Aug 2001 08:24:44 -0700 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id B86D02ECAC; Tue, 28 Aug 2001 17:23:29 +0200 (CEST) To: mobile-ip@sunroof.eng.sun.com Cc: "Patil Basavaraj (NET/Dallas)" Subject: Re: [mobile-ip] Minutes of WG meeting at IETF51 (Draft version) References: <697DAA22C5004B4596E033803A7CEF441E8528@daebe007.NOE.Nokia.com> From: Alexandru Petrescu Date: 28 Aug 2001 17:24:04 +0200 In-Reply-To: <697DAA22C5004B4596E033803A7CEF441E8528@daebe007.NOE.Nokia.com> Message-Id: Lines: 15 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, thank you for the minutes, very useful. Regarding > Mobile IP v6 security update - Phil Roberts the minutes mention three draft proposals: - draft-thomas-mobileip-ha-cookies-00.txt - draft-perkins-bake-01.txt - draft-montenegro-sucv-01.txt IMHO, other drafts treat of same subject: draft-le-mobileip-dh-00.txt draft-mkhalil-mobileip-ipv6-sap-02.txt draft-roe-mobileip-updateauth-00.txt Alex From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 28 13:33:16 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16607 for ; Tue, 28 Aug 2001 13:33:16 -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 LAA13617; Tue, 28 Aug 2001 11:33: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 KAA20894; Tue, 28 Aug 2001 10:33:45 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SHVI40004870 for ; Tue, 28 Aug 2001 10:31:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7SHVItI004869 for mobile-ip-dist; Tue, 28 Aug 2001 10:31: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SHVF40004862 for ; Tue, 28 Aug 2001 10:31:15 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA07869 for ; Tue, 28 Aug 2001 10:31:24 -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 LAA23327 for ; Tue, 28 Aug 2001 11:31:48 -0600 (MDT) Received: from sinope.ee.tu-berlin.de ([130.149.49.127]) by mail.zrz.tu-berlin.de with esmtp (exim-3.33) for id 15bmhs-0005XK-00; Tue, 28 Aug 2001 19:31:20 +0200 Received: from ee.tu-berlin.de (fu@sinope.ee.TU-Berlin.DE [130.149.49.127]) by sinope.ee.TU-Berlin.DE (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA14185 for ; Tue, 28 Aug 2001 19:30:59 +0200 Message-ID: <3B8BD544.5020ECB1@ee.tu-berlin.de> Date: Tue, 28 Aug 2001 19:30: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] I-D ACTION:draft-ietf-mobileip-qos-requirements-01.txt References: <200108271048.GAA10045@ietf.org> 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, Nice to see the new version. One comment: > 3.3.2. Interactions with link-layer support for QoS... It's a problem imposeded by the wireless link (other than MIP itself) as I understand. How about treating it as one of the hereterious cases and moving to 3.2.2? Xiaoming From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 28 14:52:48 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18543 for ; Tue, 28 Aug 2001 14:52:47 -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 MAA20282; Tue, 28 Aug 2001 12:53: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 LAA20999; Tue, 28 Aug 2001 11:53:28 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SIpE40005104 for ; Tue, 28 Aug 2001 11:51:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7SIpEjP005103 for mobile-ip-dist; Tue, 28 Aug 2001 11:51:14 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SIpB40005096 for ; Tue, 28 Aug 2001 11:51:11 -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 LAA25883 for ; Tue, 28 Aug 2001 11:51:18 -0700 (PDT) Received: from zcamail05.zca.compaq.com (zcamail05.zca.compaq.com [161.114.32.105]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA18281 for ; Tue, 28 Aug 2001 12:51:14 -0600 (MDT) Received: by zcamail05.zca.compaq.com (Postfix, from userid 12345) id E0B017EB; Tue, 28 Aug 2001 11:55:28 -0700 (PDT) Received: from mailrelay01.cce.cpqcorp.net (mailrelay01.cce.cpqcorp.net [16.47.68.171]) by zcamail05.zca.compaq.com (Postfix) with ESMTP id 8747E793 for ; Tue, 28 Aug 2001 11:55:28 -0700 (PDT) Received: by mailrelay01.cce.cpqcorp.net (Postfix, from userid 12345) id 0B9FC8EE; Tue, 28 Aug 2001 13:51:16 -0500 (CDT) Received: from oflume.zk3.dec.com (broflume.zk3.dec.com [16.141.0.42]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id 5BCDBB10 for ; Tue, 28 Aug 2001 13:51:15 -0500 (CDT) Received: from dogbert.zk3.dec.com by oflume.zk3.dec.com (8.8.8/1.1.22.3/03Mar00-0551AM) id OAA0000015778; Tue, 28 Aug 2001 14:51:14 -0400 (EDT) From: Brian Haley USG Received: from localhost by dogbert.zk3.dec.com (5.65v4.0/1.1.19.2/27Mar98-0945AM) id AA09446; Tue, 28 Aug 2001 14:51:10 -0400 Message-Id: <200108281851.AA09446@dogbert.zk3.dec.com> To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile IPv6 draft revision Date: Tue, 28 Aug 2001 14:51:09 -0400 X-Mts: smtp Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: "Charlie Perkins" wrote: > Following the recent discussion, I believe a new revision to the > existing Mobile IPv6 draft ...-14 is needed. > > Comments? Hi Charlie, Here are some comments I have on draft -14. Section 6.4 (HA info option) The last paragraph starts: "If both the Home Agent Preference and Home Agent Lifetime are set to their default values specified above..." but a default value for Home Agent Lifetime is never discussed. Maybe it should be the same as the Router Lifetime value that would be sent in an RA? Section 6.5 (Router advert changes) Why has the MinRtrADvInterval shrunk to 0.05 seconds from 0.5 seconds? Section 8.2 (Recieving BUs) This still has the old wording in bullet #4 that: "The Sequence Number field in the Binding Update option is greater than the Sequence Number received in the previous Binding Update for this home address, if any. ..." "Any Binding Update not satisfying all of these tests MUST be silently ignored..." Section 5.2 has the correct wording that should be put here: "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." Section 8.5 (Sending BAs) The second paragraph mentions IPsec: "The packet in which the Binding Acknowledgement is returned MUST meet the specific IPsec requirements for Binding Acknowledgements..." it should maybe say "security". Thanks, -Brian From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 28 14:57:06 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18638 for ; Tue, 28 Aug 2001 14:57: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 MAA23173; Tue, 28 Aug 2001 12:57: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 LAA22159; Tue, 28 Aug 2001 11:57:13 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SItK40005148 for ; Tue, 28 Aug 2001 11:55:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7SItJgR005147 for mobile-ip-dist; Tue, 28 Aug 2001 11:55:19 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SItG40005140 for ; Tue, 28 Aug 2001 11:55: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 LAA21728 for ; Tue, 28 Aug 2001 11:55:24 -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 LAA24284 for ; Tue, 28 Aug 2001 11:55:24 -0700 (PDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate4.mot.com (motgate4 2.1) with ESMTP id LAA11717 for ; Tue, 28 Aug 2001 11:55:23 -0700 (MST)] Received: [from il02exi02.comm.mot.com (il02exi02.comm.mot.com [145.1.204.41]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id LAA04591 for ; Tue, 28 Aug 2001 11:55:23 -0700 (MST)] Received: by il02exi02.comm.mot.com with Internet Mail Service (5.5.2654.52) id ; Tue, 28 Aug 2001 13:55:22 -0500 Message-ID: <01FAF65DEA16D4119B95009027E78F31073DAAEA@il02exm26.comm.mot.com> From: Lewis Adam-CAL022 To: Mobile-IP working group Subject: [mobile-ip] Appndix B of HMIP draft Date: Tue, 28 Aug 2001 13:55:22 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) 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: Something in appendix B of version 4 of the HMIP draft is not clear to me. The paragraph directly under figure B.1 states: "Hence, it may not be possible to use addresses based on PREFIX_A as source addresses for the MNs." I agree PREFIX_A will not work as a source address as it would likely be dropped at AR1 due to ingress filtering. However, won't a source with PREFIX_B also be dropped (this time by the MR) due to the same ingress filtering reasons? Afterall, MR's PREFIX_A interface would not expect to see packets with PREFIX_B as a source (but this is what is being done in the extended mode with mobile routers). I assume I am missing something. Does the MR not pefrom ingress filtering in this scenario? Does it look at the home address option to verify it is in fact topologically correct? Please clarify. Thanks, Adam Adam C. Lewis Senior Engineer Advanced Technology & Strategy Global Technology Development Group Commercial, Government, and Industrial Solutions Sector 1301 E. Algonquin Road IL02/Rm. 509 Schaumburg, IL 60196 Email: adam.lewis@motorola.com Phone: (847) 576-8489 Fax: (847) 576-9018 From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 29 05:58:57 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19018 for ; Wed, 29 Aug 2001 05:58: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 DAA02563; Wed, 29 Aug 2001 03:59:48 -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 CAA21104; Wed, 29 Aug 2001 02:59:37 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7T9wB40006538 for ; Wed, 29 Aug 2001 02:58:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7T9wA1o006537 for mobile-ip-dist; Wed, 29 Aug 2001 02:58:10 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7T9w740006530 for ; Wed, 29 Aug 2001 02:58:07 -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 CAA21857 for ; Wed, 29 Aug 2001 02:58:16 -0700 (PDT) Received: from iproxy1.ericsson.dk (iproxy1.ericsson.dk [130.228.248.98]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA01489 for ; Wed, 29 Aug 2001 03:58:11 -0600 (MDT) Received: from unixmail.ted.dk.eu.ericsson.se (knud.ted.dk.eu.ericsson.se [192.66.4.246]) by iproxy1.ericsson.dk (8.10.1/8.10.1) with ESMTP id f7T9wEc21903; Wed, 29 Aug 2001 11:58:14 +0200 (MET DST) Received: from ted.ericsson.dk (petg.ted.dk.eu.ericsson.se [192.66.4.85]) by unixmail.ted.dk.eu.ericsson.se (8.10.1/8.10.1/TEDmain-1.0) with ESMTP id f7T9w8L04453; Wed, 29 Aug 2001 11:58:09 +0200 (MEST) Message-ID: <3B8CBCB0.7C914A94@ted.ericsson.dk> Date: Wed, 29 Aug 2001 11:58:08 +0200 From: "Peter Grimstrup (TED)" Organization: Ericsson Telebit A/S X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: henrik.petander@hut.fi CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] processing of the home address option 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 Henrik, Comments inline Regards Peter Henrik Petander wrote: > > Hi all, > > I sent email about the same subject to the list some weeks ago, but > I guess it got lost in the mail storm which took place right before the > IETF meeting. > > Section 8.1 in MIPv6 draft 14 specifies that the home address option > should be processed only after all the other options in the same > destination option header are processed. In practice, this requirement > makes the receiver keep state between different options. I wonder, whether > the requirement is really worth the extra complexity it creates in all > IPv6 nodes. > > If the ordering is required, it would IMHO be better to make the ordering > the responsibility of MN, which adds the options, i.e. "The home address > option MUST be added as the last destination option to the destination > option header ...". This would simplify the CN and would increase the > complexity of MN only marginally. The only problem being if some future option(s) must be *last* as well. In that case, splitting into 2 (or more) destination option headers may be the solution, is that feasible? > > Regards, > > Henrik Petander > > ---------------------------------- > Henrik Petander > Helsinki University of Technology, > GO/Core Project > Henrik.Petander@hut.fi > Office: +358 (0)9 451 5846 > GSM: +358 (0)40 741 5248 > ---------------------------------- -- Peter Grimstrup Systems Developer Ericsson Telebit A/S tel: +45 89 38 52 75 Skanderborgvej 232 fax: +45 89 38 51 01 DK 8260 Viby J, Denmark e-mail: peter.grimstrup@ted.ericsson.dk From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 29 07:21:57 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20226 for ; Wed, 29 Aug 2001 07:21: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 FAA14156; Wed, 29 Aug 2001 05:22:40 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA26316; Wed, 29 Aug 2001 04:22:35 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7TBKg40006612 for ; Wed, 29 Aug 2001 04:20:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7TBKggi006611 for mobile-ip-dist; Wed, 29 Aug 2001 04:20:42 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7TBKc40006604 for ; Wed, 29 Aug 2001 04:20:38 -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 EAA13733 for ; Wed, 29 Aug 2001 04:20:46 -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 EAA14418 for ; Wed, 29 Aug 2001 04:20:45 -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 HAA19877; Wed, 29 Aug 2001 07:19:25 -0400 (EDT) Message-Id: <200108291119.HAA19877@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-01.txt Date: Wed, 29 Aug 2001 07:19:25 -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-01.txt Pages : 8 Date : 28-Aug-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-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-ietf-mobileip-gen-key-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mobileip-gen-key-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: <20010828120810.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-gen-key-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-gen-key-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010828120810.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 29 10:10:30 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28109 for ; Wed, 29 Aug 2001 10:10: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 IAA24414; Wed, 29 Aug 2001 08:11: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 HAA29202; Wed, 29 Aug 2001 07:11:10 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7TE8t40006875 for ; Wed, 29 Aug 2001 07:08:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7TE8tYn006874 for mobile-ip-dist; Wed, 29 Aug 2001 07:08: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.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7TE8p40006867 for ; Wed, 29 Aug 2001 07:08: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 HAA10943 for ; Wed, 29 Aug 2001 07:08:59 -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 HAA18759 for ; Wed, 29 Aug 2001 07:08:57 -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 f7TE8uv01382 for ; Wed, 29 Aug 2001 16:08:56 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Wed Aug 29 16:08:48 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Wed, 29 Aug 2001 16:08:42 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008C4A@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Appndix B of HMIP draft Date: Wed, 29 Aug 2001 16:08:36 +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: > Something in appendix B of version 4 of the HMIP draft is not clear to me. The paragraph directly under figure B.1 states: > > "Hence, it may not be possible to use addresses > based on PREFIX_A as source addresses for the MNs." > > I agree PREFIX_A will not work as a source address as it would likely be dropped at AR1 due to ingress filtering. However, won't a source with PREFIX_B also be dropped (this time by the MR) due to the same ingress filtering reasons? Afterall, MR's PREFIX_A interface would not expect to see packets with PREFIX_B as a source (but this is what is being done in the extended mode with mobile routers). I assume I am missing something. Does the MR not pefrom ingress filtering in this scenario? Does it look at the home address option to verify it is in fact topologically correct? > => Thanks for catching that despite a cryptic figure (we'll fix that figure in the next revision). There are different ways we can handle this: 1. The MR is aware of the mobility scenario (it does know what's happening because it sets theT flag in the MAP option) so it doesn't ingress filter on the PREFIX_B address 2. We make sure that the MN uses RCoA (from the further MAP) as a source and the MR MUST NOT ingress filter that prefix. 3. The MR does the same as 1 and tunnels outgoing packets to the further MAP (fixed MAP). I prefer 3 andwould try to avoid 1 as much as possible. What do you think ? Hesham From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 29 10:28:06 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28987 for ; Wed, 29 Aug 2001 10:28:05 -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 HAA13387; Wed, 29 Aug 2001 07:28: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 HAA02979; Wed, 29 Aug 2001 07:28:34 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7TEPJ40006933 for ; Wed, 29 Aug 2001 07:25:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7TEPIoR006932 for mobile-ip-dist; Wed, 29 Aug 2001 07:25: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7TEPF40006925 for ; Wed, 29 Aug 2001 07:25:15 -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 HAA01715 for ; Wed, 29 Aug 2001 07:25:23 -0700 (PDT) Received: from hotmail.com (f146.law7.hotmail.com [216.33.237.146]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA28030 for ; Wed, 29 Aug 2001 07:25:22 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 29 Aug 2001 07:25:22 -0700 Received: from 63.78.179.4 by lw7fd.law7.hotmail.msn.com with HTTP; Wed, 29 Aug 2001 14:25:22 GMT X-Originating-IP: [63.78.179.4] From: "Hemant Chaskar" To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] I-D ACTION:draft-ietf-mobileip-qos-requirements-01.txt Date: Wed, 29 Aug 2001 14:25:22 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 29 Aug 2001 14:25:22.0552 (UTC) FILETIME=[70026F80:01C13096] Sender: owner-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: All the requirements in this draft are those imposed by MIP. The wireless-link requirement is included there because practically all the deployment of MIP will be for nodes connected by wireless links to the Internet. There is one problem moving this requirement to heterogeneity section. It is that the heterogeneity of wireless link layers is more or less transparent to IP layer. The heterogeneity section contains the requirements imposed due to heterogeneity at IP-layer such as different IP-QoS mechanisms. Hemant >From: Xiaoming Fu >Reply-To: mobile-ip@sunroof.eng.sun.com >To: mobile-ip@sunroof.eng.sun.com >Subject: Re: [mobile-ip] I-D >ACTION:draft-ietf-mobileip-qos-requirements-01.txt >Date: Tue, 28 Aug 2001 19:30:44 +0200 > >Hi Hemant, > >Nice to see the new version. One comment: > > > 3.3.2. Interactions with link-layer support for QoS... >It's a problem imposeded by the wireless link (other than MIP itself) >as I understand. How about treating it as one of the hereterious >cases and moving to 3.2.2? > >Xiaoming _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 29 10:55:11 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29941 for ; Wed, 29 Aug 2001 10:55: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 IAA00639; Wed, 29 Aug 2001 08:55: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 HAA17009; Wed, 29 Aug 2001 07:55:54 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7TEsW40007049 for ; Wed, 29 Aug 2001 07:54:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7TEsVTH007048 for mobile-ip-dist; Wed, 29 Aug 2001 07:54:31 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7TEsS40007041 for ; Wed, 29 Aug 2001 07:54:28 -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 HAA18789 for ; Wed, 29 Aug 2001 07:54:35 -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 HAA14178 for ; Wed, 29 Aug 2001 07:54:34 -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 HAA15782; Wed, 29 Aug 2001 07:54:34 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f7TErJs26485; Wed, 29 Aug 2001 07:53:19 -0700 X-mProtect: Wed, 29 Aug 2001 07:53:19 -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 smtpdBHeycb; Wed, 29 Aug 2001 07:52:37 PDT Message-ID: <3B8D01B5.D3F70A48@iprg.nokia.com> Date: Wed, 29 Aug 2001 07:52:37 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Henrik.Petander@hut.fi CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] processing of the home address option 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 Henrik > Section 8.1 in MIPv6 draft 14 specifies that the home address option > should be processed only after all the other options in the same > destination option header are processed. In practice, this requirement > makes the receiver keep state between different options. I wonder, whether > the requirement is really worth the extra complexity it creates in all > IPv6 nodes. The intention was to make sure that processing the home address option would cause the mobile node's home address to be delivered to the higher level protocols at the correspondent node, while still allowing the care-of address to be visible at the IP layer. The restriction about when the processing occurs should probably be removed, because it does not matter how an implementation ensures the correct property of the home address option (as long as it does ensure it). Currently, the care-of address doesn't serve any purpose past this point, and would not have to be maintained by the implementation after processing at the network layer. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 29 11:32:52 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01316 for ; Wed, 29 Aug 2001 11:32: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 IAA16593; Wed, 29 Aug 2001 08:33:36 -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 IAA24959; Wed, 29 Aug 2001 08:33:23 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7TFVI40007167 for ; Wed, 29 Aug 2001 08:31:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7TFVIHl007166 for mobile-ip-dist; Wed, 29 Aug 2001 08:31: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7TFVE40007159 for ; Wed, 29 Aug 2001 08:31: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 IAA24518 for ; Wed, 29 Aug 2001 08:31:22 -0700 (PDT) Received: from mail.zrz.tu-berlin.de (mail.zrz.TU-Berlin.DE [130.149.4.15]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA25829 for ; Wed, 29 Aug 2001 08:31:21 -0700 (PDT) Received: from sinope.ee.tu-berlin.de ([130.149.49.127]) by mail.zrz.tu-berlin.de with esmtp (exim-3.33) for id 15c7JI-0002Lr-00; Wed, 29 Aug 2001 17:31:20 +0200 Received: from ee.tu-berlin.de (fu@sinope.ee.TU-Berlin.DE [130.149.49.127]) by sinope.ee.TU-Berlin.DE (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA19132 for ; Wed, 29 Aug 2001 17:31:20 +0200 Message-ID: <3B8D0AC8.35589A1B@ee.tu-berlin.de> Date: Wed, 29 Aug 2001 17:31:20 +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] I-D ACTION:draft-ietf-mobileip-qos-requirements-01.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, > > All the requirements in this draft are those imposed by MIP. The > wireless-link requirement is included there because practically all the > deployment of MIP will be for nodes connected by wireless links to the > Internet. Yes, it'll result in the characteristics difference for wireless links during handoffs. However IMO a IP-QoS mechanism itself should take such a link (wireless) into consideration - if we want to include such link characteristics in any QoS solution. The difficulty might lie when there are no such parameters (e.g., MN in wired link) before handoff while after handoff such parameters are introduced in the new path. > There is one problem moving this requirement to heterogeneity section. It is > that the heterogeneity of wireless link layers is more or less transparent > to IP layer. The heterogeneity section contains the requirements imposed due > to heterogeneity at IP-layer such as different IP-QoS mechanisms. I agree current description 3.2.2 only concerns with difference of various IP-layer QoS mechanisms, but could we extend it a broader way? BTW, the quoted "(best current practices)" in 3.2.2 seems unclear to me. Does it mean "or BCPs" or "from BCPs"? Cheers, Xiaoming From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 29 11:40:32 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01504 for ; Wed, 29 Aug 2001 11:40:32 -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 JAA08931; Wed, 29 Aug 2001 09:41: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 IAA25963; Wed, 29 Aug 2001 08:41:05 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7TFdM40007204 for ; Wed, 29 Aug 2001 08:39:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7TFdMdK007203 for mobile-ip-dist; Wed, 29 Aug 2001 08:39:22 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7TFdJ40007196 for ; Wed, 29 Aug 2001 08:39: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 IAA19411 for ; Wed, 29 Aug 2001 08:39:27 -0700 (PDT) Received: from mail2.zrz.tu-berlin.de (mail2.zrz.TU-Berlin.DE [130.149.4.14]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA29880 for ; Wed, 29 Aug 2001 08:39:26 -0700 (PDT) Received: from sinope.ee.tu-berlin.de ([130.149.49.127]) by mail2.zrz.tu-berlin.de with esmtp (exim-3.33) for id 15c7R7-00040j-00; Wed, 29 Aug 2001 17:39:25 +0200 Received: from ee.tu-berlin.de (fu@sinope.ee.TU-Berlin.DE [130.149.49.127]) by sinope.ee.TU-Berlin.DE (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA19177 for ; Wed, 29 Aug 2001 17:39:25 +0200 Message-ID: <3B8D0CAD.1C10D315@ee.tu-berlin.de> Date: Wed, 29 Aug 2001 17:39:25 +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: <034BEFD03799D411A59F00508BDF754603008B39@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: > > > > => 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 -- ---------------------------------------- Dr. Xiaoming Fu Telecommunication Networks Group Technical University Berlin Einsteinufer 25, 10587 Berlin Tel: (0049-30)31423827 Fax: (0049-30)31423818 Email: fu@ee.tu-berlin.de ---------------------------------------- From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 29 13:25:28 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03844 for ; Wed, 29 Aug 2001 13:25: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 KAA24787; Wed, 29 Aug 2001 10:25: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 KAA08086; Wed, 29 Aug 2001 10:20:18 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7THEs40007439 for ; Wed, 29 Aug 2001 10:14:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7THEsDx007438 for mobile-ip-dist; Wed, 29 Aug 2001 10:14:54 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7THEo40007431 for ; Wed, 29 Aug 2001 10:14:50 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA00368 for ; Wed, 29 Aug 2001 10:14:59 -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 LAA28577 for ; Wed, 29 Aug 2001 11:15:24 -0600 (MDT) Received: from sinope.ee.tu-berlin.de ([130.149.49.127]) by mail.zrz.tu-berlin.de with esmtp (exim-3.33) for id 15c8vY-0004cV-00; Wed, 29 Aug 2001 19:14:56 +0200 Received: from ee.tu-berlin.de (fu@sinope.ee.TU-Berlin.DE [130.149.49.127]) by sinope.ee.TU-Berlin.DE (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA19471 for ; Wed, 29 Aug 2001 19:14:56 +0200 Message-ID: <3B8D2310.27DB938A@ee.tu-berlin.de> Date: Wed, 29 Aug 2001 19:14:56 +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: <034BEFD03799D411A59F00508BDF754603008B59@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 Hi, Sorry for the previous mis-operation. "Hesham Soliman (ERA)" 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, =>I mistyped here, should be "ARs",not "MAP" >we can do CT(oAR-->nAR), and process the BU+QoS from the oAR until the >switching point in a conforming way. > > => 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). How could you merge FHO&HMIP when multiple MAPs are used? E.g., A MN may happen to run into another MAP domain. If CT is favorate, I think CT(oAR->nAR) is still more appropriate for a more general case. Xiaoming From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 29 16:32:44 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08615 for ; Wed, 29 Aug 2001 16:32:43 -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 NAA24128; Wed, 29 Aug 2001 13:33: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 NAA19815; Wed, 29 Aug 2001 13:33:09 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7TKUv40008095 for ; Wed, 29 Aug 2001 13:30:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7TKUvV1008094 for mobile-ip-dist; Wed, 29 Aug 2001 13:30:57 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7TKUq40008087 for ; Wed, 29 Aug 2001 13:30: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 NAA23999 for ; Wed, 29 Aug 2001 13:30:57 -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 NAA19789 for ; Wed, 29 Aug 2001 13:30:56 -0700 (PDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (motgate2 2.1) with ESMTP id NAA01933 for ; Wed, 29 Aug 2001 13:30:55 -0700 (MST)] Received: [from il02exb01.comm.mot.com (il02exb01.comm.mot.com [145.1.204.17]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id NAA28573 for ; Wed, 29 Aug 2001 13:30:55 -0700 (MST)] Received: by il02exb01.comm.mot.com with Internet Mail Service (5.5.2654.52) id ; Wed, 29 Aug 2001 15:30:54 -0500 Message-ID: <01FAF65DEA16D4119B95009027E78F310743F4B0@il02exm26.comm.mot.com> From: Lewis Adam-CAL022 To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Appndix B of HMIP draft Date: Wed, 29 Aug 2001 15:30:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) 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, -----Original Message----- From: Hesham Soliman (ERA) [mailto:Hesham.Soliman@era.ericsson.se] Sent: Wednesday, August 29, 2001 9:09 AM To: 'mobile-ip@sunroof.eng.sun.com' Subject: RE: [mobile-ip] Appndix B of HMIP draft > Something in appendix B of version 4 of the HMIP draft is not clear to me. The paragraph directly under figure B.1 states: > > "Hence, it may not be possible to use addresses > based on PREFIX_A as source addresses for the MNs." > > I agree PREFIX_A will not work as a source address as it would likely be dropped at AR1 due to ingress filtering. However, won't a source with PREFIX_B also be dropped (this time by the MR) due to the same ingress filtering reasons? Afterall, MR's PREFIX_A interface would not expect to see packets with PREFIX_B as a source (but this is what is being done in the extended mode with mobile routers). I assume I am missing something. Does the MR not pefrom ingress filtering in this scenario? Does it look at the home address option to verify it is in fact topologically correct? > => Thanks for catching that despite a cryptic figure (we'll fix that figure in the next revision). There are different ways we can handle this: 1. The MR is aware of the mobility scenario (it does know what's happening because it sets theT flag in the MAP option) so it doesn't ingress filter on the PREFIX_B address 2. We make sure that the MN uses RCoA (from the further MAP) as a source and the MR MUST NOT ingress filter that prefix. 3. The MR does the same as 1 and tunnels outgoing packets to the further MAP (fixed MAP). I prefer 3 andwould try to avoid 1 as much as possible. What do you think ? Hesham ---- I agree option 1 should be avoided. The problem I have with both options 2) and 3) is that they both assume their is a further MAP. It is very possible I think that somebody might want to use the value-added ability of HMIP to support a mobile router/network, without deploying a full HMIP network. I think the two should be able to stand alone. From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 30 03:00:13 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07049 for ; Thu, 30 Aug 2001 03:00: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 BAA08590; Thu, 30 Aug 2001 01:00:58 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA17244; Thu, 30 Aug 2001 00:00:45 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7U6wR40009314 for ; Wed, 29 Aug 2001 23:58:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7U6wRkS009313 for mobile-ip-dist; Wed, 29 Aug 2001 23:58:27 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7U6wN40009306 for ; Wed, 29 Aug 2001 23:58:23 -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 XAA14235 for ; Wed, 29 Aug 2001 23:58:32 -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 XAA25200 for ; Wed, 29 Aug 2001 23:58:31 -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 f7U6wUv26004 for ; Thu, 30 Aug 2001 08:58:30 +0200 (MEST) Received: FROM esealnt747.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Thu Aug 30 08:58:29 2001 +0200 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 30 Aug 2001 08:58:22 +0200 Message-ID: From: "Karen E Nielsen (TED)" To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] -14 Authentication Data computation Date: Thu, 30 Aug 2001 08:58:11 +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: Comment/question to the computation of the Authentication Data covering a Binding Update and a Binding Acknowledgement in draft -14. According to section 4.4 in draft-14 the Authentication Data covering a Binding Updata MUST be computed over a bit string containing the following IP addresses: Destination IP Address of the IPv6 header Care-of Address, in the Source IP Address of the IPv6 header Home Address, from the Home Address destination option + some more data And the Authentication Data covering a Binding Acknowledgement MUST be computed over a bit string containing the following IP addresses : Destination IP Address of the IPv6 header Source IP Address of the IPv6 header + some more data First of all I suppose that what is meant is the destination addresses of the IPv6 header as it appears at the receiver end (in line with the computation of authentication data in IP SEC) !? Since both the BU (in case the CN is mobile) and the BUAck might be send using a routing header this will be important to specify, I think. Secondly, in the case where the CN is itself a mobile node, the source address of the IP header of the BuAck will be a CoA of the CN, which really has nothing to do with the acknowledgement of a BU sent to the CN - wouldn't the appropriate address to cover here be the Home address of the CN - either appearing in the source address of the IP header or in the Home Address option ? /Karen ---------------------------------------------- Karen Egede Nielsen Ericsson Telebit A/S, Research Tel: + 45 89 38 51 00 Fax: + 45 89 38 51 01 Tel Direct: + 45 89 38 53 13 Email: karen.e.nielsen@lmd.ericsson.se/ karen.e.nielsen@ted.ericsson.dk ---------------------------------------------- From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 30 04:36:30 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07932 for ; Thu, 30 Aug 2001 04:36:29 -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 CAA22741; Thu, 30 Aug 2001 02:37: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 BAA15299; Thu, 30 Aug 2001 01:37:02 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7U8YX40009537 for ; Thu, 30 Aug 2001 01:34:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7U8YXbS009536 for mobile-ip-dist; Thu, 30 Aug 2001 01:34:33 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7U8YT40009529 for ; Thu, 30 Aug 2001 01:34: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 BAA24155 for ; Thu, 30 Aug 2001 01:34:39 -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 BAA00244 for ; Thu, 30 Aug 2001 01:34:38 -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 f7U8YaK03581 for ; Thu, 30 Aug 2001 10:34:37 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Thu Aug 30 10:34:36 2001 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 30 Aug 2001 10:27:51 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008C4F@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Appndix B of HMIP draft Date: Thu, 30 Aug 2001 10:34: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: > > Something in appendix B of version 4 of the HMIP draft is not clear to me. The paragraph directly under figure B.1 states: > > > > "Hence, it may not be possible to use addresses > > based on PREFIX_A as source addresses for the MNs." > > > > I agree PREFIX_A will not work as a source address as it would likely be dropped at AR1 due to ingress filtering. However, won't a source with PREFIX_B also be dropped (this time by the MR) due to the same ingress filtering reasons? Afterall, MR's PREFIX_A interface would not expect to see packets with PREFIX_B as a source (but this is what is being done in the extended mode with mobile routers). I assume I am missing something. Does the MR not pefrom ingress filtering in this scenario? Does it look at the home address option to verify it is in fact topologically correct? > > > => Thanks for catching that despite a cryptic figure (we'll fix that figure > in the next revision). > There are different ways we can handle this: > > 1. The MR is aware of the mobility scenario (it does know > what's happening because it sets theT flag in the > MAP option) so it doesn't ingress filter on the PREFIX_B address > > 2. We make sure that the MN uses RCoA (from the further MAP) > as a source and the MR MUST NOT ingress filter that prefix. > > 3. The MR does the same as 1 and tunnels outgoing packets to the > further MAP (fixed MAP). > > I prefer 3 andwould try to avoid 1 as much as possible. > What do you think ? > > Hesham > > > ---- > I agree option 1 should be avoided. The problem I have with both options 2) and 3) is that they both assume their is a further MAP. It is very possible I think that somebody might want to use the value-added ability of HMIP to support a mobile router/network, without deploying a full HMIP network. I think the two should be able to stand alone. > => I agree. However, the "further" MAP is only needed as a tunnel end point. So to replace it you need to: 1. Have an IP address for another router (easily solved) 2. That router has to trust you and forward your original packet that wouldn't have gone through the ingress filter. This trust is implicit in the further MAP by virtue of the BU (I know this is questionable but some extensons can be made to allow this). So the second point is not tricky to solve but it requires a carrier. Having it as a further MAP allows the carrier to be a BU. Of course you can also just reverse tunnel to the HA ! This will solve it but for a price. Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 30 11:49:52 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20027 for ; Thu, 30 Aug 2001 11:49: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 IAA19531; Thu, 30 Aug 2001 08:48: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 IAA00665; Thu, 30 Aug 2001 08:47:56 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7UFkA40010090 for ; Thu, 30 Aug 2001 08:46:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7UFk9IV010089 for mobile-ip-dist; Thu, 30 Aug 2001 08:46:09 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7UFk640010082 for ; Thu, 30 Aug 2001 08: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 IAA00361 for ; Thu, 30 Aug 2001 08:46:14 -0700 (PDT) Received: from idcpa4.pa.interdigital.com ([12.32.197.142]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA12079 for ; Thu, 30 Aug 2001 09:46:09 -0600 (MDT) Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19) id ; Thu, 30 Aug 2001 11:45:17 -0400 Message-ID: From: "Shahrier, Sharif M." To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Appndix B of HMIP draft Date: Thu, 30 Aug 2001 11:45:17 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f7UFk640010083 Sender: owner-mobile-ip@sunroof.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 wanted to solicit a response from anyone interested in working on: · Inter-Domain Mobility Management (mobility between two administrative networks). This could be viewed as higher-level mobility management (sometimes called "roaming"). Solutions to this problem have ben presued in other organizations, 3GPP, but I am not certain of anything being done in the IP-layer. If anyone is interested I would be glad to discuss further, either on the mailing-list, or off-line. Thanks. -Sharif. From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 30 13:21:23 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22397 for ; Thu, 30 Aug 2001 13:21: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 LAA05055; Thu, 30 Aug 2001 11:22: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 KAA21293; Thu, 30 Aug 2001 10:21:46 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7UHJ040010243 for ; Thu, 30 Aug 2001 10:19:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7UHJ0hE010242 for mobile-ip-dist; Thu, 30 Aug 2001 10:19: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 eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7UHIu40010235 for ; Thu, 30 Aug 2001 10:18:58 -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 NAA16879 for ; Thu, 30 Aug 2001 13:19:05 -0400 (EDT) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id NAA02074 for mobile-ip@sunroof.eng.sun.com; Thu, 30 Aug 2001 13:19:34 -0400 (EDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7U7RR40009408 for ; Thu, 30 Aug 2001 00:27: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 AAA29610 for ; Thu, 30 Aug 2001 00:27:35 -0700 (PDT) Received: from taku.hut.fi (taku.hut.fi [130.233.228.87]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA05681 for ; Thu, 30 Aug 2001 00:27:34 -0700 (PDT) Received: from kosh.hut.fi (lpetande@kosh.hut.fi [130.233.228.10]) by taku.hut.fi (8.9.3/8.9.3) with ESMTP id KAA26518; Thu, 30 Aug 2001 10:27:31 +0300 (EET DST) Date: Thu, 30 Aug 2001 10:27:30 +0300 (EET DST) From: Lars Henrik Petander To: "Charles E. Perkins" cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] processing of the home address option In-Reply-To: <3B8D01B5.D3F70A48@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hello Charlie, Thanks for the clarification. On Wed, 29 Aug 2001, Charles E. Perkins wrote: > > The intention was to make sure that processing the home address > option would cause the mobile node's home address to be delivered > to the higher level protocols at the correspondent node, while still > allowing the care-of address to be visible at the IP layer. Our implementation processes the destination options in order, but maintains a pointer to the home address option now containing the CoA, so we did not understand the purpose of the requirement. > The > restriction about when the processing occurs should probably be > removed, because it does not matter how an implementation ensures > the correct property of the home address option (as long as it does > ensure it). I agree with you on this. Henrik From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 30 13:28:02 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22551 for ; Thu, 30 Aug 2001 13:28: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 KAA12631; Thu, 30 Aug 2001 10:28: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 KAA22650; Thu, 30 Aug 2001 10:27:49 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7UHPq40010313 for ; Thu, 30 Aug 2001 10:25:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7UHPq4Z010312 for mobile-ip-dist; Thu, 30 Aug 2001 10:25: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 heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7UHPm40010305 for ; Thu, 30 Aug 2001 10:25: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 KAA18100 for ; Thu, 30 Aug 2001 10:25:58 -0700 (PDT) Message-Id: <200108301725.KAA18100@heliopolis.eng.sun.com> Date: Thu, 30 Aug 2001 10:25:57 -0700 (PDT) From: James Kempf Subject: [mobile-ip] Low Latency Issue: Should HTT be MUST, SHOULD, or MAY? To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: gv4KQHzIhXHfo6if+p/ZhQ== 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: At IETF 51 in London, it was agreed to add the Handoff To Third (HTT) to the POST-REGISTRATION part of the MIPv4 low latency handoff design. The HTT allows a MN that is already receiving traffic via a tunnel from an anchor FA to move to a new FA without receiving a new CoA. It is necessary because the current design provides no support for the case where a MN is moving so rapidly that it does not complete L3 handover by the time it moves to a new FA. The authors of the draft have discussed this, and are not in agreement about what level to incorporate HTT. In particular, should HTT be MUST, SHOULD, or MAY? In favor of MAY: We should keep the protocol as simple as possible. This message is only required in certain restricted circumstances that will not occur for every radio link protocol, and therefore it should not be required unless the radio link protocol supports rapid movement to a new FA. In favor of MUST: In addition to fixing the abovementioned bug, HTT also provides a new capability that is not available in RFC 2002 nor with PRE-REGISTRATION, namely the ability of the MN to choose when it should obtain a CoA based upon its traffic. If the MN is receiving real time traffic, it may choose to forgo L3 handoff until the real time stream is done, thereby avoiding the radio link traffic involved in MIP signalling. This is similar to the BETH proposal for IPv6, which the WG agreed to incorporate into the FMIPv6 draft. The authors need working group guidance on this issue. jak From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 30 13:52:29 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23359 for ; Thu, 30 Aug 2001 13:52: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 LAA01503; Thu, 30 Aug 2001 11:53: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 KAA28178; Thu, 30 Aug 2001 10:53:08 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7UHoj40010456 for ; Thu, 30 Aug 2001 10:50:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7UHojGY010455 for mobile-ip-dist; Thu, 30 Aug 2001 10:50: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 heliopolis.eng.sun.com (bigbang.Eng.Sun.COM [152.70.8.30]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7UHog40010448 for ; Thu, 30 Aug 2001 10:50: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 KAA19595 for ; Thu, 30 Aug 2001 10:50:51 -0700 (PDT) Message-Id: <200108301750.KAA19595@heliopolis.eng.sun.com> Date: Thu, 30 Aug 2001 10:50:51 -0700 (PDT) From: James Kempf Subject: [mobile-ip] Low Latency Issue: Where to Run the Reverse Tunnel? To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 4xCgsdAKRhRC3JdsbI6tfw== 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: The MIPv4 low latency handoff draft specifies that when egress filtering is on, the new FA needs to run a reverse tunnel in order to prevent outgoing packets from the MN from getting dropped. This is required for POST-REGISTRATION because it is fundamental to the protocol and for PRE-REGISTRATION in case L3 handover does not complete prior to L2 handover. Egress filtering causes packets to drop on the new subnet in cases where there is no route optimization and the home address is being used as the source address, and if route optimization is in effect and the old CoA is being used, perhaps temporarily, as the source address. Note that if the new subnet is not doing egress filtering, no reverse tunnel is required. The two possible places to which the tunnel could be run are: 1) The HA, as would be required at any FA where egress filtering is on and the there is no route optimization. 2) The old FA, as is done in BETH for FMIPv6. The authors are in general agreement that the tunnel should be run to the HA. In favor of the old FA: If route optimization is in effect, the tunnel must be run to the old FA because the source address on the MN's packets will be on the old FA's subnet. If they are tunneled to the HA's subnet, the ingress filter on the HA's subnet may drop them. In addition, tunneling them to the HA will require a preregistration transaction between the HA and the new FA, otherwise the HA is in danger of dropping the packets because the new FA is not yet known. This transaction will add to the latency of handover, in particular, because the topological distance between the new FA and the HA is likely to be longer than the distance between the old and new FAs. In favor of the HA: Route optimization is not currently deployed, nor does it look likely to be deployed any time in the near future. Should route optimization be deployed, we can modify the protocol to allow tunneling back to the old FA. The new FA will need to tunnel to the HA anyway when the MN performs L3 handover and obtains its new CoA. Since the old FA will be tunneling to the HA, tunneling to the old FA then to the HA is less efficient than simply tunneling directly to the HA. In addition, tunneling to the HA is required for GRE due to the need for authentication, so tunneling to the HA simplifes the protocol if it is used in all cases. The additional amount of latency added by the preregistration should not be extreme, and the FA can buffer outgoing packets until the registration reply is received, or opportunistically send them to the HA in anticipation of a successful preregistration. The authors would like comment, particularly whether the working group agrees with the authors' opinion that tunneling directly to the HA is the right solution. jak From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 30 14:50:35 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25204 for ; Thu, 30 Aug 2001 14:50:34 -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 LAA23063; Thu, 30 Aug 2001 11:50: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 LAA11687; Thu, 30 Aug 2001 11:49:35 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7UIl840010569 for ; Thu, 30 Aug 2001 11:47:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7UIl8Ax010568 for mobile-ip-dist; Thu, 30 Aug 2001 11:47: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7UIl540010561 for ; Thu, 30 Aug 2001 11:47:05 -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 LAA09252 for ; Thu, 30 Aug 2001 11:47: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 LAA11720 for ; Thu, 30 Aug 2001 11:47:12 -0700 (PDT) Received: by megisto-sql1.megisto.com with Internet Mail Service (5.5.2650.21) id ; Thu, 30 Aug 2001 14:46:05 -0400 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] IESG feedback on AAA keys doc Date: Thu, 30 Aug 2001 14:45:58 -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, IESG feedback on this one. Phil ------------------------------ This is a comment that probably applies to lots of MIP documents. Please define "security association" in the MIP context. In IPsec terminology, for instance, it means something very specific. I.e., keys, SPIs, etc., and works only between a pair of nodes. Once an association exists, encrypted packets can be sent. No further negotiation is needed. Also, one can have multiple (different SAs between the same set of machines). This document says: 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 The MN talks to its HA, not a AAA server. So I'm not clear what is meant by "shares a security association". From my perspective, it seems like "security relationship" would be more accurate terminology. Note that the above paragraph also talks about "security associations" between the MN and HA. Here, the terminology (I suspect) corresponds more closely to the IPsec usage. But I'm not sure. General comment. This document is very loose about whether a MN is talking to a FA/HA or a AAA server. This should be made explicitly clear throughout. Indeed, my assumption is that conceptually, if not in reality, a MN NEVER speaks to an AAA server directly. Rather, it speaks MIP protocols with an HA/FA, and that HA/FA has a side conversation with the AAA server. This should be made much more clear throughout. > 2. Scope of Protocol > > The protocol and messages in this document are intended to facilitate > the following operations which may occur between the mobile node, AAA > server, home agent, and foreign agent. Throughout this section, it should be made explicitly clear *who* is sending a message, and *to* *whom* the message is being sent. Also, when someone processes an extension *who* is doing the processing. This isn't clear from just reading the text. Also, it might make sense to change the section heading to "overview" rather than Scope, since it does seem like an overview. Assuming this is an overview, I think it would help the reader if the text included steps such as as "FA sends message to AAA server ..." "AAA server does X and returns Y to the FA", "FA generates reply and sends to MN"... 2. If the mobile node does not have a Mobility Security Association with the foreign agent, it SHOULD include an MN-FA Key Request extension. In what message, and sent to whom? What is the RFC reference to the key request extension? 3. Similarly, if the mobile node does not have a Mobility Security Association with the home agent, it MUST add an MN-HA Key Request extension. In message sent to whom? 4. If one or more Key Request extensions were added, the MN-AAA Authentication extension is added to the Registration Request. Added by whom? 5. At the time the information within the MN-AAA Authentication extension is verified by the AAA server, the AAA server also generates Key Material for the keys requested by the mobile node, and causes insertion of the Key Material fields along with the Registration Reply. So there is an implied step here in which the FA exchanges messages with its local AAA server? Would be good to explicitely say that here. Is that AAA protocol already in place? What RFCs are used? I.e, is there a potential normative reference problem buried here? (I suspect the answer is no, but am not sure.) 6. The respective AAA keys are distributed to the Home and Foreign Agent via the AAA protocol. Where are the details of this described? step 6b) FA sends a reply to the MN > extension. In order for the mobile node to make use of key > information sent to it by the AAA server, the mobile node also has to > be able to select the appropriate cryptographic algorithm that uses > the key to produce the authentication. The following table contains I doubt the AAA server is sending messages to the MN. Isn't it the FA that does this (i.e., it relays this info)? Text could be more precise. Dynamic Mobility Security Associations shared between mobile nodes What is a "Dynamic Mobility Security Association"? Is it different than other types of security associations? Note: IMO, it would be better to move the description formats of the extensions here, rather than at the end. It is a bit confusing to talk about the contents of packet fields prior to having shown the format of the option with all of the fields together. > 4. Key Material Creation and Derivation > > This section contains the procedures followed in the creation of the > Key Material by AAA servers, and the key derivation procedures used ^ > by mobile nodes. Note that the AAA servers will also make use of the insert "extension" as indicated above? Also, better to say "contains the procedure a FA/HA follows when creating ..." (or is the procedure aimed at AAA servers?) The example that follows makes use of MD5 in prefix+suffix mode, whose support is mandatory in Mobile IP [11]. Other cryptographic functions, such as those listed in 3 MAY also be used. Might be better to make HMAC-MD5 the example. Also, what is meant be "listed in 3 MAY". Should that be "listed in [3] MAY"?? 1. The AAA server identifies the mobile node's via a ``node-address''. If the Home Address field of the Registration Request is zero (0), the Mobile Node's NAI is used instead. First sentence doesn't parse. I'm confused by the description above in the sense that it implies that the MN Registration Request is sent to a AAA server. I thought it was sent to a FA. Also, why use the term "node-address"? Don't you really mean the home address? (the term node-address isn't defined anywhere). Maybe you mean to say: 1. The AAA server identifies the mobile node via a ``node-address''. The node-address is taken from the Home Address field of the Registration Request, or the NAI, if the Home Address field is zero (0). Note again how the text blurs the distinction between the FA and the AAA server. Does the AAA server see the registration request? I would think not. It sees information the FA sends to it, which includes portions of the registration request. The document should really make this clear throughout > 2. The AAA server generates a random [5] value of at least 64 bits. 64 bits seems short. I'd like someone with security background to comment on this. But I guess this is sent in the clear, so the length may not matter? 3. The AAA server inserts the random value into the Key extension in the ``Key Material'' field. Presumably this field is part of a message or an extension within a message. Which message or extension? Make explicit. Note steps 1-3 are done on the server, steps 4-5 on the mobile node. It might be good to make the more clear here, perhaps by having subsections? 4. The mobile node calculates key = MD5(AAA-key | Key Material | node-address | AAA-key) what is AAA-key? Where does it come from? Ditto for "Key Material" How does the mobile node know which AAA-key to use? Can there only be one (I hope not...) Key Material A random [5] value of at least 64 bits. Keying material of only 64 bits? Would this pass security muster?? > AAA SPI A 32-bit opaque value, indicating the SPI that the > mobile node must use to determine the algorithm to use > for establishing the FA security information. How does the mobile node create this SPI? Is this preconfigured? > FA SPI A 32-bit opaque value, which the mobile node MUST use > to index all the necessary information established for > the FA security information after it is decoded. Might be better to say something like: FA SPI The SPI for the Security Association to the FA that the MN creates as a result of processing this extension. > Algorithm Identifier > This field indicates the algorithm to be used for > future computations of the MN-FA Authentication > Extension (see section 3) It would be good to state explicitely state that this is the same algorithm identifier as defined in XXX (section 3 doesn't seem to do this either). This document doesn't say. I.e., this presumably points to an existing name space managed by IANA. What is it? [hmm I later see that this is a new name space.. see comment below.] > The Unsolicited MN-FA Key Material From AAA extension, shown > in figure 1, uses subtype 7 of the Generalized MN-FA Key Reply > Extension [12]. Shouldn't this be moved to the beginning of section 5. (e.g., as it is in Section 6?) > HA SPI A 32-bit opaque value, which the mobile node MUST use > to index all the necessary information established for > the HA security information after it is decoded. Same comment as above w.r.t FA SPI. Ditto for key material. > the Key Material provided by the home domain AAA server (AAAH). The > key is intended for use the mobile node to secure future Mobile IP > registrations with its home agent. The MN-HA Key Reply MUST appear sentence doesn't parse. > The mobile node uses the Identification field data from the > Registration Request as its initial synchronization data with the > home agent. What is the field referred to in this sentence? > 7. MN-FA Key Request From AAA Subtype > > The MN-FA Key Request From AAA subtype data uses subtype 7 of the > Generalized MN-FA Key Request Extension [12]. The MN-FA Key Request > From AAA extension MUST appear in the Registration Request before the > MN-AAA Authentication extension. The subtype data field is zero in > length. > > > 8. MN-HA Key Request From AAA Subtype > > The MN-HA Key Request From AAA subtype data uses subtype 7 of the > Generalized MN-HA Key Request Extension [12]. The MN-HA Key Request > From AAA extension MUST appear in the Registration Request before the > MN-AAA Authentication extension. The subtype data field is zero in > length. Hmm. What are the above two sections about? The first sentence in each seems redundent. Can't the remaining text just be put in the previous sections that describe the extension? Also, why is the ordering important? > 10. IANA Considerations This document requests certain numbers be assigned. Is this required, i.e., are their implementations that already use the numbers? This section should really say TBD for any assignments that it doesn't care what the actual value is, and let IANA pick. If it really does care about the value, the text should suggest a certain value be used and mention that the numbers are already in use by existing implementations. That way, IANA has some context for deciding what to do. > Section 3 introduces the Algorithm Identifier namespace that requires > IANA management. This specification makes use of 1-3; all other > values other than zero (0) are available for assignment, pending > review and approval by a Designated Expert [9]. Can't you just leverage off an existing MIP name space (i.e, the one used by other extensions?) rather than creating a new one? From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 30 17:06:33 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28168 for ; Thu, 30 Aug 2001 17:06:32 -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 OAA20122; Thu, 30 Aug 2001 14:07: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 OAA06764; Thu, 30 Aug 2001 14:07:21 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7UL5n40010895 for ; Thu, 30 Aug 2001 14:05:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7UL5nwl010894 for mobile-ip-dist; Thu, 30 Aug 2001 14:05: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 heliopolis.eng.sun.com (bigbang.Eng.Sun.COM [152.70.8.30]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7UL5j40010887 for ; Thu, 30 Aug 2001 14:05: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 OAA28947 for ; Thu, 30 Aug 2001 14:05:55 -0700 (PDT) Message-Id: <200108302105.OAA28947@heliopolis.eng.sun.com> Date: Thu, 30 Aug 2001 14:05:54 -0700 (PDT) From: James Kempf Subject: Re: [mobile-ip] Low Latency Issue: Where to Run the Reverse Tunnel? To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: XQVRUeVL5617qYSKimRzxg== 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: Here's my opinion about one particular aspect of this issue: >... > >In favor of the old FA: ... > In addition, >tunneling them to the HA will require a preregistration transaction >between the HA and the new FA, otherwise the HA is in danger of >dropping the packets because the new FA is not yet known. This >transaction will add to the latency of handover, in particular, because >the topological distance between the new FA and the HA is likely to >be longer than the distance between the old and new FAs. > >In favor of the HA: ... > The additional >amount of latency added by the preregistration should not be extreme, >and the FA can buffer outgoing packets until the registration reply >is received, or opportunistically send them to the HA in anticipation of >a successful preregistration. > The RTT on the preregistration request/reply could cause a significant increase in latency on the handover (like, say, 60 ms if I am in California and my HA is in New Jersey, or 160 ms if I am in Minneapolis and my HA is in Germany), to say nothing of the packet getting dropped because it is sent UDP. The indicated mitigating measures are relatively unattractive. Optimistically sending the packets runs the risk of the HA dropping them if the preregistration packet never got there, buffering them runs the risk of propagating the latency and causing user perceptible artifacts in the real time stream. One solution would be to deploy regional registration. This would reduce the latency somewhat, but not eliminate it completely. In addition, regional registration is currently not widely deployed and its prospects are uncertain, whereas the need for low latency handoff is very acute and the prospects for immediate deployment are fairly good. jak From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 30 17:29:31 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28431 for ; Thu, 30 Aug 2001 17:29: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 PAA10029; Thu, 30 Aug 2001 15:29: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 OAA11576; Thu, 30 Aug 2001 14:29:50 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7ULRZ40011023 for ; Thu, 30 Aug 2001 14:27:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7ULRZkL011022 for mobile-ip-dist; Thu, 30 Aug 2001 14:27:35 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7ULRV40011015 for ; Thu, 30 Aug 2001 14:27: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 OAA22976 for ; Thu, 30 Aug 2001 14:27:41 -0700 (PDT) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA21900 for ; Thu, 30 Aug 2001 15:28:09 -0600 (MDT) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id OAA19326 for ; Thu, 30 Aug 2001 14:27:39 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id OAA26601 for ; Thu, 30 Aug 2001 14:19:30 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Thu, 30 Aug 2001 16:27:39 -0500 Message-ID: From: Singh Ajoy-ASINGH1 To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Low Latency Issue: Where to Run the Reverse Tunne l? Date: Thu, 30 Aug 2001 16:27:36 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hello Jim: Please find my inline reply. regards, ajoy -----Original Message----- From: James Kempf [mailto:James.Kempf@Sun.COM] Sent: Thursday, August 30, 2001 12:51 PM To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Low Latency Issue: Where to Run the Reverse Tunnel? The MIPv4 low latency handoff draft specifies that when egress filtering is on, the new FA needs to run a reverse tunnel in order to prevent outgoing packets from the MN from getting dropped. This is required for POST-REGISTRATION because it is fundamental to the protocol and for PRE-REGISTRATION in case L3 handover does not complete prior to L2 handover. Egress filtering causes packets to drop on the new subnet in cases where there is no route optimization and the home address is being used as the source address, and if route optimization is in effect and the old CoA is being used, perhaps temporarily, as the source address. Note that if the new subnet is not doing egress filtering, no reverse tunnel is required. The two possible places to which the tunnel could be run are: 1) The HA, as would be required at any FA where egress filtering is on and the there is no route optimization. 2) The old FA, as is done in BETH for FMIPv6. The authors are in general agreement that the tunnel should be run to the HA. In favor of the old FA: If route optimization is in effect, the tunnel must be run to the old FA because the source address on the MN's packets will be on the old FA's subnet. If they are tunneled to the HA's subnet, the ingress filter on the HA's subnet may drop them. In addition, tunneling them to the HA will require a preregistration transaction between the HA and the new FA, otherwise the HA is in danger of dropping the packets because the new FA is not yet known. This transaction will add to the latency of handover, in particular, because the topological distance between the new FA and the HA is likely to be longer than the distance between the old and new FAs. In favor of the HA: Route optimization is not currently deployed, nor does it look likely to be deployed any time in the near future. Should route optimization be deployed, we can modify the protocol to allow tunneling back to the old FA. The new FA will need to tunnel to the HA anyway when the MN performs L3 handover and obtains its new CoA. Since the old FA will be tunneling to the HA, tunneling to the old FA then to the HA is less efficient than simply tunneling directly to the HA. In addition, tunneling to the HA is required for GRE due to the need for authentication, so tunneling to the HA simplifes the protocol if it is used in all cases. The additional amount of latency added by the preregistration should not be extreme, and the FA can buffer outgoing packets until the registration reply is received, or opportunistically send them to the HA in anticipation of a successful preregistration. ajoy-> I do see some advantage of tunneling packets to HA via aFA. If someone uses GRE tunnel between aFA and nFA, they can tunnel the header compressed packets to oFA. I know this is not a Mobile/IP issue. But do we want to limit the usability of Post Registration by proposing something which can minimize its use? If we allow tunneling via aFA, we may not need to transfer header compression state, until MN changes its care of address. In fact, as far as I know, 3GPP2 would like to tunnel PPP frames from nFA to aFA using bi-directional edge tunnel. The idea of sending IP packets from nFA to HA may provide optimum routing, but it may limit the usability of Post Registration scheme. The end-to-end saving in delay may not be significant in most of the cases. Any comments ? The authors would like comment, particularly whether the working group agrees with the authors' opinion that tunneling directly to the HA is the right solution. jak From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 31 07:13:05 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28425 for ; Fri, 31 Aug 2001 07:13:05 -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 EAA27486; Fri, 31 Aug 2001 04:14:06 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA09846; Fri, 31 Aug 2001 04:13:58 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7VBCO40012071 for ; Fri, 31 Aug 2001 04:12:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7VBCOwR012070 for mobile-ip-dist; Fri, 31 Aug 2001 04:12:24 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7VBCG40012055; Fri, 31 Aug 2001 04:12: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 EAA09714; Fri, 31 Aug 2001 04:12:25 -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 EAA15128; Fri, 31 Aug 2001 04:12:24 -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 HAA28376; Fri, 31 Aug 2001 07:11:02 -0400 (EDT) Message-Id: <200108311111.HAA28376@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ngtrans@sunroof.eng.sun.com, ipngwg@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Subject: [mobile-ip] I-D ACTION:draft-engelstad-ngtrans-mobility-requirements-00.txt Date: Fri, 31 Aug 2001 07:11:02 -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 to mobility while transitioning from IPv4 to IPv6 Author(s) : P. Engelstad Filename : draft-engelstad-ngtrans-mobility-requirements-00.txt Pages : 7 Date : 14-Aug-01 This document explores how layer-3 mobility can be provided to mobile nodes that are subjects to and affected by the transition mechanisms specified by the NGTRANS Working Group. It points out that the combination of mobility and transition mechanisms might lead to problems that will require a solution, and suggests requirements that a solution should meet. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-engelstad-ngtrans-mobility-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-engelstad-ngtrans-mobility-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-engelstad-ngtrans-mobility-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: <20010831071007.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-engelstad-ngtrans-mobility-requirements-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-engelstad-ngtrans-mobility-requirements-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010831071007.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 31 09:42:57 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05220 for ; Fri, 31 Aug 2001 09:42: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 GAA13379; Fri, 31 Aug 2001 06:43: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 GAA26543; Fri, 31 Aug 2001 06:43:46 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7VDgM40012236 for ; Fri, 31 Aug 2001 06:42:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7VDgMN8012235 for mobile-ip-dist; Fri, 31 Aug 2001 06:42:22 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7VDgJ40012228 for ; Fri, 31 Aug 2001 06:42: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 GAA26495 for ; Fri, 31 Aug 2001 06:42:14 -0700 (PDT) Received: from prserv.net (out1.prserv.net [32.97.166.31]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA25143 for ; Fri, 31 Aug 2001 07:42:41 -0600 (MDT) Received: from attglobal.net (slip-32-101-253-114.il.us.prserv.net[32.101.253.114]) by prserv.net (out1) with SMTP id <2001083113421120101b6gf6e>; Fri, 31 Aug 2001 13:42:11 +0000 Message-ID: <3B8F9431.BA27E510@attglobal.net> Date: Fri, 31 Aug 2001 08:42:09 -0500 From: Sebastian Thalanany X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Low Latency Issue: Should HTT be MUST, SHOULD, or MAY? References: <200108301725.KAA18100@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, Perhaps the following paragraph, indicating the context in which HTT is applied, may support the use of "MUST". "In case the link layer triggers, which are required by the post-registration scheme, to support the movement of the wireless end of the BET, are available, then the HTT scheme MUST be applied to avoid a context transfer from the aFA to the nFA for delay-sensitive information." Regards, Sebastian James Kempf wrote: > At IETF 51 in London, it was agreed to add the Handoff To Third (HTT) > to the POST-REGISTRATION part of the MIPv4 low latency handoff design. > The HTT allows a MN that is already receiving traffic via a tunnel > from an anchor FA to move to a new FA without receiving a new CoA. > It is necessary because the current design provides no support for > the case where a MN is moving so rapidly that it does not complete > L3 handover by the time it moves to a new FA. > > The authors of the draft have discussed this, and are not in agreement > about what level to incorporate HTT. In particular, should HTT be > MUST, SHOULD, or MAY? > > In favor of MAY: We should keep the protocol as simple as possible. > This message is only required in certain restricted circumstances > that will not occur for every radio link protocol, and therefore > it should not be required unless the radio link protocol supports > rapid movement to a new FA. > > In favor of MUST: In addition to fixing the abovementioned bug, > HTT also provides a new capability that is not available in > RFC 2002 nor with PRE-REGISTRATION, namely the ability of the MN > to choose when it should obtain a CoA based upon its traffic. > If the MN is receiving real time traffic, it may choose to > forgo L3 handoff until the real time stream is done, thereby > avoiding the radio link traffic involved in MIP signalling. This > is similar to the BETH proposal for IPv6, which the WG agreed > to incorporate into the FMIPv6 draft. > > The authors need working group guidance on this issue. > > jak